From owner-seamoby@diameter.org Fri Jun 1 06:49:00 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04053 for ; Fri, 1 Jun 2001 06:48:59 -0400 (EDT) Received: (qmail 11685 invoked by alias); 1 Jun 2001 10:37:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11679 invoked by uid 200); 1 Jun 2001 10:37:49 -0000 Received: (qmail 11674 invoked from network); 1 Jun 2001 10:37:48 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 1 Jun 2001 10:37:48 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03903; Fri, 1 Jun 2001 06:47:39 -0400 (EDT) Message-Id: <200106011047.GAA03903@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-hk-seamoby-ct-ipsec-00.txt Date: Fri, 01 Jun 2001 06:47:39 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPSec Context Transfer Author(s) : L. Hamer, B. Kosinski Filename : draft-hk-seamoby-ct-ipsec-00.txt Pages : 9 Date : 31-May-01 There are a large number of IP access networks where one may wish to provide security for end user traffic, or secure the access network from unauthorized traffic. One protocol which may be used to provide these services is IPSec, which requires a node to establish a security association with the access network in order to obtain these services. Traditionally, such an association is considered static, however, there are many situations in which the ability to move an IPSec security association (SA) from one security gateway (SG) to another within the access network may be beneficial. Examples of this include IPSec handover in mobile LANs and PANs, load-balancing between IPSec SGs, and fail-over applications where high-availability is required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hk-seamoby-ct-ipsec-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hk-seamoby-ct-ipsec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hk-seamoby-ct-ipsec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010531122446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hk-seamoby-ct-ipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hk-seamoby-ct-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010531122446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Fri Jun 1 21:22:05 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20854 for ; Fri, 1 Jun 2001 21:22:04 -0400 (EDT) Received: (qmail 26505 invoked by alias); 2 Jun 2001 01:10:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26498 invoked by uid 200); 2 Jun 2001 01:10:50 -0000 Received: (qmail 26493 invoked from network); 2 Jun 2001 01:10:48 -0000 Received: from east.isi.edu (38.245.76.2) by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jun 2001 01:10:48 -0000 Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.11.3/8.9.2) with ESMTP id f521KgK14682; Fri, 1 Jun 2001 21:20:42 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f521Kux11772; Fri, 1 Jun 2001 21:20:57 -0400 Message-Id: <200106020120.f521Kux11772@minotaur.east.isi.edu> To: "Gary Kenward" cc: "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Reply-To: mankin@isi.edu Subject: Comments Re: [seamoby] ct problem statement In-reply-to: Your message of Thu, 31 May 2001 17:31:41 -0400. <9FBD322B7824D511B36900508BF93C9C9F5C5D@zcard031.ca.nortel.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 01 Jun 2001 21:20:56 -0400 From: Allison Mankin Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Gary, > Pat: > > I'm afraid to ask, but I must. What's up with the ct problem statement? > > Gary Since Pat said he'd consult the ADs to answer this: I note that the WG last call on the CT problem statement ended two days ago. Were there issues brought up to any of the authors or in the design team mailing list? The working group list did not surface any, that I saw, so I'll surface some that should be addressed before we put the draft forward for advancement: 1. The draft is very concise and easy to read - you want to spoil us in the IESG by continuing this good trend by Seamoby (in the footsteps of the paging problem statement)? [Needless to say, this is _not_ an issue :> ] 2. I would like to see some discussion of the problem space of how to evaluate when Internet CT makes sense and when it might not. For instance, the point that if a feature context has information that took many exchanges and/or computation to set up, it is a better candidate. Frequency of change of features would affect when CT is a good choice. The goal is not to make any evaluations, but to give a problem space for the protocol design work to come. How can the problem be described so that designers and eventual deployers can distinguish between optimizations that provide benefits only in narrowly constrained network circumstances and designs that provide broad enough benefits to be used at Internet level. 3. Security considerations - the point about the sensitivity of information carried in the CT is good, but the point about CT not raising new security concerns is too much of a leap. Even with the good design point of having the MN work but just have a slower handoff when CT fails, there are risks to net and nodes. Examples thought of quickly: Malicious context transferrors that give incorrect but information that is not malformed, and damage/alter the MN's connectivity Malicious CT requests causing DoS to the Forwarding Nodes that have to process them. These are from quick thought. A safer comment would be that CT probably will have novel security and requirements and design will have to address. Check out draft-rescorla-cons-03.txt for more ideas for the requirements phase. Thanks, Allison From owner-seamoby@diameter.org Mon Jun 4 07:02:01 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03087 for ; Mon, 4 Jun 2001 07:02:00 -0400 (EDT) Received: (qmail 7072 invoked by alias); 4 Jun 2001 10:50:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7066 invoked by uid 200); 4 Jun 2001 10:50:45 -0000 Received: (qmail 7061 invoked from network); 4 Jun 2001 10:50:43 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 10:50:43 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03012; Mon, 4 Jun 2001 07:00:42 -0400 (EDT) Message-Id: <200106041100.HAA03012@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-renker-paging-ipv6-00.txt Date: Mon, 04 Jun 2001 07:00:41 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Paging Concept for IP based Networks Author(s) : M. Liebsch, G. Renker Filename : draft-renker-paging-ipv6-00.txt Pages : 46 Date : 01-Jun-01 This document defines an IP paging concept that supports a registered idle state of a mobile node and coordinates paging independent of the underlying layer-2 medium. The concept specifies a generic protocol that allows to abstract away from layer-2 paging capabilities up to the Access Routers, providing wired or wireless network access to idle mobile terminals. A new entity, called Paging Agent, is introduced. This Paging Agent supports employment of several different paging strategies. The reference mobility architecture of this specification is Mobile IPv6. Avoiding modifications of Mobile IPv6 entities, the paging concept integrates modularly into the mobility environment A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-renker-paging-ipv6-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-renker-paging-ipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-renker-paging-ipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010601142312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-renker-paging-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-renker-paging-ipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010601142312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Mon Jun 4 10:40:16 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08854 for ; Mon, 4 Jun 2001 10:39:56 -0400 (EDT) Received: (qmail 9429 invoked by alias); 4 Jun 2001 14:25:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9423 invoked by uid 200); 4 Jun 2001 14:25:42 -0000 Received: (qmail 9418 invoked from network); 4 Jun 2001 14:25:40 -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; 4 Jun 2001 14:25:40 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f54EZJE16569 for ; Mon, 4 Jun 2001 10:35:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 4 Jun 2001 10:35:22 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 10:35:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C7F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'mankin@isi.edu'" Cc: "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 10:35:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED03.93334730" 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_01C0ED03.93334730 Content-Type: text/plain; charset="ISO-8859-1" Hello Allison: There were no comments, that I took note of, on the email list. There was some general debate within the ct dt around some of the issues, including the ones you have raised. I believe you are asking for some changes to the problem statement before it can be submitted to the IESG. I will endeavour to make the changes, after consulting with the wg. Your first point makes sense to add - it would seem one of those situations where we (the dt) all understood the circumstances for use of ct, and did not think it needed expounding upon. The trick will be to put it into general terms. The second point troubles me somewhat: ct is essentially an information transfer operation. I do not understand (and I can only state this as my being confusion) why it is not enough to say that this information transfer must be secure. Why would a ct be any different from any other data transfer that needs to be secured? I personally don't see any new vulnerabilities; based upon my superficial understanding of security, I read the examples you have provided as specific instances of general security problems which I understood to have been addressed. In other words, how are these scenarios not already addressed by the existing security solutions? I am not against providing security for ct - not at all. However, I do want to ensure that security remains an option to the operator (and is not build into the protocol), the overhead imparted the ct can be minimized, and the performance goals attained. I am sure the wg will have input on the security issue, and the security section will be enhanced, I am uncomfortable with that idea that ct has novel requirements. Thank you for the response, Gary > -----Original Message----- > From: Allison Mankin [mailto:mankin@isi.edu] > Sent: Friday, June 01, 2001 9:21 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > Subject: Comments Re: [seamoby] ct problem statement > > > Hi, Gary, > > > Pat: > > > > I'm afraid to ask, but I must. What's up with the ct > problem statement? > > > > Gary > > Since Pat said he'd consult the ADs to answer this: > > I note that the WG last call on the CT problem statement ended two > days ago. Were there issues brought up to any of the authors or > in the design team mailing list? The working group list did > not surface > any, that I saw, so I'll surface some that should be addressed before > we put the draft forward for advancement: > > > 1. The draft is very concise and easy to read - you want to spoil > us in the IESG by continuing this good trend by Seamoby (in the > footsteps of the paging problem statement)? [Needless > to say, this is _not_ an issue :> ] > > 2. I would like to see some discussion of the problem space of > how to evaluate when Internet CT makes sense and when it might > not. For instance, the point that if a feature context has > information that took many exchanges and/or computation to set > up, it is a better candidate. Frequency of change of features > would affect when CT is a good choice. The goal is not > to make any evaluations, but to give a problem space for the > protocol design work to come. > > How can the problem be described so that designers and eventual > deployers can distinguish between optimizations that > provide benefits > only in narrowly constrained network circumstances and designs > that provide broad enough benefits to be used at Internet level. > > 3. Security considerations - the point about the sensitivity of > information carried in the CT is good, but the point about > CT not raising new security concerns is too much of a leap. > Even with the good design point of having the MN work but just > have a slower handoff when CT fails, there are risks to net and > nodes. Examples thought of quickly: > > Malicious context transferrors that give incorrect but > information that is not malformed, and damage/alter the MN's > connectivity > > Malicious CT requests causing DoS to the Forwarding Nodes that > have to process them. > > These are from quick thought. A safer comment would be that CT > probably will have novel security and requirements and design will > have to address. Check out draft-rescorla-cons-03.txt for more > ideas for the requirements phase. > > Thanks, > > Allison > > > > > > ------_=_NextPart_001_01C0ED03.93334730 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments Re: [seamoby] ct problem statement

Hello Allison:

  There were no comments, that I took note of, = on the email list.
There was some general debate within the ct dt = around some of the issues,
including the ones you have raised.

  I believe you are asking for some changes to = the problem statement before it can be submitted to the IESG. I will = endeavour to make the changes, after

consulting with the wg.

  Your first point makes sense to add - it would = seem one of those situations where we (the dt) all understood the = circumstances for use of ct, and did not think it needed expounding = upon. The trick will be to put it into general terms.

  The second point troubles me somewhat: ct is = essentially an information transfer operation. I do not understand (and = I can only state this as my being confusion) why it is not enough to = say that this information transfer

must be secure. Why would a ct be any different from = any other data transfer that needs to be secured?

  I personally don't see any new = vulnerabilities; based upon my superficial understanding of security, I = read the examples you have provided as specific instances of general = security problems which I understood to have been addressed. In other = words, how are these scenarios not already addressed by the existing = security solutions?

  I am not against providing security for ct - = not at all. However, I do want to ensure that security remains an = option to the operator (and is not build into the protocol), the = overhead imparted the ct can be minimized, and the performance goals = attained.

 
   I am sure the wg will have input on the = security issue, and the security section will be enhanced, I am = uncomfortable with that idea that ct has novel requirements.

Thank you for the response,
Gary


> -----Original Message-----
> From: Allison Mankin [mailto:mankin@isi.edu]
> Sent: Friday, June 01, 2001 9:21 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'; 'Pat Calhoun'; = sob@harvard.edu
> Subject: Comments Re: [seamoby] ct problem = statement
>
>
> Hi, Gary,
>
> > Pat:
> > 
> >  I'm afraid to ask, but I must. = What's up with the ct
> problem statement?
> > 
> > Gary
>
> Since Pat said he'd consult the ADs to answer = this:
>
> I note that the WG last call on the CT problem = statement ended two
> days ago.  Were there issues brought up to = any of the authors or
> in the design team mailing list?  The = working group list did
> not surface
> any, that I saw, so I'll surface some that = should be addressed before
> we put the draft forward for = advancement:
>
>
> 1. The draft is very concise and easy to read - = you want to spoil
>    us in the IESG by continuing = this good trend by Seamoby (in the
>    footsteps of the paging = problem statement)?  [Needless
>    to say, this is _not_ an = issue :> ]
>
> 2. I would like to see some discussion of the = problem space of
>    how to evaluate when Internet = CT makes sense and when it might
>    not.  For instance, the = point that if a feature context has
>    information that took many = exchanges and/or computation to set
>    up, it is a better = candidate.  Frequency of change of features
>    would affect when CT is a = good choice.   The goal is not
>    to make any evaluations, but = to give a problem space for the
>    protocol design work to = come. 
>
>    How can the problem be = described so that designers and eventual
>    deployers can distinguish = between optimizations that
> provide benefits
>    only in narrowly constrained = network circumstances and designs
>    that provide broad enough = benefits to be used at Internet level.
>
> 3. Security considerations - the point about = the sensitivity of
>    information carried in the CT = is good, but the point about
>    CT not raising new security = concerns is too much of a leap. 
>    Even with the good design = point of having the MN work but just
>    have a slower handoff when CT = fails, there are risks to net and
>    nodes.  Examples thought = of quickly: 
>
>      Malicious context = transferrors that give incorrect but
>      information that = is not malformed, and damage/alter the MN's
>      = connectivity
>
>      Malicious CT = requests causing DoS to the Forwarding Nodes that
>      have to process = them.
>
>    These are from quick = thought.  A safer comment would be that CT
>    probably will have novel = security and requirements and design will
>    have to address.  Check = out draft-rescorla-cons-03.txt for more
>    ideas for the requirements = phase.
>
> Thanks,
>
> Allison
>   
>
>
>
> 
>

------_=_NextPart_001_01C0ED03.93334730-- From owner-seamoby@diameter.org Mon Jun 4 11:54:31 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10904 for ; Mon, 4 Jun 2001 11:54:30 -0400 (EDT) Received: (qmail 11129 invoked by alias); 4 Jun 2001 15:42:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11123 invoked by uid 200); 4 Jun 2001 15:42:35 -0000 Received: (qmail 11116 invoked from network); 4 Jun 2001 15:42:32 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 15:42:32 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f54FVZ518323; Mon, 4 Jun 2001 08:31:36 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHH17328; Mon, 4 Jun 2001 08:33:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09279; Mon, 4 Jun 2001 08:33:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15131.43570.42842.928382@thomasm-u1.cisco.com> Date: Mon, 4 Jun 2001 08:33:06 -0700 (PDT) To: "Gary Kenward" Cc: "'mankin@isi.edu'" , "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5C7F@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5C7F@zcard031.ca.nortel.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 Gary Kenward writes: > The second point troubles me somewhat: ct is essentially an information > transfer operation. I do not understand (and I can only state this as my > being confusion) why it is not enough to say that this information transfer > must be secure. Why would a ct be any different from any other data transfer > that needs to be secured? > > I personally don't see any new vulnerabilities; based upon my superficial > understanding of security, I read the examples you have provided as specific > instances of general security problems which I understood to have been > addressed. In other words, how are these scenarios not already addressed by > the existing security solutions? > > I am not against providing security for ct - not at all. However, I do > want to ensure that security remains an option to the operator (and is not > build into the protocol), the overhead imparted the ct can be minimized, and > the performance goals attained. Anything that transfers keys of any kind cannot be done "at the operator's option". There are also privacy issues which must be preserved for the MN as well. At a base level, any transfer of context must be at least as secure the mechanisms the MN and AR used to create the original context. Anything less is a breach to the MN. Mike From owner-seamoby@diameter.org Mon Jun 4 12:02:11 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11227 for ; Mon, 4 Jun 2001 12:02:08 -0400 (EDT) Received: (qmail 11654 invoked by alias); 4 Jun 2001 15:50:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11648 invoked by uid 200); 4 Jun 2001 15:50:20 -0000 Received: (qmail 11643 invoked from network); 4 Jun 2001 15:50:18 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 15:50:18 -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 JAA13898; Mon, 4 Jun 2001 09:00:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f54G0BP31512; Mon, 4 Jun 2001 09:00:11 -0700 X-mProtect: Mon, 4 Jun 2001 09:00:11 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmkaWLL; Mon, 04 Jun 2001 09:00:09 PDT Message-ID: <3B1BB089.DD6BB430@iprg.nokia.com> Date: Mon, 04 Jun 2001 09:00:09 -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: Gary Kenward CC: "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <9FBD322B7824D511B36900508BF93C9C9F5C7F@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, > The second point troubles me somewhat: ct is essentially an information > transfer operation. I do not understand (and I can only state this as my being > confusion) why it is not enough to say that this information transfer > must be secure. Why would a ct be any different from any other data transfer > that needs to be secured? Some features (e.g., QoS or security associations) that might be handled as part of the context transfer mechanism should be transferred only upon assurance that the requester has at least some implicit authorization to make the request. Regards, Charlie P. > I personally don't see any new vulnerabilities; based upon my superficial > understanding of security, I read the examples you have provided as specific > instances of general security problems which I understood to have been > addressed. In other words, how are these scenarios not already addressed by > the existing security solutions? > > I am not against providing security for ct - not at all. However, I do want > to ensure that security remains an option to the operator (and is not build > into the protocol), the overhead imparted the ct can be minimized, and the > performance goals attained. > > > I am sure the wg will have input on the security issue, and the security > section will be enhanced, I am uncomfortable with that idea that ct has novel > requirements. > > Thank you for the response, > Gary > > > -----Original Message----- > > From: Allison Mankin [mailto:mankin@isi.edu] > > Sent: Friday, June 01, 2001 9:21 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > > Subject: Comments Re: [seamoby] ct problem statement > > > > > > Hi, Gary, > > > > > Pat: > > > > > > I'm afraid to ask, but I must. What's up with the ct > > problem statement? > > > > > > Gary > > > > Since Pat said he'd consult the ADs to answer this: > > > > I note that the WG last call on the CT problem statement ended two > > days ago. Were there issues brought up to any of the authors or > > in the design team mailing list? The working group list did > > not surface > > any, that I saw, so I'll surface some that should be addressed before > > we put the draft forward for advancement: > > > > > > 1. The draft is very concise and easy to read - you want to spoil > > us in the IESG by continuing this good trend by Seamoby (in the > > footsteps of the paging problem statement)? [Needless > > to say, this is _not_ an issue :> ] > > > > 2. I would like to see some discussion of the problem space of > > how to evaluate when Internet CT makes sense and when it might > > not. For instance, the point that if a feature context has > > information that took many exchanges and/or computation to set > > up, it is a better candidate. Frequency of change of features > > would affect when CT is a good choice. The goal is not > > to make any evaluations, but to give a problem space for the > > protocol design work to come. > > > > How can the problem be described so that designers and eventual > > deployers can distinguish between optimizations that > > provide benefits > > only in narrowly constrained network circumstances and designs > > that provide broad enough benefits to be used at Internet level. > > > > 3. Security considerations - the point about the sensitivity of > > information carried in the CT is good, but the point about > > CT not raising new security concerns is too much of a leap. > > Even with the good design point of having the MN work but just > > have a slower handoff when CT fails, there are risks to net and > > nodes. Examples thought of quickly: > > > > Malicious context transferrors that give incorrect but > > information that is not malformed, and damage/alter the MN's > > connectivity > > > > Malicious CT requests causing DoS to the Forwarding Nodes that > > have to process them. > > > > These are from quick thought. A safer comment would be that CT > > probably will have novel security and requirements and design will > > have to address. Check out draft-rescorla-cons-03.txt for more > > ideas for the requirements phase. > > > > Thanks, > > > > Allison > > > > > > > > > > > > From owner-seamoby@diameter.org Mon Jun 4 12:23:38 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11824 for ; Mon, 4 Jun 2001 12:22:42 -0400 (EDT) Received: (qmail 12216 invoked by alias); 4 Jun 2001 16:08:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12210 invoked by uid 200); 4 Jun 2001 16:08:10 -0000 Received: (qmail 12205 invoked from network); 4 Jun 2001 16:08:07 -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; 4 Jun 2001 16:08:07 -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 f54GHqE07596 for ; Mon, 4 Jun 2001 12:17:52 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Jun 2001 12:17:24 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 12:17:31 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C85@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'mankin@isi.edu'" , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 12:17:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED11.E0195F40" 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_01C0ED11.E0195F40 Content-Type: text/plain; charset="ISO-8859-1" I agree Charlie, but how is this different from other data transfers requiring explicit authentication and authorization? Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Monday, June 04, 2001 12:00 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'mankin@isi.edu'; 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > Hello Gary, > > > The second point troubles me somewhat: ct is essentially > an information > > transfer operation. I do not understand (and I can only > state this as my being > > confusion) why it is not enough to say that this > information transfer > > must be secure. Why would a ct be any different from any > other data transfer > > that needs to be secured? > > Some features (e.g., QoS or security associations) that might > be handled > as part of the context transfer mechanism should be > transferred only upon > assurance that the requester has at least some implicit > authorization to > make the request. > > Regards, > Charlie P. > > > > I personally don't see any new vulnerabilities; based > upon my superficial > > understanding of security, I read the examples you have > provided as specific > > instances of general security problems which I understood > to have been > > addressed. In other words, how are these scenarios not > already addressed by > > the existing security solutions? > > > > I am not against providing security for ct - not at all. > However, I do want > > to ensure that security remains an option to the operator > (and is not build > > into the protocol), the overhead imparted the ct can be > minimized, and the > > performance goals attained. > > > > > > I am sure the wg will have input on the security issue, > and the security > > section will be enhanced, I am uncomfortable with that idea > that ct has novel > > requirements. > > > > Thank you for the response, > > Gary > > > > > -----Original Message----- > > > From: Allison Mankin [mailto:mankin@isi.edu] > > > Sent: Friday, June 01, 2001 9:21 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > > > Subject: Comments Re: [seamoby] ct problem statement > > > > > > > > > Hi, Gary, > > > > > > > Pat: > > > > > > > > I'm afraid to ask, but I must. What's up with the ct > > > problem statement? > > > > > > > > Gary > > > > > > Since Pat said he'd consult the ADs to answer this: > > > > > > I note that the WG last call on the CT problem statement ended two > > > days ago. Were there issues brought up to any of the authors or > > > in the design team mailing list? The working group list did > > > not surface > > > any, that I saw, so I'll surface some that should be > addressed before > > > we put the draft forward for advancement: > > > > > > > > > 1. The draft is very concise and easy to read - you want to spoil > > > us in the IESG by continuing this good trend by Seamoby (in the > > > footsteps of the paging problem statement)? [Needless > > > to say, this is _not_ an issue :> ] > > > > > > 2. I would like to see some discussion of the problem space of > > > how to evaluate when Internet CT makes sense and when it might > > > not. For instance, the point that if a feature context has > > > information that took many exchanges and/or computation to set > > > up, it is a better candidate. Frequency of change of features > > > would affect when CT is a good choice. The goal is not > > > to make any evaluations, but to give a problem space for the > > > protocol design work to come. > > > > > > How can the problem be described so that designers and eventual > > > deployers can distinguish between optimizations that > > > provide benefits > > > only in narrowly constrained network circumstances and designs > > > that provide broad enough benefits to be used at > Internet level. > > > > > > 3. Security considerations - the point about the sensitivity of > > > information carried in the CT is good, but the point about > > > CT not raising new security concerns is too much of a leap. > > > Even with the good design point of having the MN work but just > > > have a slower handoff when CT fails, there are risks to net and > > > nodes. Examples thought of quickly: > > > > > > Malicious context transferrors that give incorrect but > > > information that is not malformed, and damage/alter the MN's > > > connectivity > > > > > > Malicious CT requests causing DoS to the Forwarding > Nodes that > > > have to process them. > > > > > > These are from quick thought. A safer comment would be that CT > > > probably will have novel security and requirements and > design will > > > have to address. Check out draft-rescorla-cons-03.txt for more > > > ideas for the requirements phase. > > > > > > Thanks, > > > > > > Allison > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0ED11.E0195F40 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement

I agree Charlie, but how is this different from other
data transfers requiring explicit authentication and authorization?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Monday, June 04, 2001 12:00 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'mankin@isi.edu'; 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
>
>
>
> Hello Gary,
>
> >   The second point troubles me somewhat: ct is essentially
> an information
> > transfer operation. I do not understand (and I can only
> state this as my being
> > confusion) why it is not enough to say that this
> information transfer
> > must be secure. Why would a ct be any different from any
> other data transfer
> > that needs to be secured?
>
> Some features (e.g., QoS or security associations) that might
> be handled
> as part of the context transfer mechanism should be
> transferred only upon
> assurance that the requester has at least some implicit
> authorization to
> make the request.
>
> Regards,
> Charlie P.
>
>
> >   I personally don't see any new vulnerabilities; based
> upon my superficial
> > understanding of security, I read the examples you have
> provided as specific
> > instances of general security problems which I understood
> to have been
> > addressed. In other words, how are these scenarios not
> already addressed by
> > the existing security solutions?
> >
> >   I am not against providing security for ct - not at all.
> However, I do want
> > to ensure that security remains an option to the operator
> (and is not build
> > into the protocol), the overhead imparted the ct can be
> minimized, and the
> > performance goals attained.
> >
> >
> >    I am sure the wg will have input on the security issue,
> and the security
> > section will be enhanced, I am uncomfortable with that idea
> that ct has novel
> > requirements.
> >
> > Thank you for the response,
> > Gary
> >
> > > -----Original Message-----
> > > From: Allison Mankin [mailto:mankin@isi.edu]
> > > Sent: Friday, June 01, 2001 9:21 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
> > > Subject: Comments Re: [seamoby] ct problem statement
> > >
> > >
> > > Hi, Gary,
> > >
> > > > Pat:
> > > >
> > > >  I'm afraid to ask, but I must. What's up with the ct
> > > problem statement?
> > > >
> > > > Gary
> > >
> > > Since Pat said he'd consult the ADs to answer this:
> > >
> > > I note that the WG last call on the CT problem statement ended two
> > > days ago.  Were there issues brought up to any of the authors or
> > > in the design team mailing list?  The working group list did
> > > not surface
> > > any, that I saw, so I'll surface some that should be
> addressed before
> > > we put the draft forward for advancement:
> > >
> > >
> > > 1. The draft is very concise and easy to read - you want to spoil
> > >    us in the IESG by continuing this good trend by Seamoby (in the
> > >    footsteps of the paging problem statement)?  [Needless
> > >    to say, this is _not_ an issue :> ]
> > >
> > > 2. I would like to see some discussion of the problem space of
> > >    how to evaluate when Internet CT makes sense and when it might
> > >    not.  For instance, the point that if a feature context has
> > >    information that took many exchanges and/or computation to set
> > >    up, it is a better candidate.  Frequency of change of features
> > >    would affect when CT is a good choice.   The goal is not
> > >    to make any evaluations, but to give a problem space for the
> > >    protocol design work to come.
> > >
> > >    How can the problem be described so that designers and eventual
> > >    deployers can distinguish between optimizations that
> > > provide benefits
> > >    only in narrowly constrained network circumstances and designs
> > >    that provide broad enough benefits to be used at
> Internet level.
> > >
> > > 3. Security considerations - the point about the sensitivity of
> > >    information carried in the CT is good, but the point about
> > >    CT not raising new security concerns is too much of a leap.
> > >    Even with the good design point of having the MN work but just
> > >    have a slower handoff when CT fails, there are risks to net and
> > >    nodes.  Examples thought of quickly:
> > >
> > >      Malicious context transferrors that give incorrect but
> > >      information that is not malformed, and damage/alter the MN's
> > >      connectivity
> > >
> > >      Malicious CT requests causing DoS to the Forwarding
> Nodes that
> > >      have to process them.
> > >
> > >    These are from quick thought.  A safer comment would be that CT
> > >    probably will have novel security and requirements and
> design will
> > >    have to address.  Check out draft-rescorla-cons-03.txt for more
> > >    ideas for the requirements phase.
> > >
> > > Thanks,
> > >
> > > Allison
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C0ED11.E0195F40-- From owner-seamoby@diameter.org Mon Jun 4 12:30:57 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11983 for ; Mon, 4 Jun 2001 12:30:50 -0400 (EDT) Received: (qmail 12753 invoked by alias); 4 Jun 2001 16:18:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12747 invoked by uid 200); 4 Jun 2001 16:18:20 -0000 Received: (qmail 12742 invoked from network); 4 Jun 2001 16:18:18 -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; 4 Jun 2001 16:18:18 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f54GS2E08822 for ; Mon, 4 Jun 2001 12:28:02 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 4 Jun 2001 12:27:49 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 12:27:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C86@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" Cc: "'mankin@isi.edu'" , "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 12:28:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED13.5542DA20" 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_01C0ED13.5542DA20 Content-Type: text/plain; charset="ISO-8859-1" Well, to begin with, "at the operators option" would include the option to provide privacy or not to the service users. In a competitive environment, the user could then decide whether to subscribe to the service or not, if that privacy was not provided. As for securing "keys" (which is necessary to maintain the committed level of security that operator has chosen to support), as been discussed repeatedly on this list, no one has suggesting transferring keys openly. What I stated was that I do not understand where the requirements for CT differ from any other secure data transfer between peers. Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, June 04, 2001 11:33 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > The second point troubles me somewhat: ct is essentially > an information > > transfer operation. I do not understand (and I can only > state this as my > > being confusion) why it is not enough to say that this > information transfer > > must be secure. Why would a ct be any different from any > other data transfer > > that needs to be secured? > > > > I personally don't see any new vulnerabilities; based > upon my superficial > > understanding of security, I read the examples you have > provided as specific > > instances of general security problems which I understood > to have been > > addressed. In other words, how are these scenarios not > already addressed by > > the existing security solutions? > > > > I am not against providing security for ct - not at all. > However, I do > > want to ensure that security remains an option to the > operator (and is not > > build into the protocol), the overhead imparted the ct can > be minimized, and > > the performance goals attained. > > Anything that transfers keys of any kind cannot be > done "at the operator's option". There are also > privacy issues which must be preserved for the MN > as well. At a base level, any transfer of context > must be at least as secure the mechanisms the > MN and AR used to create the original context. > Anything less is a breach to the MN. > > Mike > ------_=_NextPart_001_01C0ED13.5542DA20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments Re: [seamoby] ct problem statement

Well, to begin with, "at the operators = option" would include
the option to provide privacy or not to the service = users. In
a competitive environment, the user could then = decide whether to
subscribe to the service or not, if that privacy was = not provided.

As for securing "keys" (which is necessary = to maintain the committed
level of security that operator has chosen to = support), as been discussed repeatedly on this list, no one has = suggesting transferring keys openly. What I stated was that I do not = understand where the requirements for CT differ from any other secure = data transfer between peers.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 04, 2001 11:33 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; = sob@harvard.edu
> Subject: RE: Comments Re: [seamoby] ct problem = statement
>
>
> Gary Kenward writes:
>  >   The second point = troubles me somewhat: ct is essentially
> an information
>  > transfer operation. I do not = understand (and I can only
> state this as my
>  > being confusion) why it is not = enough to say that this
> information transfer
>  > must be secure. Why would a ct be = any different from any
> other data transfer
>  > that needs to be secured?
>  >
>  >   I personally don't see = any new vulnerabilities; based
> upon my superficial
>  > understanding of security, I read = the examples you have
> provided as specific
>  > instances of general security = problems which I understood
> to have been
>  > addressed. In other words, how are = these scenarios not
> already addressed by
>  > the existing security = solutions?
>  >
>  >   I am not against = providing security for ct - not at all.
> However, I do
>  > want to ensure that security remains = an option to the
> operator (and is not
>  > build into the protocol), the = overhead imparted the ct can
> be minimized, and
>  > the performance goals = attained.
>
>    Anything that transfers keys = of any kind cannot be
>    done "at the operator's = option". There are also
>    privacy issues which must be = preserved for the MN
>    as well. At a base level, any = transfer of context
>    must be at least as secure = the mechanisms the
>    MN and AR used to create the = original context.
>    Anything less is a breach to = the MN.
>
>       =     Mike
>

------_=_NextPart_001_01C0ED13.5542DA20-- From owner-seamoby@diameter.org Mon Jun 4 13:00:53 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12730 for ; Mon, 4 Jun 2001 12:57:47 -0400 (EDT) Received: (qmail 13480 invoked by alias); 4 Jun 2001 16:40:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13474 invoked by uid 200); 4 Jun 2001 16:40:12 -0000 Received: (qmail 13469 invoked from network); 4 Jun 2001 16:40:10 -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; 4 Jun 2001 16:40:10 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f54GntE12074 for ; Mon, 4 Jun 2001 12:49:55 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 4 Jun 2001 12:49:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 12:49:46 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C88@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 12:49:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED16.5FD657C0" 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_01C0ED16.5FD657C0 Content-Type: text/plain; charset="ISO-8859-1" So, instead, we want to develop solutions for the "good of the operator", whether they are willing to pay for it or not? A moot point, really, for if an operator does not want a feature, they simply have to find a manufacturer who is willing to provide the capability to the feature off. Let's move on. Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, June 04, 2001 12:39 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Michael Thomas'; 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; > sob@harvard.edu > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > Well, to begin with, "at the operators option" would include > > the option to provide privacy or not to the service users. In > > a competitive environment, the user could then decide whether to > > subscribe to the service or not, if that privacy was not provided. > > The problem is that a user has no way of knowing. > > > As for securing "keys" (which is necessary to maintain the > committed > > level of security that operator has chosen to support), as > been discussed > > repeatedly on this list, no one has suggesting > transferring keys openly. > > What I stated was that I do not understand where the > requirements for CT > > differ from any other secure data transfer between peers. > > Stating in the problem statement, requirements, > or the protocol itself that an operator can > administratively turn off security _at all_ > sends a very bad message. As in, vendors won't > bother implementing it since it's not required, > and operators won't bother turning it on since > it's a hassle and RFC nnnn says that's OK. > > We really do not need to go there. > > Mike > > > > Gary > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Monday, June 04, 2001 11:33 AM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > > > > Gary Kenward writes: > > > > The second point troubles me somewhat: ct is essentially > > > an information > > > > transfer operation. I do not understand (and I can only > > > state this as my > > > > being confusion) why it is not enough to say that this > > > information transfer > > > > must be secure. Why would a ct be any different from any > > > other data transfer > > > > that needs to be secured? > > > > > > > > I personally don't see any new vulnerabilities; based > > > upon my superficial > > > > understanding of security, I read the examples you have > > > provided as specific > > > > instances of general security problems which I understood > > > to have been > > > > addressed. In other words, how are these scenarios not > > > already addressed by > > > > the existing security solutions? > > > > > > > > I am not against providing security for ct - not at all. > > > However, I do > > > > want to ensure that security remains an option to the > > > operator (and is not > > > > build into the protocol), the overhead imparted the ct can > > > be minimized, and > > > > the performance goals attained. > > > > > > Anything that transfers keys of any kind cannot be > > > done "at the operator's option". There are also > > > privacy issues which must be preserved for the MN > > > as well. At a base level, any transfer of context > > > must be at least as secure the mechanisms the > > > MN and AR used to create the original context. > > > Anything less is a breach to the MN. > > > > > > Mike > > > > > > > > > > > > > > > RE: Comments Re: [seamoby] ct problem statement > > > > > > > >

Well, to begin with, "at the > operators option" would include > >
the option to provide privacy or not to > the service users. In > >
a competitive environment, the user could > then decide whether to > >
subscribe to the service or not, if that > privacy was not provided. > >

> > > >

As for securing "keys" (which is > necessary to maintain the committed > >
level of security that operator has > chosen to support), as been discussed repeatedly on this > list, no one has suggesting transferring keys openly. What I > stated was that I do not understand where the requirements > for CT differ from any other secure data transfer between > peers.

> > > >

Gary > >

> > > >

> -----Original Message----- > >
> From: Michael Thomas [ HREF="mailto:mat@cisco.com">mailto:mat@cisco.com] > >
> Sent: Monday, June 04, 2001 11:33 AM > >
> To: Kenward, Gary [WDLN2:AN10:EXCH] > >
> Cc: 'mankin@isi.edu'; 'seamoby'; > 'Pat Calhoun'; sob@harvard.edu > >
> Subject: RE: Comments Re: [seamoby] > ct problem statement > >
> > >
> > >
> Gary Kenward writes: > >
>  >   The second > point troubles me somewhat: ct is essentially > >
> an information > >
>  > transfer operation. I do > not understand (and I can only > >
> state this as my > >
>  > being confusion) why it > is not enough to say that this > >
> information transfer > >
>  > must be secure. Why would > a ct be any different from any > >
> other data transfer > >
>  > that needs to be secured? > >
>  > > >
>  >   I personally > don't see any new vulnerabilities; based > >
> upon my superficial > >
>  > understanding of > security, I read the examples you have > >
> provided as specific > >
>  > instances of general > security problems which I understood > >
> to have been > >
>  > addressed. In other > words, how are these scenarios not > >
> already addressed by > >
>  > the existing security > solutions? > >
>  > > >
>  >   I am not > against providing security for ct - not at all. > >
> However, I do > >
>  > want to ensure that > security remains an option to the > >
> operator (and is not > >
>  > build into the protocol), > the overhead imparted the ct can > >
> be minimized, and > >
>  > the performance goals > attained. > >
> > >
>    Anything that > transfers keys of any kind cannot be > >
>    done "at the > operator's option". There are also > >
>    privacy issues > which must be preserved for the MN > >
>    as well. At a base > level, any transfer of context > >
>    must be at least > as secure the mechanisms the > >
>    MN and AR used to > create the original context. > >
>    Anything less is a > breach to the MN. > >
> > >
>       >     Mike > >
> > >

> > > > > > > ------_=_NextPart_001_01C0ED16.5FD657C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments Re: [seamoby] ct problem statement

So, instead, we want to develop solutions for the = "good of the operator",
whether they are willing to pay for it or = not?

A moot point, really, for if an operator does not = want a feature, they simply have to find a manufacturer who is willing = to provide the capability to the feature off.

Let's move on.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 04, 2001 12:39 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; 'mankin@isi.edu'; = 'seamoby'; 'Pat Calhoun';
> sob@harvard.edu
> Subject: RE: Comments Re: [seamoby] ct problem = statement
>
>
> Gary Kenward writes:
>  > Well, to begin with, "at the = operators option" would include
>  > the option to provide privacy or not = to the service users. In
>  > a competitive environment, the user = could then decide whether to
>  > subscribe to the service or not, if = that privacy was not provided.
>
>    The problem is that a user = has no way of knowing.
>
>  > As for securing "keys" = (which is necessary to maintain the
> committed
>  > level of security that operator has = chosen to support), as
> been discussed
>  > repeatedly on this list, no one has = suggesting
> transferring keys openly.
>  > What I stated was that I do not = understand where the
> requirements for CT
>  > differ from any other secure data = transfer between peers.
>
>    Stating in the problem = statement, requirements,
>    or the protocol itself that = an operator can
>    administratively turn off = security _at all_
>    sends a very bad message. As = in, vendors won't
>    bother implementing it since = it's not required,
>    and operators won't bother = turning it on since
>    it's a hassle and RFC nnnn = says that's OK.
>   
>    We really do not need to go = there.
>
>       Mike
>  >
>  > Gary
>  >
>  > > -----Original = Message-----
>  > > From: Michael Thomas [mailto:mat@cisco.com]
>  > > Sent: Monday, June 04, 2001 = 11:33 AM
>  > > To: Kenward, Gary = [WDLN2:AN10:EXCH]
>  > > Cc: 'mankin@isi.edu'; = 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
>  > > Subject: RE: Comments Re: = [seamoby] ct problem statement
>  > >
>  > >
>  > > Gary Kenward writes:
>  > >  >   The = second point troubles me somewhat: ct is essentially
>  > > an information
>  > >  > transfer operation. = I do not understand (and I can only
>  > > state this as my
>  > >  > being confusion) why = it is not enough to say that this
>  > > information transfer
>  > >  > must be secure. Why = would a ct be any different from any
>  > > other data transfer
>  > >  > that needs to be = secured?
>  > >  >
>  > >  >   I = personally don't see any new vulnerabilities; based
>  > > upon my superficial
>  > >  > understanding of = security, I read the examples you have
>  > > provided as specific
>  > >  > instances of general = security problems which I understood
>  > > to have been
>  > >  > addressed. In other = words, how are these scenarios not
>  > > already addressed by
>  > >  > the existing = security solutions?
>  > >  >
>  > >  >   I am not = against providing security for ct - not at all.
>  > > However, I do
>  > >  > want to ensure that = security remains an option to the
>  > > operator (and is not
>  > >  > build into the = protocol), the overhead imparted the ct can
>  > > be minimized, and
>  > >  > the performance = goals attained.
>  > >
>  > >    Anything that = transfers keys of any kind cannot be
>  > >    done "at = the operator's option". There are also
>  > >    privacy = issues which must be preserved for the MN
>  > >    as well. At a = base level, any transfer of context
>  > >    must be at = least as secure the mechanisms the
>  > >    MN and AR = used to create the original context.
>  > >    Anything less = is a breach to the MN.
>  > >
>  > >      = Mike
>  > >
>  > <!DOCTYPE HTML PUBLIC = "-//W3C//DTD HTML 3.2//EN">
>  > <HTML>
>  > <HEAD>
>  > <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3DISO-8859-1">
>  > <META = NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2654.59">
>  > <TITLE>RE: Comments Re: = [seamoby] ct problem statement</TITLE>
>  > </HEAD>
>  > <BODY>
>  >
>  > <P><FONT SIZE=3D2>Well, = to begin with, &quot;at the
> operators option&quot; would = include</FONT>
>  > <BR><FONT SIZE=3D2>the = option to provide privacy or not to
> the service users. In</FONT>
>  > <BR><FONT SIZE=3D2>a = competitive environment, the user could
> then decide whether to</FONT>
>  > <BR><FONT = SIZE=3D2>subscribe to the service or not, if that
> privacy was not provided.</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=3D2>As for = securing &quot;keys&quot; (which is
> necessary to maintain the = committed</FONT>
>  > <BR><FONT SIZE=3D2>level = of security that operator has
> chosen to support), as been discussed = repeatedly on this
> list, no one has suggesting transferring keys = openly. What I
> stated was that I do not understand where the = requirements
> for CT differ from any other secure data = transfer between
> peers.</FONT></P>
>  >
>  > <P><FONT = SIZE=3D2>Gary</FONT>
>  > </P>
>  >
>  > <P><FONT = SIZE=3D2>&gt; -----Original Message-----</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; From: Michael Thomas [<A
> HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FO= NT>
>  > <BR><FONT = SIZE=3D2>&gt; Sent: Monday, June 04, 2001 11:33 = AM</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; To: Kenward, Gary = [WDLN2:AN10:EXCH]</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; Cc: 'mankin@isi.edu'; 'seamoby';
> 'Pat Calhoun'; = sob@harvard.edu</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; Subject: RE: Comments Re: [seamoby]
> ct problem statement</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; Gary Kenward writes:</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp; The second =
> point troubles me somewhat: ct is essentially = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; an information</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; transfer operation. I do =
> not understand (and I can only = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; state this as my</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; being confusion) why it
> is not enough to say that this = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; information transfer</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; must be secure. Why would =
> a ct be any different from any = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; other data transfer</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; that needs to be secured? = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp; I = personally
> don't see any new vulnerabilities; based = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; upon my superficial</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; understanding of
> security, I read the examples you have = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; provided as specific</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; instances of general
> security problems which I understood = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; to have been</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; addressed. In other
> words, how are these scenarios not = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; already addressed by</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; the existing security
> solutions?</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp; I am not =
> against providing security for ct - not at all. = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; However, I do</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; want to ensure that
> security remains an option to the = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; operator (and is not</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; build into the protocol), =
> the overhead imparted the ct can = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; be minimized, and</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp; &gt; the performance goals
> attained.</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Anything that =
> transfers keys of any kind cannot = be</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; done &quot;at = the
> operator's option&quot;. There are = also</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; privacy issues =
> which must be preserved for the = MN</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; as well. At a base =
> level, any transfer of = context</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; must be at least =
> as secure the mechanisms = the</FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; MN and AR used to =
> create the original context. = </FONT>
>  > <BR><FONT = SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Anything less is a =
> breach to the MN.</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; </FONT>
>  > <BR><FONT = SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp; = Mike</FONT>
>  > <BR><FONT = SIZE=3D2>&gt; </FONT>
>  > </P>
>  >
>  > </BODY>
>  > </HTML>
>

------_=_NextPart_001_01C0ED16.5FD657C0-- From owner-seamoby@diameter.org Mon Jun 4 13:21:56 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13526 for ; Mon, 4 Jun 2001 13:21:55 -0400 (EDT) Received: (qmail 14311 invoked by alias); 4 Jun 2001 17:08:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14305 invoked by uid 200); 4 Jun 2001 17:08:48 -0000 Received: (qmail 14300 invoked from network); 4 Jun 2001 17:08:46 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 17:08:46 -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 f54HGL920681; Mon, 4 Jun 2001 10:16:21 -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 AHJ00380; Mon, 4 Jun 2001 10:16:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09297; Mon, 4 Jun 2001 10:16:14 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15131.49758.850075.515326@thomasm-u1.cisco.com> Date: Mon, 4 Jun 2001 10:16:14 -0700 (PDT) To: "Gary Kenward" Cc: "'Michael Thomas'" , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5C88@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5C88@zcard031.ca.nortel.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 Gary Kenward writes: > So, instead, we want to develop solutions for the "good of the operator", > whether they are willing to pay for it or not? There are any number of ways that a shoddy operator can find to provide shoddy service. The IETF doesn't need to provide helpful hints. > A moot point, really, for if an operator does not want a feature, they > simply have to find a manufacturer who is willing to provide the capability > to the feature off. > > Let's move on. No, let's not. The *user* figures in here too, and the resulting RFC's should not allow for equivocation on this. Mike From owner-seamoby@diameter.org Mon Jun 4 13:51:00 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14393 for ; Mon, 4 Jun 2001 13:50:57 -0400 (EDT) Received: (qmail 14996 invoked by alias); 4 Jun 2001 17:39:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14990 invoked by uid 200); 4 Jun 2001 17:39:15 -0000 Received: (qmail 14985 invoked from network); 4 Jun 2001 17:39:13 -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; 4 Jun 2001 17:39:13 -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 f54HmwE22600 for ; Mon, 4 Jun 2001 13:48:58 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Jun 2001 13:48:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 13:48:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C8C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Michael Thomas'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 13:49:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED1E.A3517400" 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_01C0ED1E.A3517400 Content-Type: text/plain; charset="ISO-8859-1" The user must be considered, but while you consider an operator that does not provide privacy as "shoddy", I (and others), consider efficient and responsive to their customers. I do not want to pay for a service that I do not need. Gary > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, June 04, 2001 1:16 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Michael Thomas'; 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > So, instead, we want to develop solutions for the "good of > the operator", > > whether they are willing to pay for it or not? > > There are any number of ways that a shoddy operator > can find to provide shoddy service. The IETF doesn't > need to provide helpful hints. > > > A moot point, really, for if an operator does not want a > feature, they > > simply have to find a manufacturer who is willing to > provide the capability > > to the feature off. > > > > Let's move on. > > No, let's not. The *user* figures in here too, and the > resulting RFC's should not allow for equivocation on this. > > Mike > ------_=_NextPart_001_01C0ED1E.A3517400 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement

The user must be considered, but while you consider an operator
that does not provide privacy as "shoddy", I (and others), consider
efficient and responsive to their customers. I do not want to pay
for a service that I do not need.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 04, 2001 1:16 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
>
>
> Gary Kenward writes:
>  > So, instead, we want to develop solutions for the "good of
> the operator",
>  > whether they are willing to pay for it or not?
>
>    There are any number of ways that a shoddy operator
>    can find to provide shoddy service. The IETF doesn't
>    need to provide helpful hints.
>
>  > A moot point, really, for if an operator does not want a
> feature, they
>  > simply have to find a manufacturer who is willing to
> provide the capability
>  > to the feature off.
>  >
>  > Let's move on.
>
>    No, let's not. The *user* figures in here too, and the
>    resulting RFC's should not allow for equivocation on this.
>
>            Mike
>

------_=_NextPart_001_01C0ED1E.A3517400-- From owner-seamoby@diameter.org Mon Jun 4 15:26:00 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16101 for ; Mon, 4 Jun 2001 15:25:58 -0400 (EDT) Received: (qmail 16384 invoked by alias); 4 Jun 2001 19:12:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16378 invoked by uid 200); 4 Jun 2001 19:12:04 -0000 Received: (qmail 16372 invoked from network); 4 Jun 2001 19:12:00 -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; 4 Jun 2001 19:12:00 -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 f54JLiE07991 for ; Mon, 4 Jun 2001 15:21:44 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Jun 2001 15:21:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 15:21:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C8E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'seamoby-context'" , "'Pat Calhoun'" , "'Allison Mankin'" Subject: [seamoby] Security Considerations - new wording Date: Mon, 4 Jun 2001 15:21:38 -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 Below is a possible new wording for section 9 of the problem statement draft. I have *tried* to write it so that it identifies the concern over ct security, and the intent to investigate requirements, while asserting that ct will use what is available first, and only if justified, attempt to develop new security solutions. Opinions welcome - contributed text preferred, please! Gary ========================================================================= 9 Security Considerations Some of the considerations for context transfer security include: - information privacy: the context may contain information which the end user would prefer to keep hidden from unauthorized viewers. - transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving forwarding node, and therefore could potentially effect the operation of the access network itself; context transfer must only occur between forwarding nodes that have an established trust relationship. - security preservation: part of the context transfer may include information pertinent to a security association established between the mobile node and another entity on the network; for this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures. It is expected that the measures used to secure the transport of information between peers in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions. The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions. From owner-seamoby@diameter.org Mon Jun 4 17:14:56 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19426 for ; Mon, 4 Jun 2001 17:14:42 -0400 (EDT) Received: (qmail 18376 invoked by alias); 4 Jun 2001 21:01:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18365 invoked by uid 200); 4 Jun 2001 21:01:00 -0000 Received: (qmail 18360 invoked from network); 4 Jun 2001 21:00:58 -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; 4 Jun 2001 21:00:58 -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 f54LAhE22307 for ; Mon, 4 Jun 2001 17:10:43 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Jun 2001 17:10:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 17:10:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B4AA@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "Gary Kenward" , "'Michael Thomas'" Cc: "'mankin@isi.edu'" , "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 17:10:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED3A.D269F7A0" 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_01C0ED3A.D269F7A0 Content-Type: text/plain; charset="ISO-8859-1" I think everyone is in agreement here but cannot see it. What Gary is stating is CT MUST be secure. How to secure it is the 64 000$ question. IMHO, we could and should re-use existing security mechanisms (e.g. IPSec, TLS). If something specific comes along that is specific to CT, we can address it at that point. But can we all agree that we don't need to re-invent a specific security solution for CT? Basically, you guys are stating that the IETF security area, with all it's experts did not do a good job designing current security solutions and that we need to re-invent the wheel once again. Bottom line, the current requirement on security should be enough. It is not possible, at this point, to figure out the details of a security mechanisms. Cheers, Louis-Nicolas -----Original Message----- From: Kenward, Gary [WDLN2:AN10:EXCH] Sent: Monday, June 04, 2001 12:28 PM To: 'Michael Thomas' Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Well, to begin with, "at the operators option" would include the option to provide privacy or not to the service users. In a competitive environment, the user could then decide whether to subscribe to the service or not, if that privacy was not provided. As for securing "keys" (which is necessary to maintain the committed level of security that operator has chosen to support), as been discussed repeatedly on this list, no one has suggesting transferring keys openly. What I stated was that I do not understand where the requirements for CT differ from any other secure data transfer between peers. Gary > -----Original Message----- > From: Michael Thomas [ mailto:mat@cisco.com ] > Sent: Monday, June 04, 2001 11:33 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > The second point troubles me somewhat: ct is essentially > an information > > transfer operation. I do not understand (and I can only > state this as my > > being confusion) why it is not enough to say that this > information transfer > > must be secure. Why would a ct be any different from any > other data transfer > > that needs to be secured? > > > > I personally don't see any new vulnerabilities; based > upon my superficial > > understanding of security, I read the examples you have > provided as specific > > instances of general security problems which I understood > to have been > > addressed. In other words, how are these scenarios not > already addressed by > > the existing security solutions? > > > > I am not against providing security for ct - not at all. > However, I do > > want to ensure that security remains an option to the > operator (and is not > > build into the protocol), the overhead imparted the ct can > be minimized, and > > the performance goals attained. > > Anything that transfers keys of any kind cannot be > done "at the operator's option". There are also > privacy issues which must be preserved for the MN > as well. At a base level, any transfer of context > must be at least as secure the mechanisms the > MN and AR used to create the original context. > Anything less is a breach to the MN. > > Mike > ------_=_NextPart_001_01C0ED3A.D269F7A0 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement
I think everyone is in agreement here but cannot see it.
 
What Gary is stating is CT MUST be secure. How to secure it is the 64 000$ question. IMHO,
we could and should re-use existing security mechanisms (e.g. IPSec, TLS). If something
specific comes along that is specific to CT, we can address it at that point.
 
But can we all agree that we don't need to re-invent a specific security solution
for CT? Basically, you guys are stating that the IETF security area, with all it's experts did not
do a good job designing current security solutions and that we need to re-invent the wheel once
again.
 
Bottom line, the current requirement on security should be enough. It is not possible, at this point,
to figure out the details of a security mechanisms.
 
Cheers,
Louis-Nicolas
 
-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH]
Sent: Monday, June 04, 2001 12:28 PM
To: 'Michael Thomas'
Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
Subject: RE: Comments Re: [seamoby] ct problem statement

Well, to begin with, "at the operators option" would include
the option to provide privacy or not to the service users. In
a competitive environment, the user could then decide whether to
subscribe to the service or not, if that privacy was not provided.

As for securing "keys" (which is necessary to maintain the committed
level of security that operator has chosen to support), as been discussed repeatedly on this list, no one has suggesting transferring keys openly. What I stated was that I do not understand where the requirements for CT differ from any other secure data transfer between peers.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 04, 2001 11:33 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
> Subject: RE: Comments Re: [seamoby] ct problem statement
>
>
> Gary Kenward writes:
>  >   The second point troubles me somewhat: ct is essentially
> an information
>  > transfer operation. I do not understand (and I can only
> state this as my
>  > being confusion) why it is not enough to say that this
> information transfer
>  > must be secure. Why would a ct be any different from any
> other data transfer
>  > that needs to be secured?
>  >
>  >   I personally don't see any new vulnerabilities; based
> upon my superficial
>  > understanding of security, I read the examples you have
> provided as specific
>  > instances of general security problems which I understood
> to have been
>  > addressed. In other words, how are these scenarios not
> already addressed by
>  > the existing security solutions?
>  >
>  >   I am not against providing security for ct - not at all.
> However, I do
>  > want to ensure that security remains an option to the
> operator (and is not
>  > build into the protocol), the overhead imparted the ct can
> be minimized, and
>  > the performance goals attained.
>
>    Anything that transfers keys of any kind cannot be
>    done "at the operator's option". There are also
>    privacy issues which must be preserved for the MN
>    as well. At a base level, any transfer of context
>    must be at least as secure the mechanisms the
>    MN and AR used to create the original context.
>    Anything less is a breach to the MN.
>
>           Mike
>

------_=_NextPart_001_01C0ED3A.D269F7A0-- From owner-seamoby@diameter.org Mon Jun 4 18:35:13 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20677 for ; Mon, 4 Jun 2001 18:35:03 -0400 (EDT) Received: (qmail 19618 invoked by alias); 4 Jun 2001 22:18:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19612 invoked by uid 200); 4 Jun 2001 22:18:50 -0000 Received: (qmail 19602 invoked from network); 4 Jun 2001 22:18:46 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 22:18:46 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 18:28:30 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FB3@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Gary Kenward'" , "'Michael Thomas'" Cc: "'mankin@isi.edu'" , "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 18:28:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED45.ABD3E190" 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_01C0ED45.ABD3E190 Content-Type: text/plain; charset="iso-8859-1" I agree. If we are already running IPSec out of band for CT, do we need to run the same security mechanism on top of the same security mechanism? If IPSec is using MD5 do we also need SCTP to use MD5 and CT to use MD5 as well? Is there not some duplication of effort here? Maybe we need to do a threat analysis in the protocol design phase to ensure we have appropriate security measures at the appropriate level. - Kulwinder. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Monday, June 04, 2001 12:28 PM To: 'Michael Thomas' Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Well, to begin with, "at the operators option" would include the option to provide privacy or not to the service users. In a competitive environment, the user could then decide whether to subscribe to the service or not, if that privacy was not provided. As for securing "keys" (which is necessary to maintain the committed level of security that operator has chosen to support), as been discussed repeatedly on this list, no one has suggesting transferring keys openly. What I stated was that I do not understand where the requirements for CT differ from any other secure data transfer between peers. Gary > -----Original Message----- > From: Michael Thomas [ mailto:mat@cisco.com ] > Sent: Monday, June 04, 2001 11:33 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > The second point troubles me somewhat: ct is essentially > an information > > transfer operation. I do not understand (and I can only > state this as my > > being confusion) why it is not enough to say that this > information transfer > > must be secure. Why would a ct be any different from any > other data transfer > > that needs to be secured? > > > > I personally don't see any new vulnerabilities; based > upon my superficial > > understanding of security, I read the examples you have > provided as specific > > instances of general security problems which I understood > to have been > > addressed. In other words, how are these scenarios not > already addressed by > > the existing security solutions? > > > > I am not against providing security for ct - not at all. > However, I do > > want to ensure that security remains an option to the > operator (and is not > > build into the protocol), the overhead imparted the ct can > be minimized, and > > the performance goals attained. > > Anything that transfers keys of any kind cannot be > done "at the operator's option". There are also > privacy issues which must be preserved for the MN > as well. At a base level, any transfer of context > must be at least as secure the mechanisms the > MN and AR used to create the original context. > Anything less is a breach to the MN. > > Mike > ------_=_NextPart_001_01C0ED45.ABD3E190 Content-Type: text/html; charset="iso-8859-1" RE: Comments Re: [seamoby] ct problem statement
I agree.
 
If we are already running IPSec out of band for CT,  do we need to run the same security mechanism on top of the same security mechanism?
 
If IPSec is using MD5 do we also need SCTP to use MD5 and CT to use MD5 as well?
Is there not some duplication of effort here?
 
Maybe we need to do a threat analysis in the protocol design phase to ensure we have appropriate security measures at the appropriate level.
 
- Kulwinder.
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Monday, June 04, 2001 12:28 PM
To: 'Michael Thomas'
Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
Subject: RE: Comments Re: [seamoby] ct problem statement

Well, to begin with, "at the operators option" would include
the option to provide privacy or not to the service users. In
a competitive environment, the user could then decide whether to
subscribe to the service or not, if that privacy was not provided.

As for securing "keys" (which is necessary to maintain the committed
level of security that operator has chosen to support), as been discussed repeatedly on this list, no one has suggesting transferring keys openly. What I stated was that I do not understand where the requirements for CT differ from any other secure data transfer between peers.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 04, 2001 11:33 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'mankin@isi.edu'; 'seamoby'; 'Pat Calhoun'; sob@harvard.edu
> Subject: RE: Comments Re: [seamoby] ct problem statement
>
>
> Gary Kenward writes:
>  >   The second point troubles me somewhat: ct is essentially
> an information
>  > transfer operation. I do not understand (and I can only
> state this as my
>  > being confusion) why it is not enough to say that this
> information transfer
>  > must be secure. Why would a ct be any different from any
> other data transfer
>  > that needs to be secured?
>  >
>  >   I personally don't see any new vulnerabilities; based
> upon my superficial
>  > understanding of security, I read the examples you have
> provided as specific
>  > instances of general security problems which I understood
> to have been
>  > addressed. In other words, how are these scenarios not
> already addressed by
>  > the existing security solutions?
>  >
>  >   I am not against providing security for ct - not at all.
> However, I do
>  > want to ensure that security remains an option to the
> operator (and is not
>  > build into the protocol), the overhead imparted the ct can
> be minimized, and
>  > the performance goals attained.
>
>    Anything that transfers keys of any kind cannot be
>    done "at the operator's option". There are also
>    privacy issues which must be preserved for the MN
>    as well. At a base level, any transfer of context
>    must be at least as secure the mechanisms the
>    MN and AR used to create the original context.
>    Anything less is a breach to the MN.
>
>           Mike
>

------_=_NextPart_001_01C0ED45.ABD3E190-- From owner-seamoby@diameter.org Mon Jun 4 18:44:58 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20823 for ; Mon, 4 Jun 2001 18:44:57 -0400 (EDT) Received: (qmail 20450 invoked by alias); 4 Jun 2001 22:34:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20444 invoked by uid 200); 4 Jun 2001 22:34:07 -0000 Received: (qmail 20439 invoked from network); 4 Jun 2001 22:34:05 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jun 2001 22:34:05 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 18:44:00 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FB4@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Michael Thomas'" , Gary Kenward Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 4 Jun 2001 18:43:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, June 04, 2001 1:16 PM > To: Gary Kenward > Cc: 'Michael Thomas'; 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Gary Kenward writes: > > So, instead, we want to develop solutions for the "good of > the operator", > > whether they are willing to pay for it or not? > > There are any number of ways that a shoddy operator > can find to provide shoddy service. The IETF doesn't > need to provide helpful hints. > > > A moot point, really, for if an operator does not want a > feature, they > > simply have to find a manufacturer who is willing to > provide the capability > > to the feature off. > > > > Let's move on. > > No, let's not. The *user* figures in here too, and the > resulting RFC's should not allow for equivocation on this. > > Mike > What if it is a private wireless network where there is no competition? What if the private operator is an employer/government agency, or other entity where the wireless service is provided as a way to delivery content that is only available from a single employer/company/government agency? Does the user find another job to work at, or another country to live in? - Kulwinder. From owner-seamoby@diameter.org Tue Jun 5 06:01:57 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13958 for ; Tue, 5 Jun 2001 06:01:56 -0400 (EDT) Received: (qmail 23194 invoked by alias); 5 Jun 2001 09:51:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23188 invoked by uid 200); 5 Jun 2001 09:50:59 -0000 Received: (qmail 23183 invoked from network); 5 Jun 2001 09:50:57 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 09:50: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 f55A0ae05655 for ; Tue, 5 Jun 2001 13:00:36 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 5 Jun 2001 13:01:20 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 5 Jun 2001 13:01:20 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B078@eseis04nok> From: john.loughney@nokia.com To: gkenward@nortelnetworks.com, seamoby@diameter.org Cc: seamoby-context@cdma-2000.org, Pat.Calhoun@eng.sun.com, mankin@east.isi.edu Subject: RE: [seamoby] Security Considerations - new wording Date: Tue, 5 Jun 2001 13:01:19 +0300 Sensitivity: Company-Confidential 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 Gary, I think that we need to cover DOS attacks here. I don't think we need to go into deep detail about it, but I can envision some problems with CT w.r.t. DOS attacks. The CT protocol itself might not assume any state, but if a bad guy could send context (i.e. - state) to an AR, it might be able to overrun the ARs buffers. Alternatively, we need to ensure a third party cannot re-direct context as well. These two subjects could fall under the 'transfer legitimacy' bullet. So, text might be: - prevention of DOS-style attacks. Context transfer MUST NOT create any new opportunities for denial of service (DOS) attacks. These include (but are not limited to): flooding of bogus context in order to overrun the capacity of the target node; and the redirection of context in order to prevent the successful completion of the context transfer. How's that? From owner-seamoby@diameter.org Tue Jun 5 08:07:07 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16621 for ; Tue, 5 Jun 2001 08:07:05 -0400 (EDT) Received: (qmail 24125 invoked by alias); 5 Jun 2001 11:55:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24118 invoked by uid 200); 5 Jun 2001 11:55:56 -0000 Received: (qmail 24113 invoked from network); 5 Jun 2001 11:55:54 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 11:55:54 -0000 Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f55C4I500511; Tue, 5 Jun 2001 05:04:18 -0700 (PDT) Received: from spandex (sjc-vpn-tmp247.cisco.com [10.21.64.247]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AID03694; Tue, 5 Jun 2001 05:05:46 -0700 (PDT) Message-ID: <026001c0edb7$f55106a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Louis-Nicolas Hamer" Cc: "'seamoby'" References: <9FBD322B7824D511B36900508BF93C9CA5B4AA@zcard031.ca.nortel.com> Subject: Re: Comments Re: [seamoby] ct problem statement Date: Tue, 5 Jun 2001 08:06:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > But can we all agree that we don't need to re-invent a specific > security solution for CT? Basically, you guys are stating that > the IETF security area, with all it's experts did not do a good > job designing current security solutions and that we need to > re-invent the wheel once again. I don't see anybody saying that. There's actually a rich set of security mechanisms published by the IETF - the task is to identify the requirements and then choose the appropriate tool to solve the problem. Context transfer may have requirements, like performance, that would be difficult to meet if you were to wave hands and use IKE to key up and establish SAs. So while this isn't the time to choose mechanisms it certainly is the time to be pretty clear about what the requirements will be. "Use existing IETF protocols" will be one requirement, but there must be others. Melinda From owner-seamoby@diameter.org Tue Jun 5 08:35:27 2001 Received: from charizard.diameter.org ([24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17679 for ; Tue, 5 Jun 2001 08:35:27 -0400 (EDT) Received: (qmail 24634 invoked by alias); 5 Jun 2001 12:24:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24627 invoked by uid 200); 5 Jun 2001 12:24:29 -0000 Received: (qmail 24622 invoked from network); 5 Jun 2001 12:24:28 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 12:24:28 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 08:34:53 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Melinda Shore'" , Louis-Nicolas Hamer Cc: "'seamoby'" Subject: Security stuff was RE: Comments Re: [seamoby] ct problem statemen t Date: Tue, 5 Jun 2001 08:34:52 -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 Hello, > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, June 05, 2001 8:06 AM > To: Louis-Nicolas Hamer > Cc: 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > But can we all agree that we don't need to re-invent a specific > > security solution for CT? Basically, you guys are stating that > > the IETF security area, with all it's experts did not do a good > > job designing current security solutions and that we need to > > re-invent the wheel once again. Why not? That's what mobile IP has done... :-) > > I don't see anybody saying that. There's actually a rich > set of security mechanisms published by the IETF - the task > is to identify the requirements and then choose the > appropriate tool to solve the problem. Context transfer > may have requirements, like performance, that would be > difficult to meet if you were to wave hands and use IKE to > key up and establish SAs. Why? Why can't this be done once and then kept around for some deemed useful period of time? >So while this isn't the time to > choose mechanisms it certainly is the time to be pretty > clear about what the requirements will be. "Use existing > IETF protocols" will be one requirement, but there must be > others. Yes, like: Is encryption (a block cipher presumably) needed? Is authentication needed? Is authorization needed? Will it work over/through common firewall systems and VPNs? Will it work over/through NATs? Can it work with IPSEC? How does it work with PKI? Does this conversation belong on the CT list? Can somebody please answer these questions? Thanks, pdn From owner-seamoby@diameter.org Tue Jun 5 09:23:55 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 JAA19700 for ; Tue, 5 Jun 2001 09:23:51 -0400 (EDT) Received: (qmail 25813 invoked by alias); 5 Jun 2001 13:10:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25807 invoked by uid 200); 5 Jun 2001 13:10:54 -0000 Received: (qmail 25802 invoked from network); 5 Jun 2001 13:10:50 -0000 Received: from custos.foi.se (HELO mercur.foa.se) (150.227.16.253) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 13:10:50 -0000 Received: from box.lin.foa.se (box.foi.se [150.227.31.1]) by mercur.foa.se (8.9.3/8.9.3) with ESMTP id PAA11255; Tue, 5 Jun 2001 15:21:05 +0200 (MEST) Received: from botten (dhcp-033-177.foi.se [150.227.33.177]) by box.lin.foa.se (8.9.3/8.9.3) with SMTP id PAA08697; Tue, 5 Jun 2001 15:23:58 +0200 (MEST) Message-ID: <003601c0edc2$613fbfa0$b121e396@botten> From: =?iso-8859-1?Q?Christian_J=F6nsson?= To: "Charles E. Perkins" , "Nakhjiri Madjid-MNAKHJI1" Cc: "'Jukka Manner'" , "Hamid Syed" , "'James Kempf'" , , "Mobile Ad Hoc IETF working group" References: <35DBB8B7AC89D4118E98009027B1009B1B7BD7@IL27EXM10.cig.mot.com> <3B0560D0.3B0DDC40@iprg.nokia.com> Subject: Re: Wireless Terminology Draft( was: Re: [seamoby] Seamoby Charter Last Call) Date: Tue, 5 Jun 2001 15:21:01 +0200 Organization: Sweden's Defence Research Agency MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit [hmm, late I know, it was laying in my drafts folder...] I would just like to say I strongly support this idea. What we are dealing with is the joining of tele communications, data communications, and computer communications culture and expressions. Having a statement of what is meant terminology-wise would be a perfect thing to have. It might be hadr to get it through, though. I suppose wa all constantly encounter situations where we mean different things when talking about communications. You know, human communications is never fault free :-) Cheers, /ChJ ----- Original Message ----- From: "Charles E. Perkins" To: "Nakhjiri Madjid-MNAKHJI1" Cc: "'Jukka Manner'" ; "Hamid Syed" ; "'James Kempf'" ; ; "Mobile Ad Hoc IETF working group" Sent: Friday, May 18, 2001 7:50 PM 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 Tue Jun 5 10:42:55 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 KAA22541 for ; Tue, 5 Jun 2001 10:42:53 -0400 (EDT) Received: (qmail 27320 invoked by alias); 5 Jun 2001 14:31:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27314 invoked by uid 200); 5 Jun 2001 14:31:53 -0000 Received: (qmail 27309 invoked from network); 5 Jun 2001 14:31:51 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 14:31:51 -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 HAA26349; Tue, 5 Jun 2001 07:41:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f55EfZK04906; Tue, 5 Jun 2001 07:41:35 -0700 X-mProtect: Tue, 5 Jun 2001 07:41:35 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHaGYUw; Tue, 05 Jun 2001 07:41:34 PDT Message-ID: <3B1CEF9E.F210168A@iprg.nokia.com> Date: Tue, 05 Jun 2001 07:41:34 -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: "'seamoby'" CC: Phillip Neumiller Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem statement References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Phillip Neumiller wrote: >>> But can we all agree that we don't need to re-invent a specific >>> security solution for CT? Basically, you guys are stating that >>> the IETF security area, with all it's experts did not do a good >>> job designing current security solutions and that we need to >>> re-invent the wheel once again. > > Why not? That's what mobile IP has done... :-) This needs additional information to be understood correctly. There were two problems. 1. The Mobile IP group was instructed that use of AH was problematic because the SPD selection mechanism did not mesh well with the requirement to authenticate data in a destination option (vs., say, authenticating the payload). 2. Further, it was determined that providing the mechanism (Binding Update) for enabling direct routes between mobile node and correspondent node was inadequate unless there was also a reasonable mechanism for creating the security association for carrying out the needed authorization check. The above quoted sentence _might_ be misinterpreted to mean that people in the mobile-ip working group did not want to use IPsec mechanisms. That would be wrong. Regards, Charlie P. From owner-seamoby@diameter.org Tue Jun 5 10:47: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 KAA22662 for ; Tue, 5 Jun 2001 10:47:43 -0400 (EDT) Received: (qmail 27801 invoked by alias); 5 Jun 2001 14:36:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27795 invoked by uid 200); 5 Jun 2001 14:36:11 -0000 Received: (qmail 27790 invoked from network); 5 Jun 2001 14:36:09 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 14:36:09 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 10:46:35 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454E9@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Charles E. Perkins'" , "'seamoby'" Cc: Phillip Neumiller Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Date: Tue, 5 Jun 2001 10:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Yes, I am sorry for the sarcastic remark. MIP is not reinventintg the wheel, the MAN in the middle attack was the reason IPsec could not be used (I believe). I hope that we can analyze the "applicability of IPsec" to SeaMoby CT without getting bogged down in reinventing IPsec here. I hope that the SeaMoby group can answer the requirements issue in reverse here and ask what is wrong with using IPsec for CT rather than what are all the possible attacks on the planet that could mess up CT.... Thanks, Phil > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Tuesday, June 05, 2001 10:42 AM > To: 'seamoby' > Cc: Phillip Neumiller > Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem > statement > > > Phillip Neumiller wrote: > > >>> But can we all agree that we don't need to re-invent a specific > >>> security solution for CT? Basically, you guys are stating that > >>> the IETF security area, with all it's experts did not do a good > >>> job designing current security solutions and that we need to > >>> re-invent the wheel once again. > > > > Why not? That's what mobile IP has done... :-) > > This needs additional information to be understood correctly. > There were two problems. > > 1. The Mobile IP group was instructed that use of AH was problematic > because the SPD selection mechanism did not mesh well with the > requirement to authenticate data in a destination option (vs., say, > authenticating the payload). > > 2. Further, it was determined that providing the mechanism (Binding > Update) for enabling direct routes between mobile node and > correspondent node was inadequate unless there was also a > reasonable mechanism for creating the security association for > carrying out the needed authorization check. > > The above quoted sentence _might_ be misinterpreted to mean that > people in the mobile-ip working group did not want to use IPsec > mechanisms. That would be wrong. > > Regards, > Charlie P. > From owner-seamoby@diameter.org Tue Jun 5 10:52: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 KAA22763 for ; Tue, 5 Jun 2001 10:52:49 -0400 (EDT) Received: (qmail 28285 invoked by alias); 5 Jun 2001 14:41:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28279 invoked by uid 200); 5 Jun 2001 14:41:31 -0000 Received: (qmail 28274 invoked from network); 5 Jun 2001 14:41:29 -0000 Received: from frascone.com (HELO newman.frascone.com) (god@216.62.83.25) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 14:41:29 -0000 Received: (qmail 17383 invoked by uid 500); 5 Jun 2001 14:51:55 -0000 Date: Tue, 5 Jun 2001 09:51:55 -0500 From: David Frascone To: Phillip Neumiller Cc: "'seamoby'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Message-ID: <20010605095154.E18382@newman.frascone.com> Mail-Followup-To: Phillip Neumiller , 'seamoby' References: <0DF9FBC42474A24CA50F7A27FB08E0484454E9@meshpdc.meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484454E9@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Tue, Jun 05, 2001 at 10:46:32AM -0400 X-encrypt-payload: no Sender: owner-seamoby@diameter.org Precedence: bulk I think I'm going off on a tangent, but at the IETF, wasn't it said that the man-in-the-middle attack had no solution? And, that the MITM attacks were being ignored, since there was no solution at all, unless you had prior knowledge (i.e. the public key) of the party you were communicating with? -Dave On Tue, Jun 05, 2001 at 10:46:32AM -0400, Phillip Neumiller wrote: > Yes, I am sorry for the sarcastic remark. MIP is not reinventintg the > wheel, > the MAN in the middle attack was the reason IPsec could not be used (I > believe). > I hope that we can analyze the "applicability of IPsec" to SeaMoby CT > without > getting bogged down in reinventing IPsec here. I hope that the SeaMoby > group > can answer the requirements issue in reverse here and ask what is wrong with > using IPsec for CT rather than what are all the possible attacks on the > planet > that could mess up CT.... > > Thanks, > > Phil > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Tuesday, June 05, 2001 10:42 AM > > To: 'seamoby' > > Cc: Phillip Neumiller > > Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem > > statement > > > > > > Phillip Neumiller wrote: > > > > >>> But can we all agree that we don't need to re-invent a specific > > >>> security solution for CT? Basically, you guys are stating that > > >>> the IETF security area, with all it's experts did not do a good > > >>> job designing current security solutions and that we need to > > >>> re-invent the wheel once again. > > > > > > Why not? That's what mobile IP has done... :-) > > > > This needs additional information to be understood correctly. > > There were two problems. > > > > 1. The Mobile IP group was instructed that use of AH was problematic > > because the SPD selection mechanism did not mesh well with the > > requirement to authenticate data in a destination option (vs., say, > > authenticating the payload). > > > > 2. Further, it was determined that providing the mechanism (Binding > > Update) for enabling direct routes between mobile node and > > correspondent node was inadequate unless there was also a > > reasonable mechanism for creating the security association for > > carrying out the needed authorization check. > > > > The above quoted sentence _might_ be misinterpreted to mean that > > people in the mobile-ip working group did not want to use IPsec > > mechanisms. That would be wrong. > > > > Regards, > > Charlie P. > > > From owner-seamoby@diameter.org Tue Jun 5 11:05: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 LAA22980 for ; Tue, 5 Jun 2001 11:05:18 -0400 (EDT) Received: (qmail 28817 invoked by alias); 5 Jun 2001 14:54:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28810 invoked by uid 200); 5 Jun 2001 14:54:34 -0000 Received: (qmail 28805 invoked from network); 5 Jun 2001 14:54:32 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 14:54:32 -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 f55F4vO28950 for ; Tue, 5 Jun 2001 17:04:57 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 05 17:04:51 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 17:04:51 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBECF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman \(ERA\)" To: "'seamoby'" Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Date: Tue, 5 Jun 2001 17:04:50 +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 > Yes, I am sorry for the sarcastic remark. MIP is not reinventintg the > wheel, > the MAN in the middle attack was the reason IPsec could not be used (I > believe). > => I don't think so. The reason for IPsec concerns is what Charlie mentioned below (SPD granularity and the way BUs are sent). The bigger problem was Key exchange and relying on IKE. BTW I didn't know IPsec was ruled out just yet. Hesham From owner-seamoby@diameter.org Tue Jun 5 11:07: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 LAA23003 for ; Tue, 5 Jun 2001 11:07:34 -0400 (EDT) Received: (qmail 29291 invoked by alias); 5 Jun 2001 14:56:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29285 invoked by uid 200); 5 Jun 2001 14:56:10 -0000 Received: (qmail 29279 invoked from network); 5 Jun 2001 14:56:03 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 14:56:03 -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 IAA27348; Tue, 5 Jun 2001 08:05:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f55F5us28977; Tue, 5 Jun 2001 08:05:56 -0700 X-mProtect: Tue, 5 Jun 2001 08:05:56 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdraXEwd; Tue, 05 Jun 2001 08:05:55 PDT Message-ID: <3B1CF553.B3AAF6D0@iprg.nokia.com> Date: Tue, 05 Jun 2001 08:05:55 -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: Phillip Neumiller CC: "'seamoby'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem statement References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, >> I don't see anybody saying that. There's actually a rich >> set of security mechanisms published by the IETF - the task >> is to identify the requirements and then choose the >> appropriate tool to solve the problem. Context transfer >> may have requirements, like performance, that would be >> difficult to meet if you were to wave hands and use IKE to >> key up and establish SAs. > > Why? Why can't this be done once and then kept around for > some deemed useful period of time? Suppose we assume that two neighboring access routers already have a security association, and that a mobile node has a security association with one of them. When the mobile node moves to the other one, it seems logical to me to use the inter-access-router security association to establish a security association between the mobile node and the new access router. As far as I know, IKE can't do this. Maybe IKE should be used to set up the security associations between the access routers. Melinda Shore wrote: >> So while this isn't the time to >> choose mechanisms it certainly is the time to be pretty >> clear about what the requirements will be. "Use existing >> IETF protocols" will be one requirement, but there must be >> others. How about, "Use existing IETF protocols wherever appropriate according to performance and feature requirements"? I reckon this is what you meant, anyway. Phil wrote some more: > Yes, like: > > Is encryption (a block cipher presumably) needed? This probably depends on characteristics of the access network. > Is authentication needed? Probably not. > Is authorization needed? I think this is the central requirement. > Will it work over/through common firewall systems and VPNs? I think the basic mechanism should be designed to work with the best performance possible, and then extended to work in other scenarios. Where is our authorized firewall automatic configuration protocol anyway when we need it? > Will it work over/through NATs? Bzzzt. > Can it work with IPSEC? What does this mean? > How does it work with PKI? This question cannot be answered until the basic message flows are identified. By "basic", I mean the stuff that makes the context get transferred. After that is known, then probably the PKI details could be worked out. My guess is that the latter might even be a separate protocol, but who knows? > Does this conversation belong on the CT list? .... why not here??? .... > Can somebody please answer these questions? Please be more specific. Select from among the following: 1. Authoritative answers 2. Thoughtful answers 3. Knee-jerk responses 4. Seat-of-the-pants wisdom 5. Educated guesses 6. Wild guesses 7. Incoherent babble Or were you merely inquiring about capability, instead of placing an imperative? Regards, Charlie P. From owner-seamoby@diameter.org Tue Jun 5 11:22: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 LAA23320 for ; Tue, 5 Jun 2001 11:21:52 -0400 (EDT) Received: (qmail 29886 invoked by alias); 5 Jun 2001 15:09:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29880 invoked by uid 200); 5 Jun 2001 15:09:24 -0000 Received: (qmail 29875 invoked from network); 5 Jun 2001 15:09:22 -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; 5 Jun 2001 15:09:22 -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 f55FJ4E23291 for ; Tue, 5 Jun 2001 11:19:04 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 5 Jun 2001 11:18:49 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 11:18:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Kulwinder Atwal'" , "'Michael Thomas'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 5 Jun 2001 11:19:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EDD2.DE933BC0" 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_01C0EDD2.DE933BC0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Monday, June 04, 2001 6:44 PM > To: 'Michael Thomas'; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Monday, June 04, 2001 1:16 PM > > To: Gary Kenward > > Cc: 'Michael Thomas'; 'seamoby' > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > Gary Kenward writes: > > > So, instead, we want to develop solutions for the "good of > > the operator", > > > whether they are willing to pay for it or not? > > > > There are any number of ways that a shoddy operator > > can find to provide shoddy service. The IETF doesn't > > need to provide helpful hints. > > > > > A moot point, really, for if an operator does not want a > > feature, they > > > simply have to find a manufacturer who is willing to > > provide the capability > > > to the feature off. > > > > > > Let's move on. > > > > No, let's not. The *user* figures in here too, and the > > resulting RFC's should not allow for equivocation on this. > > > > Mike > > > > What if it is a private wireless network where there is no > competition? > > What if the private operator is an employer/government > agency, or other > entity where the wireless service is provided as a way to > delivery content > that is only available from a single > employer/company/government agency? > > Does the user find another job to work at, or another country > to live in? I guess so. What if the CIA decides to record all your email and pass it through their supercomputers for a week. Would you feel your privacy is safe? I willing to bet that none of the security experts would be willing to state that any protocol solution is going to protect you if the operator is unwilling or against supporting it, particularly if they are the government. The IETF does not, can not force compliance, it can only recommend. And as you have identified, there is no one who has the authority to force compliance. The truth is out there ;^} Gary > > - Kulwinder. > ------_=_NextPart_001_01C0EDD2.DE933BC0 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> Sent: Monday, June 04, 2001 6:44 PM
> To: 'Michael Thomas'; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
>
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Monday, June 04, 2001 1:16 PM
> > To: Gary Kenward
> > Cc: 'Michael Thomas'; 'seamoby'
> > Subject: RE: Comments Re: [seamoby] ct problem statement
> >
> >
> > Gary Kenward writes:
> >  > So, instead, we want to develop solutions for the "good of
> > the operator",
> >  > whether they are willing to pay for it or not?
> >
> >    There are any number of ways that a shoddy operator
> >    can find to provide shoddy service. The IETF doesn't
> >    need to provide helpful hints.
> >
> >  > A moot point, really, for if an operator does not want a
> > feature, they
> >  > simply have to find a manufacturer who is willing to
> > provide the capability
> >  > to the feature off.
> >  >
> >  > Let's move on.
> >
> >    No, let's not. The *user* figures in here too, and the
> >    resulting RFC's should not allow for equivocation on this.
> >
> >          Mike
> >
>
> What if it is a private wireless network where there is no
> competition?
>
> What if the private operator is an employer/government
> agency, or other
> entity where the wireless service is provided as a way to
> delivery content
> that is only available from a single
> employer/company/government agency?
>
> Does the user find another job to work at, or another country
> to live in?

I guess so. What if the CIA decides to record all your email and pass
it through their supercomputers for a week. Would you feel your privacy is
safe?

I willing to bet that none of the security experts would
be willing to state that any protocol solution is going to protect you
if the operator is unwilling or against supporting it, particularly if
they are the government.

The IETF does not, can not force compliance, it can only recommend.
And as you have identified, there is no one who has the authority to
force compliance.

The truth is out there ;^}

Gary

>
> - Kulwinder.
>

------_=_NextPart_001_01C0EDD2.DE933BC0-- From owner-seamoby@diameter.org Tue Jun 5 11:30: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 LAA23486 for ; Tue, 5 Jun 2001 11:30:16 -0400 (EDT) Received: (qmail 30572 invoked by alias); 5 Jun 2001 15:17:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30565 invoked by uid 200); 5 Jun 2001 15:17:00 -0000 Received: (qmail 30554 invoked from network); 5 Jun 2001 15:16:58 -0000 Received: from clarinet.u-strasbg.fr (root@130.79.90.157) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 15:16:58 -0000 Received: from mobinet (mobinet.u-strasbg.fr [130.79.90.159]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id RAA15812 for ; Tue, 5 Jun 2001 17:27:23 +0200 From: "Thomas Noel" To: Subject: [seamoby] CFP : RSRCP Journal - Mobility and Internet Date: Tue, 5 Jun 2001 17:25:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies.] CALL for PAPERS SPECIAL ISSUE MOBILITY AND INTERNET of RSRCP Journal http://www-r2.u-strasbg.fr/rsrcp/mintcfp.html The RSRCP journal, which is now specialized on thematic issues on Network and Distributed System is pleased to announce a special issue on "Mobility and Internet". This special issue is sponsored by IEEE Distributed Systems and the French IEEE Computer Chapter. Wireless mobile access to the Internet will add new dimensions to the way we access information and communicate. Currently, several network protocols are being studied to maintain communication between a mobile host and its correspondents during the mobile host's movements. This special issue is devoted to the presentation of recent research on network protocols and services for mobile hosts and wireless communication on the Internet. We solicit high quality papers reporting original work in theoretical or experimental research. Topics of interest include, but are not limited to the following : - Ad hoc networks - Cellular IP networks - Distributed system aspects of mobile systems - Handoffs in IP networks - Header compression in wireless networks - Hierarchical mobility - IP-based third generation mobile and wireless networks - Micro-mobility architectures and protocols - Multicast communications for mobile hosts - Mobility and IPv6 - Mobile management - Network protocols for mobile nodes - QoS in a wireless/mobile environment - Security and authentication - Service location in wireless environnement - Wireless LAN Important dates: 1. Submission deadline: June 30, 2001; 2. Notifications to the authors: September, 30, 2001; 3. Publication : December 2001; Submissions: Contributions should follow the instructions and the format of the journal edited by Hermes. (see http://www-r2.u-strasbg.fr/rsrcp/authorsguidelines.pdf) Contributions should be original ones and should not be longer than 25 pages. Submissions should be forwarded to the Guest Editors (rsrcp@clarinet.u-strasbg.fr - PS or PDF format, compressed). Guest Editors : Thomas Noel Andras Valko Universite Louis Pasteur - LSIIT Ericsson Research Pole API - Boulevard Sébastien Brant Traffic Laboratory F- 67400 - Illkirch H-1037 Budapest, Laborc u 1. France Hungary Editorial Board : Scott Corson Francis Dupont Flarion Technologies ENST - Bretagne USA France Philip Eardley Thierry Ernst British Telecom INRIA UK France Andras Farago Hong-Yon Lach University of Texas - Dallas Motorola - Paris USA France Phil Neumiller Thomas Noel 3Com LSIIT USA France Hesham Soliman Tapio Suihko Ericsson VTT Technical Research Center Australia Finland C.K. Toh Michel Trehel Georgia Institute of Technology University of Franche-Comté USA France Andras Valko Ericsson Hungary -- NOEL Thomas - ULP/LSIIT Thomas.Noel@dpt-info.u-strasbg.fr http://www-r2.u-strasbg.fr/~noel tel: (33) 03 90 24 45 92 - fax: 03 90 24 44 55 From owner-seamoby@diameter.org Tue Jun 5 11:36: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 LAA23623 for ; Tue, 5 Jun 2001 11:36:02 -0400 (EDT) Received: (qmail 31644 invoked by alias); 5 Jun 2001 15:25:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31638 invoked by uid 200); 5 Jun 2001 15:25:14 -0000 Received: (qmail 31633 invoked from network); 5 Jun 2001 15:25:12 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 15:25:12 -0000 Received: (qmail 11637 invoked from network); 5 Jun 2001 15:35:38 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 15:35:38 -0000 Message-ID: <3B1CFC48.9070707@comdev.cc> Date: Tue, 05 Jun 2001 08:35:36 -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'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement References: <0DF9FBC42474A24CA50F7A27FB08E0484454E9@meshpdc.meshnetworks.com> <20010605095154.E18382@newman.frascone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone wrote: > I think I'm going off on a tangent, but at the IETF, wasn't it said that > the man-in-the-middle attack had no solution? And, that the MITM attacks > were being ignored, since there was no solution at all, unless you had prior > knowledge (i.e. the public key) of the party you were communicating with? ...or, there is a trusted third party (Certificate Authority) whom you both trust to verify The Other Guy's(tm) identity sign The Other Guy's(tm) key. Then, all you'd need to know is the CA's public key and you could verify that the key your getting belongs to who it caims to. (NOTE: I'm not aware of any of the CAs signing IPSec Identity Keys yet, so this may be of little use. Of course, I've also not been looking for them, so they may exist; I've not checked.) Of course, this puts trust in the CAs. Who's heard about the disgruntled ex-Microsoft employee getting a cert in Microsoft's name? :) -Mark From owner-seamoby@diameter.org Tue Jun 5 11:44: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 LAA23842 for ; Tue, 5 Jun 2001 11:44:26 -0400 (EDT) Received: (qmail 32180 invoked by alias); 5 Jun 2001 15:33:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32174 invoked by uid 200); 5 Jun 2001 15:33:30 -0000 Received: (qmail 32169 invoked from network); 5 Jun 2001 15:33:29 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 15:33:29 -0000 Received: (qmail 11915 invoked from network); 5 Jun 2001 15:43:51 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 15:43:51 -0000 Message-ID: <3B1CFE37.9060501@comdev.cc> Date: Tue, 05 Jun 2001 08:43:51 -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'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem statement References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> <3B1CF553.B3AAF6D0@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charles E. Perkins wrote: >> Is encryption (a block cipher presumably) needed? > > This probably depends on characteristics of the access network. I'd like to suggest this depends more on the characteristics of the context being transfered. I don't care too much whether someone sees the current state of my header compression. I care a WHOLE LOT about someone seeing my authentication information. Of course it also depends on the characteristics of the AN, but I'd think more on the data. >> Is authentication needed? > > Probably not. > >> Is authorization needed? > > I think this is the central requirement. What good is authorization without authentication? oldAR: "Yeah, this guy is authorized." newAR: "Really? Who is he?" oldAR: "Uh, he's, well, authorized." newAR: "I don't buy it." Maybe I'm just paranoid, but I'd like to suggest that authentication and authorization go hand-in-hand. The only possible exception to this is when the two ARs trust each other (within the same administrative domain.) In this case, oldAR could simply tell newAR "Yep, this guy's been authenticated." The advantage to this is that the MN's authentication information is no longer being sent in CT. (It would (hopefully) also make the context smaller.) But unless they trust each other, I still think authentication is important. -Mark From owner-seamoby@diameter.org Tue Jun 5 11:56: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 LAA24199 for ; Tue, 5 Jun 2001 11:56:27 -0400 (EDT) Received: (qmail 32695 invoked by alias); 5 Jun 2001 15:39:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32686 invoked by uid 200); 5 Jun 2001 15:39:43 -0000 Received: (qmail 32680 invoked from network); 5 Jun 2001 15:39:41 -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; 5 Jun 2001 15:39:41 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f55FnSE28223 for ; Tue, 5 Jun 2001 11:49:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 5 Jun 2001 11:49:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 11:49:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5C95@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: RE: [seamoby] Security Considerations - new wording Date: Tue, 5 Jun 2001 11:49:35 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EDD7.1EF247C0" 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_01C0EDD7.1EF247C0 Content-Type: text/plain; charset="ISO-8859-1" John: Good suggestions. I was actually referring to DOS and other similar attacks with the euphemism "transfer legitimacy". Not being a security guru myself, I wasn't sure if there was an acceptable general term, so I created one. I was purposely trying to avoid being too specific in the problem statement. I worry that we could end up with a shopping list of potential threats. Given the direction we are going, I suspect that we will have to enumerate the various threats in the requirements draft anyway, as we are attempting to do with reliability (although, my preference would be to defer such a list until a proper threat analysis could be performed on the protocol design). Either way, the analysis will be done at least once, and more likely many, many times. Anyway, that was my thinking. Of course, if the dt wants, it can all be changed. Comments? Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, June 05, 2001 6:01 AM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com; > mankin@east.isi.edu > Subject: RE: [seamoby] Security Considerations - new wording > Sensitivity: Confidential > > > Hi Gary, > > I think that we need to cover DOS attacks here. I don't > think we need to go into deep detail about it, but I > can envision some problems with CT w.r.t. DOS attacks. > > The CT protocol itself might not assume any state, but > if a bad guy could send context (i.e. - state) to an AR, > it might be able to overrun the ARs buffers. > > Alternatively, we need to ensure a third party cannot > re-direct context as well. > > These two subjects could fall under the 'transfer legitimacy' > bullet. > > So, text might be: > > - prevention of DOS-style attacks. Context transfer > MUST NOT create any new opportunities for denial of > service (DOS) attacks. These include (but are not > limited to): flooding of bogus context in order > to overrun the capacity of the target node; and the > redirection of context in order to prevent the > successful completion of the context transfer. > > How's that? > > ------_=_NextPart_001_01C0EDD7.1EF247C0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] Security Considerations - new wording

John:

  Good suggestions. I was actually referring to DOS and other
similar attacks with the euphemism "transfer legitimacy". Not
being a security guru myself, I wasn't sure if there was an
acceptable general term, so I created one.

  I was purposely trying to avoid being too specific in the problem
statement. I worry that we could end up with a shopping list of
potential threats.

Given the direction we are going, I suspect that we will have to
enumerate the various threats in the requirements draft anyway, as
we are attempting to do with reliability (although, my preference
would be to defer such a list until a proper threat analysis could
be performed on the protocol design). Either way, the analysis will
be done at least once, and more likely many, many times.

Anyway, that was my thinking. Of course, if the dt wants, it can
all be changed. Comments?

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Tuesday, June 05, 2001 6:01 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com;
> mankin@east.isi.edu
> Subject: RE: [seamoby] Security Considerations - new wording
> Sensitivity: Confidential
>
>
> Hi Gary,
>
> I think that we need to cover DOS attacks here.  I don't
> think we need to go into deep detail about it, but I
> can envision some problems with CT w.r.t. DOS attacks.
>
> The CT protocol itself might not assume any state, but
> if a bad guy could send context (i.e. - state) to an AR,
> it might be able to overrun the ARs buffers. 
>
> Alternatively, we need to ensure a third party cannot
> re-direct context as well.
>
> These two subjects could fall under the 'transfer legitimacy'
> bullet. 
>
> So, text might be:
>
>       - prevention of DOS-style attacks.  Context transfer
>       MUST NOT create any new opportunities for denial of
>       service (DOS) attacks.  These include (but are not
>       limited to): flooding of bogus context in order
>       to overrun the capacity of the target node; and the
>       redirection of context in order to prevent the
>       successful completion of the context transfer.
>
> How's that?
>      
>

------_=_NextPart_001_01C0EDD7.1EF247C0-- From owner-seamoby@diameter.org Tue Jun 5 12:00: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 MAA24418 for ; Tue, 5 Jun 2001 12:00:47 -0400 (EDT) Received: (qmail 959 invoked by alias); 5 Jun 2001 15:50:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 951 invoked by uid 200); 5 Jun 2001 15:50:00 -0000 Received: (qmail 946 invoked from network); 5 Jun 2001 15:49:58 -0000 Received: from chello213047128084.15.vie.surfer.at (HELO ssaserv1.roesti.cc) (213.47.128.84) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 15:49:58 -0000 Received: by chello213047128084.15.vie.surfer.at with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Jun 2001 17:55:45 +0200 Message-ID: <71C667A91D79D41197910050DA46B3C902FC11@chello213047128084.15.vie.surfer.at> From: Hannes Tschofenig To: "'Mark Smith '" , "''seamoby' '" Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Date: Tue, 5 Jun 2001 17:55:43 +0200 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 mark! What good is authorization without authentication? oldAR: "Yeah, this guy is authorized." newAR: "Really? Who is he?" oldAR: "Uh, he's, well, authorized." newAR: "I don't buy it." Maybe I'm just paranoid, but I'd like to suggest that authentication and authorization go hand-in-hand. # authorization and authentication do not always go hand-in-hand: # an example: # if you look at the proposals for the mn-cn binding update problem you # will see that they all do not provide authentication but most of them # try to solve the address ownership problem - an authorization # problem. # but in most cases you are right. -Mark # ciao # hannes tschofenig From owner-seamoby@diameter.org Tue Jun 5 12:03: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 MAA24522 for ; Tue, 5 Jun 2001 12:03:03 -0400 (EDT) Received: (qmail 1446 invoked by alias); 5 Jun 2001 15:51:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1440 invoked by uid 200); 5 Jun 2001 15:51:30 -0000 Received: (qmail 1435 invoked from network); 5 Jun 2001 15:51:29 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 15:51:29 -0000 Received: (qmail 13090 invoked from network); 5 Jun 2001 16:01:55 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 16:01:55 -0000 Message-ID: <3B1D0274.60706@comdev.cc> Date: Tue, 05 Jun 2001 09:01:56 -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'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > I guess so. What if the CIA decides to record all your email and pass > it through their supercomputers for a week. Would you feel your privacy is > safe? If I believe in the system and the underlying encryption, yes. Do I believe that the NSA (to whom the CIA would pass the data for processing) has solved the NP-Complete problem yet? If they have, they've mannaged to keep their hats on probably one of the biggest mathimatical advancements in history. I don't think it's likely at this point, so I trust RSA (with a large enough key.) > I willing to bet that none of the security experts would > be willing to state that any protocol solution is going to protect you > if the operator is unwilling or against supporting it, particularly if > they are the government. If the government is the operator, you're correct. However, I don't think the government (at least, not the US goverment. Maybe this argument is more applicable elsewhere) is in the wireless, mobile IP business, last I checked. > The IETF does not, can not force compliance, it can only recommend. > And as you have identified, there is no one who has the authority to > force compliance. This is true. But the IETF _CAN_ force a good security model for compliance. If you build a good security model(*) into the protocol, and require it, then anyone who doesn't use that good security model is not complient with the protocol. If someone is going to release a non-standards-compliant product, there's nothing I can do about that, but they haven't released a CTP product. (As an example, this is a personal beef I have with the FreeS/WAN folks. Their product is _NOT_ IPSec. It looks like IPSec, it smells like IPSec, it provides much of the same functionality as IPSec, but it doesn't (by design) support SingleDES which is a requirement of the IPSec protocol. It is therefor _NOT_ IPSec compliant.) My point to this post is to say that I believe it is our duity to treat the customer's content as if it were sensitive, whether they want it to be or not. We, at the requirements stage, have no idea whether a particular MN would care whether its authentication information is protected or not, so we have to assume that it should be. Just my $0.02 worth. -Mark (*) Where "good security model" is defined as "sufficient for the purpose." Keep in mind that the idea behind security in a situation like this is just to make sure it's not the weakest link. There's always Rubber Hose Cryptanalysis, where the Cryptanalysist beats the target over the head and shoulders with a rubber hose until they give up the information they're after. _MUCH_ more effective than attacking the system or the encryption algorythm in a number of cases. From owner-seamoby@diameter.org Tue Jun 5 12:40: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 MAA25486 for ; Tue, 5 Jun 2001 12:40:14 -0400 (EDT) Received: (qmail 2414 invoked by alias); 5 Jun 2001 16:29:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2408 invoked by uid 200); 5 Jun 2001 16:29:20 -0000 Received: (qmail 2399 invoked from network); 5 Jun 2001 16:29:17 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:29:17 -0000 Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f55GdD906494; Tue, 5 Jun 2001 09:39:13 -0700 (PDT) Received: from spandex (sjc-vpn-tmp106.cisco.com [10.21.64.106]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AIE03506; Tue, 5 Jun 2001 09:38:52 -0700 (PDT) Message-ID: <005801c0edde$1bc9b360$d45904d1@cisco.com> From: "Melinda Shore" To: "Mark Smith" , "'seamoby'" References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> <3B1CF553.B3AAF6D0@iprg.nokia.com> <3B1CFE37.9060501@comdev.cc> Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem statement Date: Tue, 5 Jun 2001 12:39:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 x-mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'd like to suggest this depends more on the characteristics of the > context being transfered. I don't care too much whether someone sees > the current state of my header compression. I care a WHOLE LOT about > someone seeing my authentication information. I think this is generally (okay, absolutely) true, with the caveat below ... > Maybe I'm just paranoid, but I'd like to suggest that authentication and > authorization go hand-in-hand. At the risk of inciting giggles, I should point out that some networks are considered trusted and that pretty much any traffic on them would be considered legitimate. You could argue that this does constitute weak authentication. Authentication and authorization are orthogonal and should be treated as such. I don't think that it's always necessarily the case that authorization needs to depend on cryptographic authentication. Melinda From owner-seamoby@diameter.org Tue Jun 5 12:46: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 MAA25686 for ; Tue, 5 Jun 2001 12:46:50 -0400 (EDT) Received: (qmail 2922 invoked by alias); 5 Jun 2001 16:34:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2916 invoked by uid 200); 5 Jun 2001 16:34:58 -0000 Received: (qmail 2911 invoked from network); 5 Jun 2001 16:34:56 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:34:56 -0000 Received: (qmail 14393 invoked from network); 5 Jun 2001 16:45:18 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 16:45:18 -0000 Message-ID: <3B1D0C9E.8020001@comdev.cc> Date: Tue, 05 Jun 2001 09:45:18 -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'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> <3B1D0274.60706@comdev.cc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Not to reply to my own email, but... Mark Smith wrote: > (As an example, this is a personal beef I have with the FreeS/WAN folks. > Their product is _NOT_ IPSec. It looks like IPSec, it smells like > IPSec, it provides much of the same functionality as IPSec, but it > doesn't (by design) support SingleDES which is a requirement of the > IPSec protocol. It is therefor _NOT_ IPSec compliant.) Just to clarify here, the FreeS/WAN folks don't impliment SingleDES, not because it's a Good security model, but because they believe it to be a Bad security model. They believe that SingleDES is trivially breakable, in realtime, by readily available hardware, and is therefor no better than clear text. In addition, it gives the user a false sense of security and is therefor WORSE than clear text. While this is arguable either way, my point was that FreeS/WAN is not standards compliant because of this decision, not that it's a bad security model. They're actually doing it because its a better security model (ITheirHO). I just didn't want people thinking that I thought FreeS/WAN used a bad security model. :) -Mark From owner-seamoby@diameter.org Tue Jun 5 12:54: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 MAA25914 for ; Tue, 5 Jun 2001 12:54:30 -0400 (EDT) Received: (qmail 3621 invoked by alias); 5 Jun 2001 16:39:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3614 invoked by uid 200); 5 Jun 2001 16:39:13 -0000 Received: (qmail 3604 invoked from network); 5 Jun 2001 16:39:10 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:39:10 -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 f55GhK910487; Tue, 5 Jun 2001 09:43:20 -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 AHQ18035; Tue, 5 Jun 2001 09:43:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09586; Tue, 5 Jun 2001 09:43:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.3107.143800.256338@thomasm-u1.cisco.com> Date: Tue, 5 Jun 2001 09:43:15 -0700 (PDT) To: David Frascone Cc: Phillip Neumiller , "'seamoby'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement In-Reply-To: <20010605095154.E18382@newman.frascone.com> References: <0DF9FBC42474A24CA50F7A27FB08E0484454E9@meshpdc.meshnetworks.com> <20010605095154.E18382@newman.frascone.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 David Frascone writes: > I think I'm going off on a tangent, but at the IETF, wasn't it said that > the man-in-the-middle attack had no solution? Sure it has a solution. Shared keys, kerberos, PKI's... > And, that the MITM attacks > were being ignored, since there was no solution at all, unless you had prior > knowledge (i.e. the public key) of the party you were communicating with? Without direct knowledge, or a trusted third party that is correct. That said, CT does *not* have the same situation. In fact, it's pretty much a poster child for where direct knowledge or third parties is completely appropriate. Mike > > -Dave > > On Tue, Jun 05, 2001 at 10:46:32AM -0400, Phillip Neumiller wrote: > > Yes, I am sorry for the sarcastic remark. MIP is not reinventintg the > > wheel, > > the MAN in the middle attack was the reason IPsec could not be used (I > > believe). > > I hope that we can analyze the "applicability of IPsec" to SeaMoby CT > > without > > getting bogged down in reinventing IPsec here. I hope that the SeaMoby > > group > > can answer the requirements issue in reverse here and ask what is wrong with > > using IPsec for CT rather than what are all the possible attacks on the > > planet > > that could mess up CT.... > > > > Thanks, > > > > Phil > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Tuesday, June 05, 2001 10:42 AM > > > To: 'seamoby' > > > Cc: Phillip Neumiller > > > Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem > > > statement > > > > > > > > > Phillip Neumiller wrote: > > > > > > >>> But can we all agree that we don't need to re-invent a specific > > > >>> security solution for CT? Basically, you guys are stating that > > > >>> the IETF security area, with all it's experts did not do a good > > > >>> job designing current security solutions and that we need to > > > >>> re-invent the wheel once again. > > > > > > > > Why not? That's what mobile IP has done... :-) > > > > > > This needs additional information to be understood correctly. > > > There were two problems. > > > > > > 1. The Mobile IP group was instructed that use of AH was problematic > > > because the SPD selection mechanism did not mesh well with the > > > requirement to authenticate data in a destination option (vs., say, > > > authenticating the payload). > > > > > > 2. Further, it was determined that providing the mechanism (Binding > > > Update) for enabling direct routes between mobile node and > > > correspondent node was inadequate unless there was also a > > > reasonable mechanism for creating the security association for > > > carrying out the needed authorization check. > > > > > > The above quoted sentence _might_ be misinterpreted to mean that > > > people in the mobile-ip working group did not want to use IPsec > > > mechanisms. That would be wrong. > > > > > > Regards, > > > Charlie P. > > > > > From owner-seamoby@diameter.org Tue Jun 5 12:57: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 MAA26016 for ; Tue, 5 Jun 2001 12:57:23 -0400 (EDT) Received: (qmail 4289 invoked by alias); 5 Jun 2001 16:44:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4281 invoked by uid 200); 5 Jun 2001 16:44:14 -0000 Received: (qmail 4272 invoked from network); 5 Jun 2001 16:44:12 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:44:12 -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 f55Gs7U06148; Tue, 5 Jun 2001 09:54:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHQ18420; Tue, 5 Jun 2001 09:54:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09589; Tue, 5 Jun 2001 09:54:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.3754.301687.644989@thomasm-u1.cisco.com> Date: Tue, 5 Jun 2001 09:54:02 -0700 (PDT) To: Hannes Tschofenig Cc: "'Mark Smith '" , "''seamoby' '" Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement In-Reply-To: <71C667A91D79D41197910050DA46B3C902FC11@chello213047128084.15.vie.surfer.at> References: <71C667A91D79D41197910050DA46B3C902FC11@chello213047128084.15.vie.surfer.at> 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 Hannes Tschofenig writes: > # hi mark! > > What good is authorization without authentication? > > oldAR: "Yeah, this guy is authorized." > newAR: "Really? Who is he?" > oldAR: "Uh, he's, well, authorized." > newAR: "I don't buy it." > > Maybe I'm just paranoid, but I'd like to suggest that authentication and > authorization go hand-in-hand. > > # authorization and authentication do not always go hand-in-hand: > # an example: > # if you look at the proposals for the mn-cn binding update problem you > # will see that they all do not provide authentication but most of them > # try to solve the address ownership problem - an authorization > # problem. > > # but in most cases you are right. I really don't think that mipv6 address ownership problem is the best example. In fact, the proposals that have been submitted all assert identity, namely the IP address from whence they came. Most (all?) of the proposals for the CN problem depend on a return routability check as both a check on authentication -- CN challenges, MN responds to the challenge with the same IP address -- and authorization -- if the MN can respond at all, it must have been authorized by its attachment point, and so on through the network. Note that this is a weak form of both authentication and authorization (ie no strong crypto binding), but it does try to accomplish both goals. Mike From owner-seamoby@diameter.org Tue Jun 5 13:00: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 NAA26065 for ; Tue, 5 Jun 2001 13:00:03 -0400 (EDT) Received: (qmail 5053 invoked by alias); 5 Jun 2001 16:48:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5047 invoked by uid 200); 5 Jun 2001 16:48:55 -0000 Received: (qmail 5042 invoked from network); 5 Jun 2001 16:48:53 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:48:53 -0000 Received: (qmail 14905 invoked from network); 5 Jun 2001 16:59:20 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 16:59:20 -0000 Message-ID: <3B1D0FE9.50907@comdev.cc> Date: Tue, 05 Jun 2001 09:59:21 -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'" Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem statement References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> <3B1CF553.B3AAF6D0@iprg.nokia.com> <3B1CFE37.9060501@comdev.cc> <005801c0edde$1bc9b360$d45904d1@cisco.com> <3B1D0D96.6020907@comdev.cc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess my only response to this is that a trusted network has implicit authentication at setup time, so your example fits by description.. :) So, in short, we agree, I'd just like to make sure the authentication requirement makes it in there. Setting up a pre-authenticated, trusted network qualifies as authentication. -Mark > Melinda Shore wrote: > > > I'd like to suggest this depends more on the characteristics of the > > context being transfered. I don't care too much whether someone > > sees the current state of my header compression. I care a WHOLE LOT > > about someone seeing my authentication information. > > I think this is generally (okay, absolutely) true, with > the caveat below ... > > > > Maybe I'm just paranoid, but I'd like to suggest that authentication > > and authorization go hand-in-hand. > > > At the risk of inciting giggles, Hehehehehehehehe.... Oh. Sorry... :) > I should point out that > some networks are considered trusted and that pretty much > any traffic on them would be considered legitimate. You > could argue that this does constitute weak authentication. > Authentication and authorization are orthogonal and should > be treated as such. I don't think that it's always necessarily > the case that authorization needs to depend on > cryptographic authentication. > Melinda From owner-seamoby@diameter.org Tue Jun 5 13:03: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 NAA26165 for ; Tue, 5 Jun 2001 13:03:56 -0400 (EDT) Received: (qmail 5369 invoked by alias); 5 Jun 2001 16:50:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5362 invoked by uid 200); 5 Jun 2001 16:50:20 -0000 Received: (qmail 5347 invoked from network); 5 Jun 2001 16:50:17 -0000 Received: from unknown (HELO mailgw.local.ipunplugged.com) (@213.88.134.217) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 16:50:17 -0000 Received: from Gioconda (h242n1fls33o801.telia.com [213.64.180.242]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA08467; Tue, 5 Jun 2001 19:02:36 +0200 Reply-To: From: "Henrik Levkowetz" To: "'seamoby'" Cc: , "Gary Kenward" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 5 Jun 2001 19:00:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200106020120.f521Kux11772@minotaur.east.isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, As a follow-up on Allison's comments on the CT problem statement I've put together some text. I'm not fully certain I understand what Allison want added to the problem statement, but still, (making a guess) here's a first attempt. I would add this on to the existing section 8 of the CT problem statement: --- Performance also figures into eventual design and deployment of networks using context transfer. There are several problems which are associated with this, apart from the problems which influence the protocol design itself: - Which feature contexts merit transfer, and which not? This could be based on how fast the context changes, distance between forwarding nodes, the effort (in terms of time, message exchanges and calculation) required to set up context anew, and possibly other parameters. Some of these may be network dependent, rather than static. - Under which network conditions are the use of context transfer meaningful? Guidelines, or ways to calculate or estimate the benefit of context transfer may be needed in order to make sensible deployment of context transfer possible. - Is it possible during operation of a network to determine the usefulness of context transfer, in terms of (for each node or pair of nodes) how many changes in connectivity were assisted by context transfer, and how many were not? - Is it possible to set up parameters which guide the operation of context transfer, in such a manner that it can be sensibly and meaningfully adapted to different network conditions and topologies? --- Best, Henrik Allison wrote: > > Hi, Gary, > > > Pat: > > > > I'm afraid to ask, but I must. What's up with the ct problem statement? > > > > Gary > > Since Pat said he'd consult the ADs to answer this: > > I note that the WG last call on the CT problem statement ended two > days ago. Were there issues brought up to any of the authors or > in the design team mailing list? The working group list did not surface > any, that I saw, so I'll surface some that should be addressed before > we put the draft forward for advancement: > > > 1. The draft is very concise and easy to read - you want to spoil > us in the IESG by continuing this good trend by Seamoby (in the > footsteps of the paging problem statement)? [Needless > to say, this is _not_ an issue :> ] > > 2. I would like to see some discussion of the problem space of > how to evaluate when Internet CT makes sense and when it might > not. For instance, the point that if a feature context has > information that took many exchanges and/or computation to set > up, it is a better candidate. Frequency of change of features > would affect when CT is a good choice. The goal is not > to make any evaluations, but to give a problem space for the > protocol design work to come. > > How can the problem be described so that designers and eventual > deployers can distinguish between optimizations that provide benefits > only in narrowly constrained network circumstances and designs > that provide broad enough benefits to be used at Internet level. > > 3. Security considerations - the point about the sensitivity of > information carried in the CT is good, but the point about > CT not raising new security concerns is too much of a leap. > Even with the good design point of having the MN work but just > have a slower handoff when CT fails, there are risks to net and > nodes. Examples thought of quickly: > > Malicious context transferrors that give incorrect but > information that is not malformed, and damage/alter the MN's > connectivity > > Malicious CT requests causing DoS to the Forwarding Nodes that > have to process them. > > These are from quick thought. A safer comment would be that CT > probably will have novel security and requirements and design will > have to address. Check out draft-rescorla-cons-03.txt for more > ideas for the requirements phase. > > Thanks, > > Allison > > > > > From owner-seamoby@diameter.org Tue Jun 5 13:29:55 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 NAA26733 for ; Tue, 5 Jun 2001 13:29:54 -0400 (EDT) Received: (qmail 6752 invoked by alias); 5 Jun 2001 17:06:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6746 invoked by uid 200); 5 Jun 2001 17:06:39 -0000 Received: (qmail 6741 invoked from network); 5 Jun 2001 17:06:37 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 17:06:37 -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 f55HGY910470; Tue, 5 Jun 2001 10:16: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 AHQ19182; Tue, 5 Jun 2001 10:16:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09594; Tue, 5 Jun 2001 10:16:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.5103.557166.768874@thomasm-u1.cisco.com> Date: Tue, 5 Jun 2001 10:16:31 -0700 (PDT) To: Phillip Neumiller Cc: "'Melinda Shore'" , Louis-Nicolas Hamer , "'seamoby'" Subject: Security stuff was RE: Comments Re: [seamoby] ct problem statemen t In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.com> References: <0DF9FBC42474A24CA50F7A27FB08E0484454E8@meshpdc.meshnetworks.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 Phillip Neumiller writes: > > > But can we all agree that we don't need to re-invent a specific > > > security solution for CT? Basically, you guys are stating that > > > the IETF security area, with all it's experts did not do a good > > > job designing current security solutions and that we need to > > > re-invent the wheel once again. > > Why not? That's what mobile IP has done... :-) As many have pointed out, the need to create an application layer security scheme for BU's came as a rude awakening to the MIP WG. It certainly wasn't their desire. > > I don't see anybody saying that. There's actually a rich > > set of security mechanisms published by the IETF - the task > > is to identify the requirements and then choose the > > appropriate tool to solve the problem. Context transfer > > may have requirements, like performance, that would be > > difficult to meet if you were to wave hands and use IKE to > > key up and establish SAs. > > Why? Why can't this be done once and then kept around for > some deemed useful period of time? Right. There is probably a requirement hiding here: o the protocol MUST be able to pre-establish associations with CT peers to avoid possible keying, transport three way handshakes, etc, latency during context transfer. > > Is encryption (a block cipher presumably) needed? Yes. > Is authentication needed? Yes. > Is authorization needed? Yes. Both from the CT peer, and the whatever triggered the CT peer (eg, MN). > Will it work over/through common firewall systems and VPNs? Define "firewall". If you don't mean "NAT" then it should. > Will it work over/through NATs? I think this should be a *non* requirement. It's very likely that CT payloads would need to fixed up by the NAT which would destroy the ability to detect e2e message integrity, replays, etc. > Can it work with IPSEC? Define "work". If you mean tunnel mode, I think it's the same as your VPN question. Otherwise it sounds like solution space. > How does it work with PKI? Keying is orthogonal. > Does this conversation belong on the CT list? Probably. Mike From owner-seamoby@diameter.org Tue Jun 5 13:56: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 NAA27262 for ; Tue, 5 Jun 2001 13:56:21 -0400 (EDT) Received: (qmail 8951 invoked by alias); 5 Jun 2001 17:42:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8945 invoked by uid 200); 5 Jun 2001 17:42:16 -0000 Received: (qmail 8940 invoked from network); 5 Jun 2001 17:42:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 17:42:14 -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 KAA10140; Tue, 5 Jun 2001 10:52:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f55HqBJ02669; Tue, 5 Jun 2001 10:52:11 -0700 X-mProtect: Tue, 5 Jun 2001 10:52:11 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdYjUwii; Tue, 05 Jun 2001 10:52:09 PDT Message-ID: <3B1D1C49.12C1D41E@iprg.nokia.com> Date: Tue, 05 Jun 2001 10:52:09 -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: Mark Smith CC: "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> <3B1D0274.60706@comdev.cc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Smith wrote: > ......... Do I > believe that the NSA (to whom the CIA would pass the data for > processing) has solved the NP-Complete problem yet? If they have, > they've mannaged to keep their hats on probably one of the biggest > mathimatical advancements in history. Until I read this, I never thought that the strength of typical cryptographic algorithms was dependent on the NP-completeness problem. Can you say more about the relationship of the two? Regards, Charlie P. From owner-seamoby@diameter.org Tue Jun 5 14:28: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 OAA27863 for ; Tue, 5 Jun 2001 14:28:56 -0400 (EDT) Received: (qmail 9670 invoked by alias); 5 Jun 2001 18:17:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9664 invoked by uid 200); 5 Jun 2001 18:17:32 -0000 Received: (qmail 9659 invoked from network); 5 Jun 2001 18:17:30 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 18:17:30 -0000 Received: (qmail 17951 invoked from network); 5 Jun 2001 18:27:52 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 5 Jun 2001 18:27:52 -0000 Message-ID: <3B1D24A8.20900@comdev.cc> Date: Tue, 05 Jun 2001 11:27:52 -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'" Subject: Crypto Questions, was Re: Comments Re: [seamoby] ct problem statement References: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> <3B1D0274.60706@comdev.cc> <3B1D1C49.12C1D41E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit This is where I really need my reference books to confirm I'm not talking out of my rear-end. Unfortunatly, I don't have them handy, so if this smells a bit funny, you know why. :) It was pointed out to me that factoring (RSA) is not related directly to the NP-Complete problem set. However, it has not been proven to be NOT as difficult as the NP-Complete problem yet, so for the time being, its as good. I guess it would be more correct to say that factoring is thought to be as difficult as the NP-Complete problem, which is different than saying that solving the NP-Complete problem would solve the Factoring problem, thus breaking RSA. So, my statement was incorrect. Even if the NSA had solved the NP-Complete problem, that still wouldn't necessarily break RSA. Although, solving the factoring problem would still be pretty darn tough to keep a cover on. As an aside, I'm talking about public key crypto-systems when talking about order of difficulty, and specifically RSA when talking about factoring. Things like DES are a totally different design and are broken differently. -Mark ps: If anyone has any other questions about this, I'd be happy to discuss it, but lets take it off the list. I only posted this here to correct my earlier statements. -mts Charles E. Perkins wrote: > Mark Smith wrote: > > >> ......... Do I >> believe that the NSA (to whom the CIA would pass the data for >> processing) has solved the NP-Complete problem yet? If they have, >> they've mannaged to keep their hats on probably one of the biggest >> mathimatical advancements in history. > > > Until I read this, I never thought that the strength of typical > cryptographic algorithms was dependent on the NP-completeness > problem. Can you say more about the relationship of the two? > > Regards, > Charlie P. From owner-seamoby@diameter.org Tue Jun 5 14:31: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 OAA27901 for ; Tue, 5 Jun 2001 14:31:34 -0400 (EDT) Received: (qmail 10149 invoked by alias); 5 Jun 2001 18:20:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10140 invoked by uid 200); 5 Jun 2001 18:20:05 -0000 Received: (qmail 10121 invoked from network); 5 Jun 2001 18:20:01 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 18:20:01 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 14:30:26 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454EA@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Charles E. Perkins'" , Mark Smith Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 5 Jun 2001 14:30:26 -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 Hi Charlie, Factoring is NP. Trying all primes less sqrt(N) = O(e^ck); k = ln N, c= constant Quadratic Field Sieve O[e@ck^1/2(ln k)^1/2] Number Field Sieve O[e^ck^1/3(ln k)^2/3] All exponential... Now if you happen to have a quantum computer available to you Shore algorithm for factoring is O[k^3], i.e. polynomial!!! Thanks, Phyil > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Tuesday, June 05, 2001 1:52 PM > To: Mark Smith > Cc: 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > Mark Smith wrote: > > > ......... Do I > > believe that the NSA (to whom the CIA would pass the data for > > processing) has solved the NP-Complete problem yet? If they have, > > they've mannaged to keep their hats on probably one of the biggest > > mathimatical advancements in history. > > Until I read this, I never thought that the strength of typical > cryptographic algorithms was dependent on the NP-completeness > problem. Can you say more about the relationship of the two? > > Regards, > Charlie P. > From owner-seamoby@diameter.org Tue Jun 5 19:55: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 TAA01703 for ; Tue, 5 Jun 2001 19:55:35 -0400 (EDT) Received: (qmail 13137 invoked by alias); 5 Jun 2001 23:44:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13131 invoked by uid 200); 5 Jun 2001 23:44:23 -0000 Received: (qmail 13126 invoked from network); 5 Jun 2001 23:44:19 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jun 2001 23:44:19 -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 f55Nqt900546; Tue, 5 Jun 2001 16:52:55 -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 AHT03788; Tue, 5 Jun 2001 16:52:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA09664; Tue, 5 Jun 2001 16:52:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.28886.301439.190655@thomasm-u1.cisco.com> Date: Tue, 5 Jun 2001 16:52:54 -0700 (PDT) To: "Gary Kenward" Cc: "'Kulwinder Atwal'" , "'Michael Thomas'" , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C9F5C93@zcard031.ca.nortel.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 Gary Kenward writes: > I guess so. What if the CIA decides to record all your email and pass > it through their supercomputers for a week. Would you feel your privacy is > safe? > > I willing to bet that none of the security experts would > be willing to state that any protocol solution is going to protect you > if the operator is unwilling or against supporting it, particularly if > they are the government. > > The IETF does not, can not force compliance, it can only recommend. > And as you have identified, there is no one who has the authority to > force compliance. And we might get hit by an asteriod in 15 minutes too. We are only talking about protocol requirements. There is no reason for the protocol or its requirements to specify how an operator can cut corners. There is a requirement that the protocol must meet the security requirements of authentication, authorization, privacy, DoS resilience, etc, etc, and that those mechanisms MUST be implemented. What goes on beyond that is completely out of scope of IETF. Mike From owner-seamoby@diameter.org Wed Jun 6 04: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 EAA23607 for ; Wed, 6 Jun 2001 04:30:34 -0400 (EDT) Received: (qmail 14302 invoked by alias); 6 Jun 2001 08:19:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14296 invoked by uid 200); 6 Jun 2001 08:19:16 -0000 Received: (qmail 14287 invoked from network); 6 Jun 2001 08:19:13 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 08:19:13 -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 f568TVq02431 for ; Wed, 6 Jun 2001 11:29:31 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 6 Jun 2001 11:29:24 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 6 Jun 2001 11:29:24 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B08B@eseis04nok> From: john.loughney@nokia.com To: gkenward@nortelnetworks.com, seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: RE: [seamoby] Security Considerations - new wording Date: Wed, 6 Jun 2001 11:29:17 +0300 Sensitivity: Company-Confidential 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 Gary, Good suggestions. I was actually referring to DOS and other similar attacks with the euphemism "transfer legitimacy". Not being a security guru myself, I wasn't sure if there was an acceptable general term, so I created one. [ ] That's what I thought, I just thought additional text would be good to add. I was purposely trying to avoid being too specific in the problem statement. I worry that we could end up with a shopping list of potential threats. [ ] Hopefully, it should be enough that we list some possible security threats that CT might cause (or at least open the possibility for bad guys to do bad things). > - prevention of DOS-style attacks. Context transfer > MUST NOT create any new opportunities for denial of > service (DOS) attacks. These include (but are not > limited to): flooding of bogus context in order > to overrun the capacity of the target node; and the > redirection of context in order to prevent the > successful completion of the context transfer. > > How's that? [ ] Further comment: The text I proposeed does sound like a requirement. If we change the 2nd sentence to: Context transfer may create new opportunities for DOS ... br, John From owner-seamoby@diameter.org Wed Jun 6 06:08: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 GAA24458 for ; Wed, 6 Jun 2001 06:08:03 -0400 (EDT) Received: (qmail 15098 invoked by alias); 6 Jun 2001 09:56:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15091 invoked by uid 200); 6 Jun 2001 09:56:33 -0000 Received: (qmail 15086 invoked from network); 6 Jun 2001 09:56:31 -0000 Received: from chello213047128084.15.vie.surfer.at (HELO ssaserv1.roesti.cc) (213.47.128.84) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 09:56:31 -0000 Received: by chello213047128084.15.vie.surfer.at with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 12:02:22 +0200 Message-ID: <71C667A91D79D41197910050DA46B3C902FC17@chello213047128084.15.vie.surfer.at> From: Hannes Tschofenig To: "'Michael Thomas '" , Hannes Tschofenig Cc: "''Mark Smith ' '" , "'''seamoby' ' '" Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Date: Wed, 6 Jun 2001 12:02:19 +0200 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 thomas! Hannes Tschofenig writes: > # hi mark! > > What good is authorization without authentication? > > oldAR: "Yeah, this guy is authorized." > newAR: "Really? Who is he?" > oldAR: "Uh, he's, well, authorized." > newAR: "I don't buy it." > > Maybe I'm just paranoid, but I'd like to suggest that authentication and > authorization go hand-in-hand. > > # authorization and authentication do not always go hand-in-hand: > # an example: > # if you look at the proposals for the mn-cn binding update problem you > # will see that they all do not provide authentication but most of them > # try to solve the address ownership problem - an authorization > # problem. > > # but in most cases you are right. I really don't think that mipv6 address ownership problem is the best example. % it may not be the best example related to CT % but it shows authorization without authentication. In fact, the proposals that have been submitted all assert identity, namely the IP address from whence they came. % they show two things: % - the mobile node is at the current location (CoA) and % is therefore able to reply to a response from a CN. % - and some proposals make use of the home agent to % actively participate in the protocol. % additionally the existing infrastructure is used to limit % the location of an adversary. Most (all?) % the first proposal "purpose built keys" does not provide % address ownership - the home address is never used in the % protocol itself % the protocol however tries to introduce an interesting property: % if the mobile node was once able to send the EID to the CN % then the CN can be sure that a BU is from the same sender. of the proposals for the CN problem depend on a return routability check as both a check on authentication -- CN challenges, MN responds to the challenge with the same IP address -- and authorization -- if the MN can respond at all, it must have been authorized by its attachment point, and so on through the network. Note that this is a weak form of both authentication and authorization (ie no strong crypto binding), but it does try to accomplish both goals. % i am not quite sure if i would call this authentication because: % if you look at a traditional authentication protocol then % you have either a shared secret between those two parties or % you rely on a trusted third party (with a trust relationship % between both entities to the TTP). % here we have neither a shared secret nor a infrastructure behind % those entities. there is no trust relationship between the CN and the % HA (or mn's home network). % % in the mipv6 case case the best you can do with the proposed % protocols is to % - limit the location of the adversary (by using an esp tunnel % between the HA and the MN,...) % - and avoid passive attacks whereby the final key can be computed % by eavesdropping data transmited between the MN and the CN. % (hence all propals show a vulnerability against active attacks) % hannes Mike From owner-seamoby@diameter.org Wed Jun 6 06:17: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 GAA24560 for ; Wed, 6 Jun 2001 06:17:30 -0400 (EDT) Received: (qmail 15575 invoked by alias); 6 Jun 2001 10:04:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15569 invoked by uid 200); 6 Jun 2001 10:04:58 -0000 Received: (qmail 15564 invoked from network); 6 Jun 2001 10:04:55 -0000 Received: from porsta.cs.helsinki.fi (root@128.214.48.124) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 10:04:55 -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 f56AE3m30613; Wed, 6 Jun 2001 13:14:04 +0300 Date: Wed, 6 Jun 2001 13:14:02 +0300 (EEST) From: Jukka Manner To: James Kempf cc: , , , , Subject: Re: [seamoby] Re: Wireless Terminology Draft In-Reply-To: <200105312041.NAA01314@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, it seems to me that our initial attempt at defining "wireless and mobile" terminology is getting support, or? Could I ask of you and others interested to provide feedback on the latest terminology draft. So far, I have received two questions about some terms, but nothing more. We intend to edit a new version for the London meeting. Perhaps we could also discuss the issue there too, and see if we should continue the work on the latest terminology draft or take it as the basis and start a totally new one, with or without the MANET terminology. I would see that this kind of draft would be "cross-WG" work (seamoby, mip, manet), so maybe it should be kept as an individual document/submission and aim as an Informational RFC later. BR, Jukka On Thu, 31 May 2001, James Kempf wrote: > 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 Wed Jun 6 07:02: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 HAA25191 for ; Wed, 6 Jun 2001 07:02:20 -0400 (EDT) Received: (qmail 16082 invoked by alias); 6 Jun 2001 10:51:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16076 invoked by uid 200); 6 Jun 2001 10:51:05 -0000 Received: (qmail 16071 invoked from network); 6 Jun 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; 6 Jun 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 HAA25019; Wed, 6 Jun 2001 07:01:06 -0400 (EDT) Message-Id: <200106061101.HAA25019@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-hamid-seamoby-ct-fwk-00.txt Date: Wed, 06 Jun 2001 07:01:06 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Context Transfer Framework Author(s) : H. Syed, G. Kenward Filename : draft-hamid-seamoby-ct-fwk-00.txt Pages : 14 Date : 05-Jun-01 This document proposes a framework for context transfer between the access routers. The framework identifies the various functional elements that participate in the process of context transfer and the protocols required to exchange information between the functional entities. Included are a few samples of context transfer scenarios to assist in explaining the interactions of the entities in the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamid-seamoby-ct-fwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010605122915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hamid-seamoby-ct-fwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010605122915.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Wed Jun 6 08:48: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 IAA28634 for ; Wed, 6 Jun 2001 08:48:09 -0400 (EDT) Received: (qmail 16845 invoked by alias); 6 Jun 2001 12:36:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16838 invoked by uid 200); 6 Jun 2001 12:36:34 -0000 Received: (qmail 16833 invoked from network); 6 Jun 2001 12:36:31 -0000 Received: from del2.vsnl.net.in (202.54.15.30) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 12:36:31 -0000 Received: from vishnu.vishnu (unknown [202.54.100.4]) by del2.vsnl.net.in (Postfix) with ESMTP id 239EC3F2E5 for ; Wed, 6 Jun 2001 18:17:24 +0530 (IST) Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MLZP8KDC; Wed, 6 Jun 2001 18:16:05 +0530 Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06062001-181535-88.MMD@vishnu; Wed, 6 Jun 2001 18:15:35 +0530 Delivered-To: sandy@amdale.com Received: (qmail 5328 invoked by uid 104); 6 Jun 2001 12:39:20 -0000 Delivered-To: amdale.com-sandeepj@AMDALE.COM Received: (qmail 5305 invoked by alias); 6 Jun 2001 12:39:20 -0000 Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 6 Jun 2001 12:39:20 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26178 for ietf-123-outbound.01@ietf.org; Wed, 6 Jun 2001 07:45: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 HAA25887 for ; Wed, 6 Jun 2001 07:01:08 -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 HAA25019; Wed, 6 Jun 2001 07:01:06 -0400 (EDT) Message-Id: <200106061101.HAA25019@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-hamid-seamoby-ct-fwk-00.txt Date: Wed, 06 Jun 2001 07:01:06 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Context Transfer Framework Author(s) : H. Syed, G. Kenward Filename : draft-hamid-seamoby-ct-fwk-00.txt Pages : 14 Date : 05-Jun-01 This document proposes a framework for context transfer between the access routers. The framework identifies the various functional elements that participate in the process of context transfer and the protocols required to exchange information between the functional entities. Included are a few samples of context transfer scenarios to assist in explaining the interactions of the entities in the framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamid-seamoby-ct-fwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010605122915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hamid-seamoby-ct-fwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010605122915.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Wed Jun 6 09:02:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29098 for ; Wed, 6 Jun 2001 09:02:46 -0400 (EDT) Received: (qmail 17411 invoked by alias); 6 Jun 2001 12:51:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17401 invoked by uid 200); 6 Jun 2001 12:51:28 -0000 Received: (qmail 17392 invoked from network); 6 Jun 2001 12:51:25 -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; 6 Jun 2001 12:51:25 -0000 Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f56D19E16091; Wed, 6 Jun 2001 09:01:13 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 6 Jun 2001 09:00:52 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 09:00:52 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0B7@zcard031.ca.nortel.com> From: "Hamid Syed" To: seamoby-context@cdma-2000.org Cc: seamoby@cdma-2000.org Subject: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt Date: Wed, 6 Jun 2001 09:01:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EE88.C0B56450" 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_01C0EE88.C0B56450 Content-Type: text/plain Hello CT Folks, I have submitted a framework draft for context transfer. I would appreciate and welcome any comments on the draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt cheers -Hamid ------_=_NextPart_001_01C0EE88.C0B56450 Content-Type: text/html Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt

Hello CT Folks,

I have submitted a framework draft for = context transfer. I would appreciate and welcome any comments on the = draft.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-hamid-seamob= y-ct-fwk-00.txt

cheers

-Hamid


------_=_NextPart_001_01C0EE88.C0B56450-- From owner-seamoby@diameter.org Wed Jun 6 11:39: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 LAA03380 for ; Wed, 6 Jun 2001 11:38:57 -0400 (EDT) Received: (qmail 18456 invoked by alias); 6 Jun 2001 15:26:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18450 invoked by uid 200); 6 Jun 2001 15:26:01 -0000 Received: (qmail 18445 invoked from network); 6 Jun 2001 15:25:58 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 15:25:58 -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 JAA28831; Wed, 6 Jun 2001 09:36:22 -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 IAA22239; Wed, 6 Jun 2001 08:36:22 -0700 (PDT) Message-Id: <200106061536.IAA22239@heliopolis.eng.sun.com> Date: Wed, 6 Jun 2001 08:36:22 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] Re: Wireless Terminology Draft To: James.Kempf@Sun.COM, jmanner@cs.Helsinki.FI Cc: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, hmsyed@nortelnetworks.com, seamoby@diameter.org, manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Bounx9EvJfcSnIydCpPZAA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Jukka, This sounds like a good plan, thank you for stepping up to do it. I intend to review the latest document in the URL Charlie sent out. I agree that this is likely to be a cross working group document. I don't know of any specific IETF mechanism to address this procedurally, but I think it will be important to get review by members of all working groups, so we can get agreement on terminology going forward. I think the document should definitely be "draft-ietf-..." if that is possible, perhaps we can get guidance from the ADs on this. I also think making it an informational RFC should be the goal. At this point, I can't see this being a separate working group or even a BOF, perhaps it could be assigned provisionally to one of the three working groups with the least amount on its charter with the proviso that the results pass through the other two. jak >Date: Wed, 6 Jun 2001 13:14:02 +0300 (EEST) >From: Jukka Manner >To: James Kempf >cc: , , , , >Subject: Re: [seamoby] Re: Wireless Terminology Draft > > > Hi all, > > it seems to me that our initial attempt at defining "wireless and >mobile" terminology is getting support, or? Could I ask of you and others >interested to provide feedback on the latest terminology draft. So far, I have >received two questions about some terms, but nothing more. We intend to >edit a new version for the London meeting. Perhaps we could also discuss the >issue there too, and see if we should continue the work on the latest >terminology draft or take it as the basis and start a totally new one, with or >without the MANET terminology. I would see that this kind of draft would be >"cross-WG" work (seamoby, mip, manet), so maybe it should be kept as an >individual document/submission and aim as an Informational RFC later. > > BR, > > Jukka > >On Thu, 31 May 2001, James Kempf wrote: > >> 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 Wed Jun 6 13:07:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05703 for ; Wed, 6 Jun 2001 13:07:25 -0400 (EDT) Received: (qmail 19113 invoked by alias); 6 Jun 2001 16:55:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19107 invoked by uid 200); 6 Jun 2001 16:55:50 -0000 Received: (qmail 19102 invoked from network); 6 Jun 2001 16:55:48 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 16:55:48 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 13:06:12 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454F2@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'James Kempf'" , jmanner@cs.Helsinki.FI Cc: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, hmsyed@nortelnetworks.com, seamoby@diameter.org, manet@itd.nrl.navy.mil Subject: RE: [seamoby] Re: Wireless Terminology Draft Date: Wed, 6 Jun 2001 13:06: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: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Wednesday, June 06, 2001 11:36 AM > I > don't know of any specific IETF mechanism to address this > procedurally, > but I think it will be important to get review by members of all > working groups, so we can get agreement on terminology going forward. Hi, There is the IETF general area.... with Process for Organization of Internet Standards ONg (poisson) Last Modified: 17-May-01 I suggest asking either: James Galvin John Klensin if a cross-WG terminology document would fall into their stewardship. From owner-seamoby@diameter.org Wed Jun 6 13:40:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06534 for ; Wed, 6 Jun 2001 13:40:25 -0400 (EDT) Received: (qmail 20339 invoked by alias); 6 Jun 2001 17:29:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20333 invoked by uid 200); 6 Jun 2001 17:29:21 -0000 Received: (qmail 20328 invoked from network); 6 Jun 2001 17:29:19 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 17:29:19 -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 KAA00153; Wed, 6 Jun 2001 10:39:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f56HdFk25931; Wed, 6 Jun 2001 10:39:15 -0700 X-mProtect: Wed, 6 Jun 2001 10:39:15 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdcfS3e7; Wed, 06 Jun 2001 10:39:12 PDT Message-ID: <3B1E6AC1.B808ACB1@iprg.nokia.com> Date: Wed, 06 Jun 2001 10:39:13 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Syed CC: Gary Kenward , Seamless Mobility Working Group Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt References: <9FBD322B7824D511B36900508BF93C9C1CD0B7@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid, We previously published a framework document for consideration within [seamoby]. Our emphasis was on context feature classification and message flows. Your document (which I reckon is to be considered an individual submission) does not have much about feature classfication, and at first glance seems to be a lot more emphasis on groupings of access routers. I would like to suggest that establishing communities or neighborhoods or groups of access routers could be handled by a protocol which would be separate than the protocol for doing the context transfer, and further that in many instances it wouldn't be necessary to make the access router groups at all. I wondered whether you had taken a look at our previous framework draft, and if so whether you think meet the requirements. If you didn't see it yet, and if you'd like to take a look, here is the URL: http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt Regards, Charlie P. > Hamid Syed wrote: > > Hello CT Folks, > > I have submitted a framework draft for context transfer. I would appreciate > and welcome any comments on the draft. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > cheers > > -Hamid From owner-seamoby@diameter.org Wed Jun 6 18:21: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 SAA09970 for ; Wed, 6 Jun 2001 18:21:34 -0400 (EDT) Received: (qmail 22384 invoked by alias); 6 Jun 2001 22:10:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22378 invoked by uid 200); 6 Jun 2001 22:10:11 -0000 Received: (qmail 22373 invoked from network); 6 Jun 2001 22:10:06 -0000 Received: from gigi.excite.com (199.172.152.110) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jun 2001 22:10:06 -0000 Received: from wiser.excite.com ([199.172.152.234]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20010606222007.VUUO3984.gigi.excite.com@wiser.excite.com>; Wed, 6 Jun 2001 15:20:07 -0700 Message-ID: <667419.991866007074.JavaMail.imail@wiser.excite.com> Date: Wed, 6 Jun 2001 15:20:05 -0700 (PDT) From: gary kenward To: Mark Smith , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 47.248.0.43 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 05 Jun 2001 09:01:56 -0700, Mark Smith wrote: > > (*) Where "good security model" is defined as "sufficient for the > purpose." Keep in mind that the idea behind security in a situation > like this is just to make sure it's not the weakest link. There's > always Rubber Hose Cryptanalysis, where the Cryptanalysist beats the > target over the head and shoulders with a rubber hose until they give up > the information they're after. _MUCH_ more effective than attacking the > system or the encryption algorythm in a number of cases. > *chuckle* Thanks. Gary _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-seamoby@diameter.org Wed Jun 6 19:08: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 TAA10400 for ; Wed, 6 Jun 2001 19:07:59 -0400 (EDT) Received: (qmail 22980 invoked by alias); 6 Jun 2001 22:56:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22974 invoked by uid 200); 6 Jun 2001 22:56:56 -0000 Received: (qmail 22962 invoked by uid 500); 6 Jun 2001 22:56:53 -0000 Date: Wed, 6 Jun 2001 15:56:53 -0700 From: Pat Calhoun To: Phillip Neumiller Cc: "'James Kempf'" , jmanner@cs.Helsinki.FI, Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, hmsyed@nortelnetworks.com, seamoby@diameter.org, manet@itd.nrl.navy.mil Subject: Re: [seamoby] Re: Wireless Terminology Draft Message-ID: <20010606155652.T12278@charizard.diameter.org> Mail-Followup-To: Phillip Neumiller , 'James Kempf' , jmanner@cs.Helsinki.FI, Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, hmsyed@nortelnetworks.com, seamoby@diameter.org, manet@itd.nrl.navy.mil References: <0DF9FBC42474A24CA50F7A27FB08E0484454F2@meshpdc.meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484454F2@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Wed, Jun 06, 2001 at 01:06:07PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 06, 2001 at 01:06:07PM -0400, Phillip Neumiller wrote: > > > > -----Original Message----- > > From: James Kempf [mailto:James.Kempf@Sun.COM] > > Sent: Wednesday, June 06, 2001 11:36 AM > > I > > don't know of any specific IETF mechanism to address this > > procedurally, > > but I think it will be important to get review by members of all > > working groups, so we can get agreement on terminology going forward. I have some ideas, but need to run them through Allison. I'll be talking to her later this week, and will try to figure out an answer to this. PatC From owner-seamoby@diameter.org Thu Jun 7 07:09:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03496 for ; Thu, 7 Jun 2001 07:09:20 -0400 (EDT) Received: (qmail 24327 invoked by alias); 7 Jun 2001 10:57:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24321 invoked by uid 200); 7 Jun 2001 10:57:32 -0000 Received: (qmail 24316 invoked from network); 7 Jun 2001 10:57:30 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 10:57:30 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03318; Thu, 7 Jun 2001 07:07:28 -0400 (EDT) Message-Id: <200106071107.HAA03318@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-hamid-seamoby-ct-qos-context-00.txt Date: Thu, 07 Jun 2001 07:07:28 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : QoS (DiffServ) Context Transfer Author(s) : H. Syed, M. Jaseemuddin Filename : draft-hamid-seamoby-ct-qos-context-00.txt Pages : 7 Date : 06-Jun-01 The intent of this draft is to describe the unique requirements for transfer of DiffServ QoS context and to detail the specific data which must be transferred in order to maintain the service provisioning to the IP QoS flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamid-seamoby-ct-qos-context-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606101025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hamid-seamoby-ct-qos-context-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606101025.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Jun 7 08:53: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 IAA05707 for ; Thu, 7 Jun 2001 08:53:10 -0400 (EDT) Received: (qmail 25056 invoked by alias); 7 Jun 2001 12:39:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25050 invoked by uid 200); 7 Jun 2001 12:39:46 -0000 Received: (qmail 25045 invoked from network); 7 Jun 2001 12:39:43 -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; 7 Jun 2001 12:39:43 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57CnVE09029 for ; Thu, 7 Jun 2001 08:49:31 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 08:49:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 08:49:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0BB@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Charles E. Perkins'" Cc: "Gary Kenward" , Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt Date: Thu, 7 Jun 2001 08:49:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF50.53898F00" 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_01C0EF50.53898F00 Content-Type: text/plain Hello Charlie, I am glad that you read the draft. Please see my comments below. > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com] > Sent: Wednesday, June 06, 2001 1:39 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility Working Group > Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > > Hello Hamid, > > We previously published a framework document for consideration > within [seamoby]. Our emphasis was on context feature classification > and message flows. Your document (which I reckon is to be considered > an individual submission) does not have much about feature > classfication, and at first glance seems to be a lot more emphasis > on groupings of access routers. [Syed, Hamid [WDLN2:AN22:EXCH]] I disagree. Infact the draft attempts to cover a broader range of the over all problem. We do not believe that just shipping the context from one access router to another can provide a "seamless" handover. Identifying the potential context candidates and a close interworking with the mobility mechanism are equally important to be addressed in the context transfer framework. Our draft is focused on distributing the functional roles to the ct entities and defining interfaces between them. The context transfer protocol is only one aspect of the over all problem domain and that is what your draft is proposing, a solution for shipping context from one AR to the other. I may consider your submission as a candidate solution for context trasnfer protocol but this is not a framework. I believe that frameworks should focus on functional models and interface definitions and the details of individual protocols must be taken ouitside the framework document. > I would like to suggest that establishing communities or neighborhoods > or groups of access routers could be handled by a protocol which would > be separate than the protocol for doing the context transfer, and > further that in many instances it wouldn't be necessary to make the > access router groups at all. [Syed, Hamid [WDLN2:AN22:EXCH]] This is what the framework has captured, a separate protocol for context group management and another protocol for context transfer. I would say, identifying a suitable candidate for handover amongst the context group members will help minimizing the service disruption during handover. Defining a handover candidate discovery protocol is already part of Seamoby WG charter and our framework shows how the functional entities interact with each other through the standard interfaces. > > I wondered whether you had taken a look at our previous framework > draft, and if so whether you think meet the requirements. If you > didn't see it yet, and if you'd like to take a look, here is the URL: > > http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt > > Regards, > Charlie P. [Syed, Hamid [WDLN2:AN22:EXCH]] Thanx for your comments. > > Hamid Syed wrote: > > > > Hello CT Folks, > > > > I have submitted a framework draft for context transfer. I would > appreciate > > and welcome any comments on the draft. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > > > cheers > > > > -Hamid ------_=_NextPart_001_01C0EF50.53898F00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt

Hello = Charlie,

I am glad that you = read the draft. Please see my comments below.

    -----Original Message-----
    From:   Charles E. Perkins = [SMTP:charliep@IPRG.nokia.com]
    Sent:   Wednesday, June 06, 2001 1:39 PM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility = Working Group
    Subject:       = Re: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt


    Hello Hamid,

    We previously published a framework = document for consideration
    within [seamoby].  Our emphasis = was on context feature classification
    and message flows.  Your = document (which I reckon is to be considered
    an individual submission) does not = have much about feature
    classfication, and at first glance = seems to be a lot more emphasis
    on groupings of access = routers.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I disagree. Infact the draft attempts to cover = a broader range of the over all problem. We do not believe that just = shipping the context from one access router to another can provide a = "seamless" handover. Identifying the potential context = candidates and a close interworking with the mobility mechanism are = equally important to be addressed in the context transfer framework. = Our draft is focused on distributing the functional roles to the ct = entities and defining interfaces between them. The context transfer = protocol is only one aspect of the over all problem domain and that is = what your draft is proposing, a solution for shipping context from one = AR to the other. I may consider your submission as a candidate solution = for context trasnfer protocol but this is not a framework. I believe = that frameworks should focus on functional models and interface = definitions and the details of individual protocols must be taken = ouitside the framework document.

    I would like to suggest that = establishing communities or neighborhoods
    or groups of access routers could be = handled by a protocol which would
    be separate than the protocol for = doing the context transfer, and
    further that in many instances it = wouldn't be necessary to make the
    access router groups at all.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]   This is what the framework has captured, = a separate protocol for context group management and another protocol = for context transfer. I would say, identifying a suitable candidate for = handover amongst the context group members will help minimizing the = service disruption during handover.  Defining a handover candidate = discovery protocol is already part of Seamoby WG charter and our = framework shows how the functional entities interact with each other = through the standard interfaces.

     
    I wondered whether you had taken a = look at our previous framework
    draft, and if so whether you think = meet the requirements.  If you
    didn't see it yet, and if you'd like = to take a look, here is the URL:
            http://search.ietf.org/internet-drafts/draft-koodli-se= amoby-ctv6-00.txt

    Regards,
    Charlie P.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Thanx for your comments.


    > Hamid Syed wrote:
    >
    > Hello CT Folks,
    >
    > I have submitted a framework = draft for context transfer. I would appreciate
    > and welcome any comments on the = draft.
    >
    > A URL for this Internet-Draft = is:
    > http://www.ietf.org/internet-drafts/draft-hamid-seamob= y-ct-fwk-00.txt
    >
    > cheers
    >
    > -Hamid

------_=_NextPart_001_01C0EF50.53898F00-- From owner-seamoby@diameter.org Thu Jun 7 09:54:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07400 for ; Thu, 7 Jun 2001 09:54:22 -0400 (EDT) Received: (qmail 25731 invoked by alias); 7 Jun 2001 13:42:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25724 invoked by uid 200); 7 Jun 2001 13:42:44 -0000 Received: (qmail 25715 invoked from network); 7 Jun 2001 13:42:41 -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; 7 Jun 2001 13:42:41 -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 f57DqZE23152; Thu, 7 Jun 2001 09:52:35 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 7 Jun 2001 09:52:33 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 09:52:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0BF@zcard031.ca.nortel.com> From: "Hamid Syed" To: seamoby-context@cdma-2000.org Cc: seamoby@cdma-2000.org Subject: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.txt Date: Thu, 7 Jun 2001 09:52:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF59.27BED700" 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_01C0EF59.27BED700 Content-Type: text/plain Hello CT Folks, I have submitted a draft for qos context transfer. The intent of this draft is to describe the unique requirements for transfer of DiffServ QoS context and to detail the specific data which must be transferred in order to maintain the service provisioning to the IP QoS flows. I would appreciate and welcome any comments on the draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-qos-context-00.tx t -Hamid ------_=_NextPart_001_01C0EF59.27BED700 Content-Type: text/html Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.txt

Hello CT Folks,

I have submitted a draft for qos = context transfer. The intent of this draft is to describe the unique = requirements for transfer of DiffServ QoS context and to detail the = specific data which must be transferred in order to maintain the = service provisioning to the IP QoS flows.

I would appreciate and welcome any = comments on the draft.


A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-hamid-seamob= y-ct-qos-context-00.txt


-Hamid

------_=_NextPart_001_01C0EF59.27BED700-- From owner-seamoby@diameter.org Thu Jun 7 10:07:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07660 for ; Thu, 7 Jun 2001 10:07:09 -0400 (EDT) Received: (qmail 26295 invoked by alias); 7 Jun 2001 13:55:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26289 invoked by uid 200); 7 Jun 2001 13:55:10 -0000 Received: (qmail 26284 invoked from network); 7 Jun 2001 13:55:03 -0000 Received: from del2.vsnl.net.in (202.54.15.30) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 13:55:03 -0000 Received: from vishnu.vishnu (unknown [203.197.193.57]) by del2.vsnl.net.in (Postfix) with ESMTP id EA82F3F624 for ; Thu, 7 Jun 2001 19:35:48 +0530 (IST) Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MLZP8KH6; Thu, 7 Jun 2001 19:34:19 +0530 Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06072001-193107-240.MMD@vishnu; Thu, 7 Jun 2001 19:31:07 +0530 Delivered-To: sandy@amdale.com Received: (qmail 8253 invoked by uid 104); 7 Jun 2001 12:33:21 -0000 Delivered-To: amdale.com-sandeepj@AMDALE.COM Received: (qmail 8234 invoked by alias); 7 Jun 2001 12:33:21 -0000 Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 7 Jun 2001 12:33:21 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28911 for ietf-123-outbound.01@ietf.org; Thu, 7 Jun 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 HAA28745 for ; Thu, 7 Jun 2001 07:07:38 -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 HAA03318; Thu, 7 Jun 2001 07:07:28 -0400 (EDT) Message-Id: <200106071107.HAA03318@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-hamid-seamoby-ct-qos-context-00.txt Date: Thu, 07 Jun 2001 07:07:28 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : QoS (DiffServ) Context Transfer Author(s) : H. Syed, M. Jaseemuddin Filename : draft-hamid-seamoby-ct-qos-context-00.txt Pages : 7 Date : 06-Jun-01 The intent of this draft is to describe the unique requirements for transfer of DiffServ QoS context and to detail the specific data which must be transferred in order to maintain the service provisioning to the IP QoS flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hamid-seamoby-ct-qos-context-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606101025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hamid-seamoby-ct-qos-context-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hamid-seamoby-ct-qos-context-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606101025.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Jun 7 10:38: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 KAA08154 for ; Thu, 7 Jun 2001 10:38:32 -0400 (EDT) Received: (qmail 27268 invoked by alias); 7 Jun 2001 14:27:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27261 invoked by uid 200); 7 Jun 2001 14:27:06 -0000 Received: (qmail 27256 invoked from network); 7 Jun 2001 14:27:05 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 14:27:05 -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 HAA01912; Thu, 7 Jun 2001 07:37:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57Eb2O14647; Thu, 7 Jun 2001 07:37:02 -0700 X-mProtect: Thu, 7 Jun 2001 07:37:02 -0700 Nokia Silicon Valley Messaging Protection Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd3vARvY; Thu, 07 Jun 2001 07:36:59 PDT Message-ID: <3B1F917F.97B279E7@iprg.nokia.com> Date: Thu, 07 Jun 2001 07:36:47 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Syed CC: Seamless Mobility Working Group Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.txt References: <9FBD322B7824D511B36900508BF93C9C1CD0BB@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hamid, here are a couple comments on draft-hamid-seamoby-ct-qos-context-00.txt. First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat misleading, 'Requirements for...' would be more appropriate. Otherwise, I am quite confused by what you mean. About the timing requirement: why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for packets to go unaccounted, then they go unaccounted at oldAR as well as newAR? Also, configuration context MUST be transferred before state context, so that newAR can make sense of the state context. Also, configuration context MUST be transferred to newAR before first packet arrival at the newAR, so that newAR can start metering, marking and such even though state context is missing. Now if you allow the metering to start before state context has arrived, then you assume the router has the ability to merge two states (the new state at newAR with the old (transferred) state), and thus 7.2.2 should be rephrased as something like: A state context transfer MUST be sent after the last packet arrival at the oldAR. Transport reliability section does not distinguish between state and config, and thus it is hard to know what you mean. Now, these are details. What I am confused about is this: you make the assumption that both oldAR and newAR are DS capable routers in the same domain. Which means that first the newAR has to tell this to the oldAR. So CT becomes oldAR ------> newAR: request for QoS CT classification <------- : QoS CT classification: DS/same domain: ok, so I'll use the QoS CT requirements -------> : config --------> : state which also means that a contest transfer context transfer (or meta-CT) has to be defined :) In the framework document (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt) is described a general framework to transfer QoS that does not requires a preliminary handshake between oldAR and newAR. Take care, Cedric. From owner-seamoby@diameter.org Thu Jun 7 14:04: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 OAA11704 for ; Thu, 7 Jun 2001 14:04:50 -0400 (EDT) Received: (qmail 28768 invoked by alias); 7 Jun 2001 17:52:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28762 invoked by uid 200); 7 Jun 2001 17:52:53 -0000 Received: (qmail 28757 invoked from network); 7 Jun 2001 17:52:51 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 17:52:51 -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 LAA17316; Thu, 7 Jun 2001 11:02:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57I2s931465; Thu, 7 Jun 2001 11:02:54 -0700 X-mProtect: Thu, 7 Jun 2001 11:02:54 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdhOCQz7; Thu, 07 Jun 2001 11:02:50 PDT Message-ID: <3B1FC1CA.7D371D4E@iprg.nokia.com> Date: Thu, 07 Jun 2001 11:02:50 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Syed CC: "'Charles E. Perkins'" , Gary Kenward , Seamless Mobility Working Group Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt References: <9FBD322B7824D511B36900508BF93C9C1CD0BB@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid, some comments below. Regards, -Rajeev Hamid Syed wrote: > > > Hello Charlie, > > I am glad that you read the draft. Please see my comments below. > > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com] > Sent: Wednesday, June 06, 2001 1:39 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility > Working Group > Subject: Re: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > Hello Hamid, > > We previously published a framework document for consideration > within [seamoby]. Our emphasis was on context feature > classification > and message flows. Your document (which I reckon is to be > considered > an individual submission) does not have much about feature > classfication, and at first glance seems to be a lot more > emphasis > on groupings of access routers. > [Syed, Hamid [WDLN2:AN22:EXCH]] I disagree. Infact the draft > attempts to cover a broader range of the over all problem. We do > not believe that just shipping the context from one access router > to another can provide a "seamless" > "Shipping" contexts (some folks call it transferring contexts BTW) is an integral part of the Context Transfer Protocol. Indeed, you need to know the target router, which is a separate protocol/mechanism. Once you do know the target router, I guess you would be interested in transferring contexts in CT. It seems intuitively obvious to do CT along with handovers. > handover. Identifying the potential context candidates and a > close interworking with the mobility mechanism are equally > important to be addressed in the context transfer framework. Our > draft is focused on distributing the functional roles to the ct > entities and defining interfaces between them. The context > transfer protocol is only one > In the CT problem statement draft, we have identified the entities: AR, AP, MN, MH > aspect of the over all problem domain and that is what your draft > is proposing, a solution for shipping context from one AR to the > other. I may consider your submission as a candidate solution for > context trasnfer protocol but this is not a framework. I believe > that frameworks should focus on functional models and interface > definitions and the details of individual protocols must be taken > ouitside the framework document. > By interface defintions do you mean protocol messages ? Or do you have 3G interfaces in mind ? > > > I would like to suggest that establishing communities or > neighborhoods > or groups of access routers could be handled by a protocol which > would > be separate than the protocol for doing the context transfer, and > > further that in many instances it wouldn't be necessary to make > the > access router groups at all. > [Syed, Hamid [WDLN2:AN22:EXCH]] This is what the framework has > captured, a separate protocol for context group management and > another protocol for context transfer. I would say, identifying a > suitable candidate for handover amongst the context group members > will help minimizing the service disruption during handover. > Defining a handover candidate discovery protocol is already part > of Seamoby WG charter and our framework shows how the functional > entities interact with each other through the standard > interfaces. > > > You are right that target router discovery is part of seamoby work. We all have our views on how this would work with CT. Once we have that work (target router selection) done, we will be able to better relate to it. Until then, I think it suffices to say that some seamoby entity provides us the target router address. > > I wondered whether you had taken a look at our previous framework > > draft, and if so whether you think meet the requirements. If you > > didn't see it yet, and if you'd like to take a look, here is the > URL: > > http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt > > Regards, > Charlie P. > [Syed, Hamid [WDLN2:AN22:EXCH]] Thanx for your comments. > > > Hamid Syed wrote: > > > > Hello CT Folks, > > > > I have submitted a framework draft for context transfer. I > would appreciate > > and welcome any comments on the draft. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > > > > cheers > > > > -Hamid > From owner-seamoby@diameter.org Thu Jun 7 15:13: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 PAA12829 for ; Thu, 7 Jun 2001 15:13:36 -0400 (EDT) Received: (qmail 29973 invoked by alias); 7 Jun 2001 18:48:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29967 invoked by uid 200); 7 Jun 2001 18:48:43 -0000 Received: (qmail 29961 invoked from network); 7 Jun 2001 18:48:41 -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; 7 Jun 2001 18:48:41 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57IwZE14858 for ; Thu, 7 Jun 2001 14:58:35 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 14:58:14 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 14:58:23 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CB1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , "Hamid Syed" Cc: "'Charles E. Perkins'" , Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt Date: Thu, 7 Jun 2001 14:58:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF83.DB62E6A0" 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_01C0EF83.DB62E6A0 Content-Type: text/plain; charset="ISO-8859-1" Rajeev > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, June 07, 2001 2:03 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: 'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless > Mobility Working Group > Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > > > In the CT problem statement draft, we have identified the > entities: AR, > AP, MN, MH > You need to read the second version of the draft, and the archives to read the explanation I gave for changing the nomenclature. To be fair (to myself), I was expecting many comments about this change. None were forthcomming, and a last call was issued for the problem statement. Gary ------_=_NextPart_001_01C0EF83.DB62E6A0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt

Rajeev

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Thursday, June 07, 2001 2:03 PM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: 'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless
> Mobility Working Group
> Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt
>
>
>

> In the CT problem statement draft, we have identified the
> entities: AR,
> AP, MN, MH
>

You need to read the second version of the draft, and the archives
to read the explanation I gave for changing the nomenclature.

To be fair (to myself), I was expecting many comments about this change.
None were forthcomming, and a last call was issued for the problem statement.

Gary

------_=_NextPart_001_01C0EF83.DB62E6A0-- From owner-seamoby@diameter.org Thu Jun 7 15:22: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 PAA12920 for ; Thu, 7 Jun 2001 15:22:00 -0400 (EDT) Received: (qmail 29996 invoked by alias); 7 Jun 2001 18:49:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29990 invoked by uid 200); 7 Jun 2001 18:49:02 -0000 Received: (qmail 29984 invoked from network); 7 Jun 2001 18:49:00 -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; 7 Jun 2001 18:49:00 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57IwsE14927 for ; Thu, 7 Jun 2001 14:58:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 14:58:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 14:58:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0C3@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Rajeev Koodli'" Cc: "'Charles E. Perkins'" , "Gary Kenward" , Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt Date: Thu, 7 Jun 2001 14:59:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF83.EB73C140" 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_01C0EF83.EB73C140 Content-Type: text/plain; charset="ISO-8859-1" Hello Rajeev, see my comments below. cheers -Hamid > -----Original Message----- > From: Rajeev Koodli [SMTP:rajeev@iprg.nokia.com] > Sent: Thursday, June 07, 2001 2:03 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: 'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless > Mobility Working Group > Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > > Hello Hamid, > > some comments below. > > Regards, > > -Rajeev > > > Hamid Syed wrote: > > > > > > > Hello Charlie, > > > > I am glad that you read the draft. Please see my comments below. > > > > -----Original Message----- > > From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com] > > Sent: Wednesday, June 06, 2001 1:39 PM > > To: Syed, Hamid [WDLN2:AN22:EXCH] > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility > > Working Group > > Subject: Re: [seamoby] I-D > > ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > > > Hello Hamid, > > > > We previously published a framework document for consideration > > within [seamoby]. Our emphasis was on context feature > > classification > > and message flows. Your document (which I reckon is to be > > considered > > an individual submission) does not have much about feature > > classfication, and at first glance seems to be a lot more > > emphasis > > on groupings of access routers. > > [Syed, Hamid [WDLN2:AN22:EXCH]] I disagree. Infact the draft > > attempts to cover a broader range of the over all problem. We do > > not believe that just shipping the context from one access router > > to another can provide a "seamless" > > > "Shipping" contexts (some folks call it transferring contexts BTW) is an > integral part of the Context Transfer Protocol. Indeed, you need to know > the target router, which is a separate protocol/mechanism. Once you do > know the target router, I guess you would be interested in transferring > contexts in CT. It seems intuitively obvious to do CT along with > handovers. [Syed, Hamid [WDLN2:AN22:EXCH]] I agree that handoff candidate discovery could be done through a separate protocol (and btw that is what our framework is suggesting) but I disagree isolating the two problems or making assumptions about their interworking. How the other protocol would work with any context transfer protocol?. which entity would determine or enable a suitable candidate discovery?. what are the related triggers or events?. All this is the part of context transfer problem domain and we cannot deny it. Any framework for context transfer must address all the issues. We cannot go making assupmtions about phenomenon that are closely realted to the context transfer. > > handover. Identifying the potential context candidates and a > > close interworking with the mobility mechanism are equally > > important to be addressed in the context transfer framework. Our > > draft is focused on distributing the functional roles to the ct > > entities and defining interfaces between them. The context > > transfer protocol is only one > > > > In the CT problem statement draft, we have identified the entities: AR, > AP, MN, MH [Syed, Hamid [WDLN2:AN22:EXCH]] Well..i do not disagree but AR is a an entity that contains more than one function in it (see the definition of AR). While our framework identifies the entities that are specific to context transfer and actively participates in the context transfer process. > > aspect of the over all problem domain and that is what your draft > > is proposing, a solution for shipping context from one AR to the > > other. I may consider your submission as a candidate solution for > > context trasnfer protocol but this is not a framework. I believe > > that frameworks should focus on functional models and interface > > definitions and the details of individual protocols must be taken > > ouitside the framework document. > > > > By interface defintions do you mean protocol messages ? Or do you have > 3G interfaces in mind ? [Syed, Hamid [WDLN2:AN22:EXCH]] IETF protocols. which are definitely interfaces between entities. > > > > > > I would like to suggest that establishing communities or > > neighborhoods > > or groups of access routers could be handled by a protocol which > > would > > be separate than the protocol for doing the context transfer, and > > > > further that in many instances it wouldn't be necessary to make > > the > > access router groups at all. > > [Syed, Hamid [WDLN2:AN22:EXCH]] This is what the framework has > > captured, a separate protocol for context group management and > > another protocol for context transfer. I would say, identifying a > > suitable candidate for handover amongst the context group members > > will help minimizing the service disruption during handover. > > Defining a handover candidate discovery protocol is already part > > of Seamoby WG charter and our framework shows how the functional > > entities interact with each other through the standard > > interfaces. > > > > > > > You are right that target router discovery is part of seamoby work. We > all have our views on how this would work with CT. Once we have that > work (target router selection) done, we will be able to better relate to > it. Until then, I think it suffices to say that some seamoby entity > provides us the target router address. [Syed, Hamid [WDLN2:AN22:EXCH]] Again..why try solving problems by making assumptions about the important details. Why not work on a framework that covers all the problem areas with no assumptions. Try a high level design first and then go for individual protocol definition. I do not understand the need for a shortcut approach. > > > > I wondered whether you had taken a look at our previous framework > > > > draft, and if so whether you think meet the requirements. If you > > > > didn't see it yet, and if you'd like to take a look, here is the > > URL: > > > > > http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt > > > > Regards, > > Charlie P. > > [Syed, Hamid [WDLN2:AN22:EXCH]] Thanx for your comments. > > > > > Hamid Syed wrote: > > > > > > Hello CT Folks, > > > > > > I have submitted a framework draft for context transfer. I > > would appreciate > > > and welcome any comments on the draft. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > > > > > > > cheers > > > > > > -Hamid > > > ------_=_NextPart_001_01C0EF83.EB73C140 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt

Hello Rajeev,

see my comments = below.

cheers

-Hamid

    -----Original Message-----
    From:   Rajeev Koodli = [SMTP:rajeev@iprg.nokia.com]
    Sent:   Thursday, June 07, 2001 2:03 PM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; = Seamless Mobility Working Group
    Subject:       = Re: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt


    Hello Hamid,

    some comments below.

    Regards,

    -Rajeev


    Hamid Syed wrote:

    >
    >
    > Hello Charlie,
    >
    > I am glad that you read the = draft. Please see my comments below.
    >
    >      = -----Original Message-----
    >      = From:   Charles E. Perkins = [SMTP:charliep@IPRG.nokia.com]
    >      = Sent:   Wednesday, June 06, 2001 1:39 PM
    >      = To:     Syed, Hamid [WDLN2:AN22:EXCH]
    >      = Cc:     Kenward, Gary [WDLN2:AN10:EXCH]; Seamless = Mobility
    >      = Working Group
    >      = Subject:        Re: [seamoby] = I-D
    >      = ACTION:draft-hamid-seamoby-ct-fwk-00.txt
    >
    >      = Hello Hamid,
    >
    >      We = previously published a framework document for consideration
    >      = within [seamoby].  Our emphasis was on context feature
    >      = classification
    >      = and message flows.  Your document (which I reckon is to be
    >      = considered
    >      an = individual submission) does not have much about feature
    >      = classfication, and at first glance seems to be a lot more
    >      = emphasis
    >      on = groupings of access routers.
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  I disagree. Infact the = draft
    >      = attempts to cover a broader range of the over all problem. We do
    >      = not believe that just shipping the context from one access = router
    >      to = another can provide a "seamless"
    >
    "Shipping" contexts (some = folks call it transferring contexts BTW) is an
    integral part of the Context Transfer = Protocol. Indeed, you need to know
    the target router, which is a = separate protocol/mechanism. Once you do
    know the target router, I guess you = would be interested in transferring
    contexts in CT. It seems intuitively = obvious to do CT along with
    handovers.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I agree that handoff candidate discovery could = be done through a separate protocol (and btw that is what our framework = is suggesting) but I disagree isolating the two problems or making = assumptions about their interworking. How the other protocol would work = with any context transfer protocol?. which entity would determine or = enable a suitable candidate discovery?. what are the related triggers = or events?. All this is the part of context transfer problem domain and = we cannot deny it. Any framework for context transfer must address all = the issues. We cannot go making assupmtions about phenomenon that are = closely realted to the context transfer.


    >      = handover. Identifying the potential context candidates and a
    >      = close interworking with the mobility mechanism are equally
    >      = important to be addressed in the context transfer framework. Our
    >      = draft is focused on distributing the functional roles to the ct
    >      = entities and defining interfaces between them. The context
    >      = transfer protocol is only one
    >

    In the CT problem statement draft, we = have identified the entities: AR,
    AP, MN, MH
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Well..i do not disagree but AR is a an entity = that contains more than one function in it (see the definition of AR). = While our framework identifies the entities that are specific to = context transfer and actively participates in the context transfer = process.


    >      = aspect of the over all problem domain and that is what your = draft
    >      is = proposing, a solution for shipping context from one AR to the
    >      = other. I may consider your submission as a candidate solution = for
    >      = context trasnfer protocol but this is not a framework. I believe
    >      = that frameworks should focus on functional models and interface
    >      = definitions and the details of individual protocols must be = taken
    >      = ouitside the framework document.
    >

    By interface defintions do you mean = protocol messages ? Or do you have
    3G interfaces in mind ?
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  IETF protocols. which are definitely = interfaces between entities.


    >
    >
    >      I = would like to suggest that establishing communities or
    >      = neighborhoods
    >      or = groups of access routers could be handled by a protocol which
    >      = would
    >      be = separate than the protocol for doing the context transfer, and
    >
    >      = further that in many instances it wouldn't be necessary to make
    >      = the
    >      = access router groups at all.
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]   This is what the framework = has
    >      = captured, a separate protocol for context group management and
    >      = another protocol for context transfer. I would say, identifying = a
    >      = suitable candidate for handover amongst the context group = members
    >      = will help minimizing the service disruption during handover.
    >      = Defining a handover candidate discovery protocol is already part
    >      of = Seamoby WG charter and our framework shows how the functional
    >      = entities interact with each other through the standard
    >      = interfaces.
    >
    >
    >
    You are right that target router = discovery is part of seamoby work. We
    all have our views on how this would = work with CT. Once we have that
    work (target router selection) done, = we will be able to better relate to
    it. Until then, I think it suffices = to say that some seamoby entity
    provides us the target router = address.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Again..why try solving problems by making = assumptions about the important details. Why not work on a framework = that covers all the problem areas with no assumptions. Try a high level = design first and then go for individual protocol definition. I do not = understand the need for a shortcut approach.


    >
    >      I = wondered whether you had taken a look at our previous framework
    >
    >      = draft, and if so whether you think meet the requirements.  If = you
    >
    >      = didn't see it yet, and if you'd like to take a look, here is the
    >      = URL:
    >
    >      = http://search.ietf.org/internet-drafts/draft-koodli-se= amoby-ctv6-00.txt
    >
    >      = Regards,
    >      = Charlie P.
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  Thanx for your comments.
    >
    >      = > Hamid Syed wrote:
    >      = >
    >      = > Hello CT Folks,
    >      = >
    >      = > I have submitted a framework draft for context transfer. I
    >      = would appreciate
    >      = > and welcome any comments on the draft.
    >      = >
    >      = > A URL for this Internet-Draft is:
    >      = >
    >      http://www.ietf.org/internet-drafts/draft-hamid-seamob= y-ct-fwk-00.txt
    >
    >      = >
    >      = > cheers
    >      = >
    >      = > -Hamid
    >

------_=_NextPart_001_01C0EF83.EB73C140-- From owner-seamoby@diameter.org Thu Jun 7 15:28: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 PAA12988 for ; Thu, 7 Jun 2001 15:28:14 -0400 (EDT) Received: (qmail 29605 invoked by alias); 7 Jun 2001 18:43:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29599 invoked by uid 200); 7 Jun 2001 18:43:08 -0000 Received: (qmail 29594 invoked from network); 7 Jun 2001 18:43:06 -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; 7 Jun 2001 18:43:06 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57Ir1E14026 for ; Thu, 7 Jun 2001 14:53:01 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 14:52:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 14:52:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CAF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Cedric Westphal'" , "Hamid Syed" Cc: Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t Date: Thu, 7 Jun 2001 14:53:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF83.1856F480" 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_01C0EF83.1856F480 Content-Type: text/plain; charset="ISO-8859-1" Cedric: There has been an open issue about AR capability, and there are five (at least) schools of thought: o One approach would rely upon a capability discovery phase to determine which ARs have compatible capabilities (this would imply some sort of information model as well as information distribution, maintenance and access mechanisms or protocols as well as a discovery protocol). o The second approach would rely on admission control that would based upon: authorization, policy decisions, resource availability, and AR capability. o The third approach would rely upon a negotiation phase during the ct; this would seem to slow down ct, but it may not be a problem for proactive ct, and the feature could be used for partial traffic handovers, and to downgrade service if resources were not available. This is an enhancement of the admission control approach. o The fourth approach relys on engineering the network so that the ARs are compatible (this probably won't work in an all-wireless network). o The fifth approach does not care: if the ct fails because the receiving AR could not use the context, so what? At least you tried ;^}. Sorry for delving into solution space. Clearly some of these approaches have impact on the ct requirements, and some do not. I haven't figured out how to address all possibilities with a set of generic requirements (other then to say that *some* mechanism must exist, which is fatuous). Thanks, Gary > -----Original Message----- > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > Sent: Thursday, June 07, 2001 10:37 AM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: Seamless Mobility Working Group > Subject: Re: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.txt > > > Hamid, > > here are a couple comments on > draft-hamid-seamoby-ct-qos-context-00.txt. > > First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat > misleading, > 'Requirements for...' would be more appropriate. > > Otherwise, I am quite confused by what you mean. About the timing > requirement: > why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for > packets to > go > unaccounted, then they go unaccounted at oldAR as well as newAR? > > Also, configuration context MUST be transferred before state > context, so > that newAR > can make sense of the state context. > Also, configuration context MUST be transferred to newAR before first > packet arrival at the newAR, so that newAR can start metering, marking > and such even though state context > is missing. > > Now if you allow the metering to start before state context > has arrived, > then you assume > the router has the ability to merge two states (the new state at newAR > with the old (transferred) > state), and thus 7.2.2 should be rephrased as something like: A state > context transfer > MUST be sent after the last packet arrival at the oldAR. > > Transport reliability section does not distinguish between state and > config, and thus it is > hard to know what you mean. > > Now, these are details. What I am confused about is this: you make the > assumption that > both oldAR and newAR are DS capable routers in the same domain. Which > means that > first the newAR has to tell this to the oldAR. So CT becomes > oldAR ------> newAR: request for QoS CT classification > <------- : QoS CT classification: DS/same domain: > ok, so I'll use the QoS CT > requirements > -------> : config > --------> : state > > which also means that a contest transfer context transfer (or meta-CT) > has to be defined :) > > In the framework document > (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c tv6-00.txt) is described a general framework to transfer QoS that does not requires a preliminary handshake between oldAR and newAR. Take care, Cedric. ------_=_NextPart_001_01C0EF83.1856F480 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.txt

Cedric:

  There has been an open issue about AR capability, and there
are five (at least) schools of thought:

   o One approach would rely upon a capability discovery phase to
     determine which ARs have compatible capabilities (this would
     imply some sort of information model as well as information
     distribution, maintenance and access mechanisms or protocols
     as well as a discovery protocol).

   o The second approach would rely on admission control that would
     based upon: authorization, policy decisions, resource availability,
     and AR capability.

   o The third approach would rely upon a negotiation phase during
     the ct; this would seem to slow down ct, but it may not be
     a problem for proactive ct, and the feature could be used
     for partial traffic handovers, and to downgrade service if
     resources were not available. This is an enhancement of the
     admission control approach.

   o The fourth approach relys on engineering the network so
     that the ARs are compatible (this probably won't work in an
     all-wireless network).
 
   o The fifth approach does not care: if the ct fails because the
     receiving AR could not use the context, so what? At least you
     tried ;^}.

Sorry for delving into solution space. Clearly some of these approaches
have impact on the ct requirements, and some do not. I haven't figured
out how to address all possibilities with a set of generic requirements
(other then to say that *some* mechanism must exist, which is fatuous).

Thanks,
Gary


> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Thursday, June 07, 2001 10:37 AM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: Seamless Mobility Working Group
> Subject: Re: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt
>
>
> Hamid,
>
> here are a couple comments on
> draft-hamid-seamoby-ct-qos-context-00.txt.
>
> First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat
> misleading,
> 'Requirements for...' would be more appropriate.
>
> Otherwise, I am quite confused by what you mean. About the timing
> requirement:
> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for
> packets to
> go
> unaccounted, then they go unaccounted at oldAR as well as newAR?
>
> Also, configuration context MUST be transferred before state
> context, so
> that newAR
> can make sense of the state context.
> Also, configuration context MUST be transferred to newAR before first
> packet arrival at the newAR, so that newAR can start metering, marking
> and such even though state context
> is missing.
>
> Now if you allow the metering to start before state context
> has arrived,
> then you assume
> the router has the ability to merge two states (the new state at newAR
> with the old (transferred)
> state), and thus 7.2.2 should be rephrased as something like: A state
> context transfer
> MUST be sent after the last packet arrival at the oldAR.
>
> Transport reliability section does not distinguish between state and
> config, and thus it is
> hard to know what you mean.
>
> Now, these are details. What I am confused about is this: you make the
> assumption that
> both oldAR and newAR are DS capable routers in the same domain. Which
> means that
> first the newAR has to tell this to the oldAR. So CT becomes
> oldAR ------> newAR: request for QoS CT classification
>           <-------            : QoS CT classification: DS/same domain:
> ok, so I'll use the QoS CT
> requirements
>           ------->            : config
>           -------->          : state
>
> which also means that a contest transfer context transfer (or meta-CT)
> has to be defined :)
>
> In the framework document
> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c
tv6-00.txt)
is described a
general framework to transfer QoS that does not requires a preliminary
handshake between
oldAR and newAR.

Take care,

Cedric.










------_=_NextPart_001_01C0EF83.1856F480-- From owner-seamoby@diameter.org Thu Jun 7 15:30:31 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13061 for ; Thu, 7 Jun 2001 15:30:29 -0400 (EDT) Received: (qmail 30050 invoked by alias); 7 Jun 2001 18:50:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30044 invoked by uid 200); 7 Jun 2001 18:50:45 -0000 Received: (qmail 30035 invoked from network); 7 Jun 2001 18:50:43 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 18:50:43 -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 NAA22347; Thu, 7 Jun 2001 13:01:12 -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 MAA28847; Thu, 7 Jun 2001 12:01:11 -0700 (PDT) Message-Id: <200106071901.MAA28847@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 12:01:11 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t To: cedric@IPRG.nokia.com, hmsyed@nortelnetworks.com, gkenward@nortelnetworks.com Cc: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: trRCt8tNZ7B2D3MoKLivTg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk I'm unclear about when the AR discovery protocol is intended to operate. Is this envisioned to occur during MN handover or is it envisioned to occur beforehand? Also, is it intended that the protocol operate MN to AR or AR to AR? Depending on this, the performance characteristic could be quite different. jak >Delivered-To: seamoby-list@charizard.diameter.org >From: "Gary Kenward" >To: "'Cedric Westphal'" , "Hamid Syed" >Cc: Seamless Mobility Working Group >Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t >Date: Thu, 7 Jun 2001 14:53:09 -0400 > >Cedric: > > There has been an open issue about AR capability, and there >are five (at least) schools of thought: > > o One approach would rely upon a capability discovery phase to > determine which ARs have compatible capabilities (this would > imply some sort of information model as well as information > distribution, maintenance and access mechanisms or protocols > as well as a discovery protocol). > > o The second approach would rely on admission control that would > based upon: authorization, policy decisions, resource availability, > and AR capability. > > o The third approach would rely upon a negotiation phase during > the ct; this would seem to slow down ct, but it may not be > a problem for proactive ct, and the feature could be used > for partial traffic handovers, and to downgrade service if > resources were not available. This is an enhancement of the > admission control approach. > > o The fourth approach relys on engineering the network so > that the ARs are compatible (this probably won't work in an > all-wireless network). > > o The fifth approach does not care: if the ct fails because the > receiving AR could not use the context, so what? At least you > tried ;^}. > >Sorry for delving into solution space. Clearly some of these approaches >have impact on the ct requirements, and some do not. I haven't figured >out how to address all possibilities with a set of generic requirements >(other then to say that *some* mechanism must exist, which is fatuous). > >Thanks, >Gary > > >> -----Original Message----- >> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] >> Sent: Thursday, June 07, 2001 10:37 AM >> To: Syed, Hamid [WDLN2:AN22:EXCH] >> Cc: Seamless Mobility Working Group >> Subject: Re: [seamoby] I-D >> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt >> >> >> Hamid, >> >> here are a couple comments on >> draft-hamid-seamoby-ct-qos-context-00.txt. >> >> First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat >> misleading, >> 'Requirements for...' would be more appropriate. >> >> Otherwise, I am quite confused by what you mean. About the timing >> requirement: >> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for >> packets to >> go >> unaccounted, then they go unaccounted at oldAR as well as newAR? >> >> Also, configuration context MUST be transferred before state >> context, so >> that newAR >> can make sense of the state context. >> Also, configuration context MUST be transferred to newAR before first >> packet arrival at the newAR, so that newAR can start metering, marking >> and such even though state context >> is missing. >> >> Now if you allow the metering to start before state context >> has arrived, >> then you assume >> the router has the ability to merge two states (the new state at newAR >> with the old (transferred) >> state), and thus 7.2.2 should be rephrased as something like: A state >> context transfer >> MUST be sent after the last packet arrival at the oldAR. >> >> Transport reliability section does not distinguish between state and >> config, and thus it is >> hard to know what you mean. >> >> Now, these are details. What I am confused about is this: you make the >> assumption that >> both oldAR and newAR are DS capable routers in the same domain. Which >> means that >> first the newAR has to tell this to the oldAR. So CT becomes >> oldAR ------> newAR: request for QoS CT classification >> <------- : QoS CT classification: DS/same domain: >> ok, so I'll use the QoS CT >> requirements >> -------> : config >> --------> : state >> >> which also means that a contest transfer context transfer (or meta-CT) >> has to be defined :) >> >> In the framework document >> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c >tv6-00.txt) >is described a >general framework to transfer QoS that does not requires a preliminary >handshake between >oldAR and newAR. > >Take care, > >Cedric. > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 7 15:48:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13292 for ; Thu, 7 Jun 2001 15:47:59 -0400 (EDT) Received: (qmail 30218 invoked by alias); 7 Jun 2001 18:55:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30210 invoked by uid 200); 7 Jun 2001 18:55:24 -0000 Received: (qmail 30202 invoked from network); 7 Jun 2001 18:55:21 -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; 7 Jun 2001 18:55:21 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57J5EE15927 for ; Thu, 7 Jun 2001 15:05:14 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 15:05:09 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:05:18 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0C4@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'James Kempf'" , cedric@IPRG.nokia.com, "Gary Kenward" Cc: seamoby@diameter.org Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t Date: Thu, 7 Jun 2001 15:05:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF84.D3B219C0" 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_01C0EF84.D3B219C0 Content-Type: text/plain; charset="ISO-8859-1" Hello James, Perhaps you might want to look at the scenarios at the end of the draft. It will answer your concerns. cheers -Hamid > -----Original Message----- > From: James Kempf [SMTP:James.Kempf@Sun.COM] > Sent: Thursday, June 07, 2001 3:01 PM > To: cedric@IPRG.nokia.com; Syed, Hamid [WDLN2:AN22:EXCH]; Kenward, Gary > [WDLN2:AN10:EXCH] > Cc: seamoby@diameter.org > Subject: RE: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t > > I'm unclear about when the AR discovery protocol is intended to operate. > Is this envisioned to occur during MN handover or is it envisioned > to occur beforehand? Also, is it intended that the protocol operate > MN to AR or AR to AR? > > Depending on this, the performance characteristic could be quite > different. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: "Gary Kenward" > >To: "'Cedric Westphal'" , "Hamid Syed" > > >Cc: Seamless Mobility Working Group > >Subject: RE: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t > >Date: Thu, 7 Jun 2001 14:53:09 -0400 > > > >Cedric: > > > > There has been an open issue about AR capability, and there > >are five (at least) schools of thought: > > > > o One approach would rely upon a capability discovery phase to > > determine which ARs have compatible capabilities (this would > > imply some sort of information model as well as information > > distribution, maintenance and access mechanisms or protocols > > as well as a discovery protocol). > > > > o The second approach would rely on admission control that would > > based upon: authorization, policy decisions, resource availability, > > and AR capability. > > > > o The third approach would rely upon a negotiation phase during > > the ct; this would seem to slow down ct, but it may not be > > a problem for proactive ct, and the feature could be used > > for partial traffic handovers, and to downgrade service if > > resources were not available. This is an enhancement of the > > admission control approach. > > > > o The fourth approach relys on engineering the network so > > that the ARs are compatible (this probably won't work in an > > all-wireless network). > > > > o The fifth approach does not care: if the ct fails because the > > receiving AR could not use the context, so what? At least you > > tried ;^}. > > > >Sorry for delving into solution space. Clearly some of these approaches > >have impact on the ct requirements, and some do not. I haven't figured > >out how to address all possibilities with a set of generic requirements > >(other then to say that *some* mechanism must exist, which is fatuous). > > > >Thanks, > >Gary > > > > > >> -----Original Message----- > >> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > >> Sent: Thursday, June 07, 2001 10:37 AM > >> To: Syed, Hamid [WDLN2:AN22:EXCH] > >> Cc: Seamless Mobility Working Group > >> Subject: Re: [seamoby] I-D > >> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt > >> > >> > >> Hamid, > >> > >> here are a couple comments on > >> draft-hamid-seamoby-ct-qos-context-00.txt. > >> > >> First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat > >> misleading, > >> 'Requirements for...' would be more appropriate. > >> > >> Otherwise, I am quite confused by what you mean. About the timing > >> requirement: > >> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for > >> packets to > >> go > >> unaccounted, then they go unaccounted at oldAR as well as newAR? > >> > >> Also, configuration context MUST be transferred before state > >> context, so > >> that newAR > >> can make sense of the state context. > >> Also, configuration context MUST be transferred to newAR before first > >> packet arrival at the newAR, so that newAR can start metering, marking > >> and such even though state context > >> is missing. > >> > >> Now if you allow the metering to start before state context > >> has arrived, > >> then you assume > >> the router has the ability to merge two states (the new state at newAR > >> with the old (transferred) > >> state), and thus 7.2.2 should be rephrased as something like: A state > >> context transfer > >> MUST be sent after the last packet arrival at the oldAR. > >> > >> Transport reliability section does not distinguish between state and > >> config, and thus it is > >> hard to know what you mean. > >> > >> Now, these are details. What I am confused about is this: you make the > >> assumption that > >> both oldAR and newAR are DS capable routers in the same domain. Which > >> means that > >> first the newAR has to tell this to the oldAR. So CT becomes > >> oldAR ------> newAR: request for QoS CT classification > >> <------- : QoS CT classification: DS/same domain: > >> ok, so I'll use the QoS CT > >> requirements > >> -------> : config > >> --------> : state > >> > >> which also means that a contest transfer context transfer (or meta-CT) > >> has to be defined :) > >> > >> In the framework document > >> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c > >tv6-00.txt) > >is described a > >general framework to transfer QoS that does not requires a preliminary > >handshake between > >oldAR and newAR. > > > >Take care, > > > >Cedric. > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0EF84.D3B219C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t

Hello James,

Perhaps you might = want to look at the scenarios at the end of the draft. It will answer = your concerns.

cheers

-Hamid

    -----Original Message-----
    From:   James Kempf [SMTP:James.Kempf@Sun.COM]
    Sent:   Thursday, June 07, 2001 3:01 PM
    To:     cedric@IPRG.nokia.com; Syed, Hamid [WDLN2:AN22:EXCH]; = Kenward, Gary [WDLN2:AN10:EXCH]
    Cc:     seamoby@diameter.org
    Subject:       = RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t

    I'm unclear about when the AR = discovery protocol is intended to operate.
    Is this envisioned to occur during MN = handover or is it envisioned
    to occur beforehand? Also, is it = intended that the protocol operate
    MN to AR or AR to AR?

    Depending on this, the performance = characteristic could be quite
    different.

            =         jak

    >Delivered-To: = seamoby-list@charizard.diameter.org
    >From: "Gary Kenward" = <gkenward@nortelnetworks.com>
    >To: "'Cedric Westphal'" = <cedric@IPRG.nokia.com>, "Hamid Syed"
    <hmsyed@nortelnetworks.com>
    >Cc: Seamless Mobility Working = Group <seamoby@diameter.org>
    >Subject: RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t
    >Date: Thu, 7 Jun 2001 14:53:09 = -0400
    >
    >Cedric:
    >
    >  There has been an open = issue about AR capability, and there
    >are five (at least) schools of = thought:
    >
    >   o One approach would = rely upon a capability discovery phase to
    >     = determine which ARs have compatible capabilities (this would
    >     imply = some sort of information model as well as information
    >     = distribution, maintenance and access mechanisms or protocols
    >     as well = as a discovery protocol).
    >
    >   o The second = approach would rely on admission control that would
    >     based = upon: authorization, policy decisions, resource availability,
    >     and AR = capability.
    >
    >   o The third approach = would rely upon a negotiation phase during
    >     the ct; = this would seem to slow down ct, but it may not be
    >     a = problem for proactive ct, and the feature could be used
    >     for = partial traffic handovers, and to downgrade service if
    >     = resources were not available. This is an enhancement of the
    >     = admission control approach.
    >
    >   o The fourth = approach relys on engineering the network so
    >     that the = ARs are compatible (this probably won't work in an
    >     = all-wireless network).
    >
    >   o The fifth approach = does not care: if the ct fails because the
    >     = receiving AR could not use the context, so what? At least you
    >     tried = ;^}.
    >
    >Sorry for delving into solution = space. Clearly some of these approaches
    >have impact on the ct = requirements, and some do not. I haven't figured
    >out how to address all = possibilities with a set of generic requirements
    >(other then to say that *some* = mechanism must exist, which is fatuous).
    >
    >Thanks,
    >Gary
    >
    >
    >> -----Original = Message-----
    >> From: Cedric Westphal = [mailto:cedric@IPRG.nokia.com]
    >> Sent: Thursday, June 07, = 2001 10:37 AM
    >> To: Syed, Hamid = [WDLN2:AN22:EXCH]
    >> Cc: Seamless Mobility = Working Group
    >> Subject: Re: [seamoby] = I-D
    >> = ACTION:draft-hamid-seamoby-ct-qos-context-00.txt
    >>
    >>
    >> Hamid,
    >>
    >> here are a couple comments = on
    >> = draft-hamid-seamoby-ct-qos-context-00.txt.
    >>
    >> First, I think the title = 'QoS (Diffserv) Context Transfer' is somewhat
    >> misleading,
    >> 'Requirements for...' would = be more appropriate.
    >>
    >> Otherwise, I am quite = confused by what you mean. About the timing
    >> requirement:
    >> why is 7.2.2 a MUST NOT and = 7.2.3 a SHOULD. If you allow for
    >> packets to
    >> go
    >> unaccounted, then they go = unaccounted at oldAR as well as newAR?
    >>
    >> Also, configuration context = MUST be transferred before state
    >> context, so
    >> that newAR
    >> can make sense of the state = context.
    >> Also, configuration context = MUST be transferred to newAR before first
    >> packet arrival at the newAR, = so that newAR can start metering, marking
    >> and such even though state = context
    >> is missing.
    >>
    >> Now if you allow the = metering to start before state context
    >> has arrived,
    >> then you assume
    >> the router has the ability = to merge two states (the new state at newAR
    >> with the old = (transferred)
    >> state), and thus 7.2.2 = should be rephrased as something like: A state
    >> context transfer
    >> MUST be sent after the last = packet arrival at the oldAR.
    >>
    >> Transport reliability = section does not distinguish between state and
    >> config, and thus it = is
    >> hard to know what you = mean.
    >>
    >> Now, these are details. What = I am confused about is this: you make the
    >> assumption that
    >> both oldAR and newAR are DS = capable routers in the same domain. Which
    >> means that
    >> first the newAR has to tell = this to the oldAR. So CT becomes
    >> oldAR ------> newAR: = request for QoS CT classification
    >>        &= nbsp;  = <-------          &= nbsp; : QoS CT classification: DS/same domain:
    >> ok, so I'll use the QoS = CT
    >> requirements
    >>        &= nbsp;  = ------->          &= nbsp; : config
    >>        &= nbsp;  = -------->          : = state
    >>
    >> which also means that a = contest transfer context transfer (or meta-CT)
    >> has to be defined :)
    >>
    >> In the framework = document
    >> (http://search.ietf.org/internet-drafts/draft-koodli-se= amoby-c
    >tv6-00.txt)
    >is described a
    >general framework to transfer QoS = that does not requires a preliminary
    >handshake between
    >oldAR and newAR.
    >
    >Take care,
    >
    >Cedric.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >

------_=_NextPart_001_01C0EF84.D3B219C0-- From owner-seamoby@diameter.org Thu Jun 7 15:57: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 PAA13445 for ; Thu, 7 Jun 2001 15:56:58 -0400 (EDT) Received: (qmail 30792 invoked by alias); 7 Jun 2001 19:05:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30786 invoked by uid 200); 7 Jun 2001 19:05:33 -0000 Received: (qmail 30780 invoked from network); 7 Jun 2001 19:05:30 -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; 7 Jun 2001 19:05:30 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57JFOE17351 for ; Thu, 7 Jun 2001 15:15:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 15:15:17 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:15:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0C5@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Cedric Westphal'" Cc: Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t Date: Thu, 7 Jun 2001 15:15:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF86.3F62F580" 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_01C0EF86.3F62F580 Content-Type: text/plain hello Cedric, Thanx for the comments. see my response below. cheers -Hamid > -----Original Message----- > From: Cedric Westphal [SMTP:cedric@IPRG.nokia.com] > Sent: Thursday, June 07, 2001 10:37 AM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: Seamless Mobility Working Group > Subject: Re: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.txt > > Hamid, > > here are a couple comments on draft-hamid-seamoby-ct-qos-context-00.txt. > > First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat > misleading, > 'Requirements for...' would be more appropriate. [Syed, Hamid [WDLN2:AN22:EXCH]] Dont disagree with you but the draft is not only capturing requirements but identifying the Qos context data as well. > Otherwise, I am quite confused by what you mean. About the timing > requirement: > why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for packets to > go > unaccounted, then they go unaccounted at oldAR as well as newAR? > > Also, configuration context MUST be transferred before state context, so > that newAR > can make sense of the state context. [Syed, Hamid [WDLN2:AN22:EXCH]] Correct. In proactive context transfer, this is how it should be done but for reactive, I would say the configuration context must be processed first but could be transferred at the same time. > Also, configuration context MUST be transferred to newAR before first > packet arrival at the newAR, so that newAR can start metering, marking > and such even though state context > is missing. > > Now if you allow the metering to start before state context has arrived, > then you assume > the router has the ability to merge two states (the new state at newAR > with the old (transferred) > state), and thus 7.2.2 should be rephrased as something like: A state > context transfer > MUST be sent after the last packet arrival at the oldAR. [Syed, Hamid [WDLN2:AN22:EXCH]] Again dont disagre with you here. It just another way of presenting the requirements and may be a better way. thanx. > Transport reliability section does not distinguish between state and > config, and thus it is > hard to know what you mean. > > Now, these are details. What I am confused about is this: you make the > assumption that > both oldAR and newAR are DS capable routers in the same domain. Which > means that > first the newAR has to tell this to the oldAR. So CT becomes > oldAR ------> newAR: request for QoS CT classification > <------- : QoS CT classification: DS/same domain: > ok, so I'll use the QoS CT > requirements > -------> : config > --------> : state > > which also means that a contest transfer context transfer (or meta-CT) > has to be defined :) [Syed, Hamid [WDLN2:AN22:EXCH]] I do not know how you did get this impression. The draft is intended to capture the QoS context data and the specific requirements. It does not say that the qos context needs a separate transfer protocol or negotiation mechansim. infact, the transfer protocol for all the contexts types is the same. I agree that all the feature contexts must be transferred in a generic way. > In the framework document > (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt) > is described a > general framework to transfer QoS that does not requires a preliminary > handshake between > oldAR and newAR. > > Take care, > > Cedric. > > > > > > > > > > ------_=_NextPart_001_01C0EF86.3F62F580 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-qos-context-00.txt

hello Cedric,

Thanx for the = comments. see my response below.

cheers

-Hamid

    -----Original Message-----
    From:   Cedric Westphal = [SMTP:cedric@IPRG.nokia.com]
    Sent:   Thursday, June 07, 2001 10:37 AM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     Seamless Mobility Working Group
    Subject:       = Re: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-qos-context-00.txt

    Hamid,

    here are a couple comments on = draft-hamid-seamoby-ct-qos-context-00.txt.

    First, I think the title 'QoS = (Diffserv) Context Transfer' is somewhat
    misleading,
    'Requirements for...' would be more = appropriate.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Dont disagree with you but the draft is not = only capturing requirements but identifying the Qos context data as = well.

    Otherwise, I am quite confused by what = you mean. About the timing
    requirement:
    why is 7.2.2 a MUST NOT and 7.2.3 a = SHOULD. If you allow for packets to
    go
    unaccounted, then they go unaccounted = at oldAR as well as newAR?

    Also, configuration context MUST be = transferred before state context, so
    that newAR
    can make sense of the state = context.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Correct. In proactive context transfer, this = is how it should be done but for reactive, I would say the = configuration context must be processed first but could be transferred = at the same time.

    Also, configuration context MUST be = transferred to newAR before first
    packet arrival at the newAR, so that = newAR can start metering, marking
    and such even though state = context
    is missing.

    Now if you allow the metering to start = before state context has arrived,
    then you assume
    the router has the ability to merge = two states (the new state at newAR
    with the old (transferred)
    state), and thus 7.2.2 should be = rephrased as something like: A state
    context transfer
    MUST be sent after the last packet = arrival at the oldAR.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Again dont disagre with you here. It just = another way of presenting the requirements and may be a better way. = thanx.

    Transport reliability section does not = distinguish between state and
    config, and thus it is
    hard to know what you mean.

    Now, these are details. What I am = confused about is this: you make the
    assumption that
    both oldAR and newAR are DS capable = routers in the same domain. Which
    means that
    first the newAR has to tell this to = the oldAR. So CT becomes
    oldAR ------> newAR: request for = QoS CT classification
              = <-------          &= nbsp; : QoS CT classification: DS/same domain:
    ok, so I'll use the QoS CT
    requirements
              = ------->          &= nbsp; : config
              = -------->          : = state

    which also means that a contest = transfer context transfer (or meta-CT)
    has to be defined :)
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I do not know how you did get this impression. = The draft is intended to capture the QoS context data and the specific = requirements. It does not say that the qos context needs a separate = transfer protocol or negotiation mechansim. infact, the transfer = protocol for all the contexts types is the same. I agree that all the = feature contexts must be transferred in a generic way.

    In the framework document
    (http://search.ietf.org/internet-drafts/draft-koodli-se= amoby-ctv6-00.txt)
    is described a
    general framework to transfer QoS = that does not requires a preliminary
    handshake between
    oldAR and newAR.

    Take care,

    Cedric.










------_=_NextPart_001_01C0EF86.3F62F580-- From owner-seamoby@diameter.org Thu Jun 7 16:07: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 QAA13587 for ; Thu, 7 Jun 2001 16:07:20 -0400 (EDT) Received: (qmail 882 invoked by alias); 7 Jun 2001 19:53:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 876 invoked by uid 200); 7 Jun 2001 19:53:26 -0000 Received: (qmail 870 invoked from network); 7 Jun 2001 19:53:24 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 19:53:24 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA22008 for ; Thu, 7 Jun 2001 13:03:57 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA23423 for ; Thu, 7 Jun 2001 12:57:23 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:03:52 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C7A@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mankin@isi.edu'" , Gary Kenward Cc: "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: RE: Comments Re: [seamoby] ct problem statement Date: Thu, 7 Jun 2001 15:03:45 -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 Allison, Thanks for the comments and sorry for the delay. I like to give my personal response (not on behalf of the group and it seems other people provided their opinions already. As far as WG and group feedback, well, I must say that the draft went through a serious downsizing, thanks to editors good work. However, unfortunately I am not sure if the second version enjoyed as much attention as the first, since there were several hot debates regarding requirements at the time, I can see now that the security parts are somehow severely downsized, I will comment on the security issues in a separate email. I am glad that, the reduced draft seems to have served the very purpose of acclimatizing its audience to CT as a solution (even if it might be an optimization only), since we are having this healthy overview conversation here. Also I am glad that this discussion came up now after all the requirement discussions that we had in the past months, which had made most of us understand the CT problem through its requirements, so revising problem statement after the requirement discussions seems like a healthy thing. However, at the same time in the interest of consistency the following has been removed from the draft, 1-list of various feature contexts where removed, 2-different approaches to CT 3-security considerations 4-Some requirements (especially on security) in the appendix Regarding 1 specifically, during the requirements phase, several issues on timing and reliability came up such as -If you were able to send context partially and handle individual features' requirements on timing and reliability, then CT could be seen as an optimization by helping the timing. -If the chief concern is security, then CT might help provisioning security, although it might introduce latency compared to an insecure system, but that way achieve another type of optimization. Regarding 2, there were a few issues such as -proactive and reactive CT and their timing requirements: If you were able to send context to a bunch of handover candidates proactively (without even knowing exactly which one you hand over to), you might reduce service disruption period by removing context transfer out of critical path. My personal opinion is: that issue is related to AR discovery/ CNP and MM teams work. -the issue of being able to fall back on base line in case CT fails was brought up and I am not sure if it made it in the draft. Comparing CT with a no-CT baseline (I am not sure if that is Mobile IP or not) is important, but it again involves considering various features and their requirements as well as recognition of MIP or something else as a baseline. In summary, I think most of us agree (Although I am not sure it is reflected anywhere) that CT must be seen as an optimization procedure, if it can meet various features timing and reliability requirements. And exact recommendation for designers and implementers as far as when to use CT and when not might be a bit too early until we have clear understanding of feature requirements and their relations to various handover solutions (such as MIP fast handovers) out there. I will comment on the security issues in another email. Regards, Madjid -----Original Message----- From: Allison Mankin [mailto:mankin@isi.edu] Sent: Friday, June 01, 2001 8:21 PM To: Gary Kenward Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu Subject: Comments Re: [seamoby] ct problem statement Hi, Gary, > Pat: > > I'm afraid to ask, but I must. What's up with the ct problem statement? > > Gary Since Pat said he'd consult the ADs to answer this: I note that the WG last call on the CT problem statement ended two days ago. Were there issues brought up to any of the authors or in the design team mailing list? The working group list did not surface any, that I saw, so I'll surface some that should be addressed before we put the draft forward for advancement: would show that some contents it is now harder to see the at the same time it had to hide some of the issues 1. The draft is very concise and easy to read - you want to spoil us in the IESG by continuing this good trend by Seamoby (in the footsteps of the paging problem statement)? [Needless to say, this is _not_ an issue :> ] 2. I would like to see some discussion of the problem space of how to evaluate when Internet CT makes sense and when it might not. For instance, the point that if a feature context has information that took many exchanges and/or computation to set up, it is a better candidate. Frequency of change of features would affect when CT is a good choice. The goal is not to make any evaluations, but to give a problem space for the protocol design work to come. How can the problem be described so that designers and eventual deployers can distinguish between optimizations that provide benefits only in narrowly constrained network circumstances and designs that provide broad enough benefits to be used at Internet level. 3. Security considerations - the point about the sensitivity of information carried in the CT is good, but the point about CT not raising new security concerns is too much of a leap. Even with the good design point of having the MN work but just have a slower handoff when CT fails, there are risks to net and nodes. Examples thought of quickly: Malicious context transferrors that give incorrect but information that is not malformed, and damage/alter the MN's connectivity Malicious CT requests causing DoS to the Forwarding Nodes that have to process them. These are from quick thought. A safer comment would be that CT probably will have novel security and requirements and design will have to address. Check out draft-rescorla-cons-03.txt for more ideas for the requirements phase. Thanks, Allison From owner-seamoby@diameter.org Thu Jun 7 16:10: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 QAA13681 for ; Thu, 7 Jun 2001 16:10:28 -0400 (EDT) Received: (qmail 30177 invoked by alias); 7 Jun 2001 18:55:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30171 invoked by uid 200); 7 Jun 2001 18:55:02 -0000 Received: (qmail 30165 invoked from network); 7 Jun 2001 18:54:59 -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; 7 Jun 2001 18:54:59 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57J4rE15817 for ; Thu, 7 Jun 2001 15:04:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 15:04:37 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:04:46 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CB3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , cedric@IPRG.nokia.com, "Hamid Syed" Cc: seamoby@diameter.org Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t Date: Thu, 7 Jun 2001 15:04:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF84.BED7F740" 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_01C0EF84.BED7F740 Content-Type: text/plain; charset="ISO-8859-1" Yes. You are absolutely correct James. Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Thursday, June 07, 2001 3:01 PM > To: cedric@IPRG.nokia.com; Syed, Hamid [WDLN2:AN22:EXCH]; > Kenward, Gary > [WDLN2:AN10:EXCH] > Cc: seamoby@diameter.org > Subject: RE: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t > > > I'm unclear about when the AR discovery protocol is intended > to operate. > Is this envisioned to occur during MN handover or is it envisioned > to occur beforehand? Also, is it intended that the protocol operate > MN to AR or AR to AR? > > Depending on this, the performance characteristic could be quite > different. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: "Gary Kenward" > >To: "'Cedric Westphal'" , "Hamid Syed" > > >Cc: Seamless Mobility Working Group > >Subject: RE: [seamoby] I-D > ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t > >Date: Thu, 7 Jun 2001 14:53:09 -0400 > > > >Cedric: > > > > There has been an open issue about AR capability, and there > >are five (at least) schools of thought: > > > > o One approach would rely upon a capability discovery phase to > > determine which ARs have compatible capabilities (this would > > imply some sort of information model as well as information > > distribution, maintenance and access mechanisms or protocols > > as well as a discovery protocol). > > > > o The second approach would rely on admission control that would > > based upon: authorization, policy decisions, resource > availability, > > and AR capability. > > > > o The third approach would rely upon a negotiation phase during > > the ct; this would seem to slow down ct, but it may not be > > a problem for proactive ct, and the feature could be used > > for partial traffic handovers, and to downgrade service if > > resources were not available. This is an enhancement of the > > admission control approach. > > > > o The fourth approach relys on engineering the network so > > that the ARs are compatible (this probably won't work in an > > all-wireless network). > > > > o The fifth approach does not care: if the ct fails because the > > receiving AR could not use the context, so what? At least you > > tried ;^}. > > > >Sorry for delving into solution space. Clearly some of these > approaches > >have impact on the ct requirements, and some do not. I > haven't figured > >out how to address all possibilities with a set of generic > requirements > >(other then to say that *some* mechanism must exist, which > is fatuous). > > > >Thanks, > >Gary > > > > > >> -----Original Message----- > >> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > >> Sent: Thursday, June 07, 2001 10:37 AM > >> To: Syed, Hamid [WDLN2:AN22:EXCH] > >> Cc: Seamless Mobility Working Group > >> Subject: Re: [seamoby] I-D > >> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt > >> > >> > >> Hamid, > >> > >> here are a couple comments on > >> draft-hamid-seamoby-ct-qos-context-00.txt. > >> > >> First, I think the title 'QoS (Diffserv) Context Transfer' > is somewhat > >> misleading, > >> 'Requirements for...' would be more appropriate. > >> > >> Otherwise, I am quite confused by what you mean. About the timing > >> requirement: > >> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for > >> packets to > >> go > >> unaccounted, then they go unaccounted at oldAR as well as newAR? > >> > >> Also, configuration context MUST be transferred before state > >> context, so > >> that newAR > >> can make sense of the state context. > >> Also, configuration context MUST be transferred to newAR > before first > >> packet arrival at the newAR, so that newAR can start > metering, marking > >> and such even though state context > >> is missing. > >> > >> Now if you allow the metering to start before state context > >> has arrived, > >> then you assume > >> the router has the ability to merge two states (the new > state at newAR > >> with the old (transferred) > >> state), and thus 7.2.2 should be rephrased as something > like: A state > >> context transfer > >> MUST be sent after the last packet arrival at the oldAR. > >> > >> Transport reliability section does not distinguish between > state and > >> config, and thus it is > >> hard to know what you mean. > >> > >> Now, these are details. What I am confused about is this: > you make the > >> assumption that > >> both oldAR and newAR are DS capable routers in the same > domain. Which > >> means that > >> first the newAR has to tell this to the oldAR. So CT becomes > >> oldAR ------> newAR: request for QoS CT classification > >> <------- : QoS CT classification: > DS/same domain: > >> ok, so I'll use the QoS CT > >> requirements > >> -------> : config > >> --------> : state > >> > >> which also means that a contest transfer context transfer > (or meta-CT) > >> has to be defined :) > >> > >> In the framework document > >> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c > >tv6-00.txt) > >is described a > >general framework to transfer QoS that does not requires a > preliminary > >handshake between > >oldAR and newAR. > > > >Take care, > > > >Cedric. > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0EF84.BED7F740 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t

Yes. You are absolutely correct James.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Thursday, June 07, 2001 3:01 PM
> To: cedric@IPRG.nokia.com; Syed, Hamid [WDLN2:AN22:EXCH];
> Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: seamoby@diameter.org
> Subject: RE: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t
>
>
> I'm unclear about when the AR discovery protocol is intended
> to operate.
> Is this envisioned to occur during MN handover or is it envisioned
> to occur beforehand? Also, is it intended that the protocol operate
> MN to AR or AR to AR?
>
> Depending on this, the performance characteristic could be quite
> different.
>
>               jak
>
> >Delivered-To: seamoby-list@charizard.diameter.org
> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> >To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>, "Hamid Syed"
> <hmsyed@nortelnetworks.com>
> >Cc: Seamless Mobility Working Group <seamoby@diameter.org>
> >Subject: RE: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t
> >Date: Thu, 7 Jun 2001 14:53:09 -0400
> >
> >Cedric:
> >
> >  There has been an open issue about AR capability, and there
> >are five (at least) schools of thought:
> >
> >   o One approach would rely upon a capability discovery phase to
> >     determine which ARs have compatible capabilities (this would
> >     imply some sort of information model as well as information
> >     distribution, maintenance and access mechanisms or protocols
> >     as well as a discovery protocol).
> >
> >   o The second approach would rely on admission control that would
> >     based upon: authorization, policy decisions, resource
> availability,
> >     and AR capability.
> >
> >   o The third approach would rely upon a negotiation phase during
> >     the ct; this would seem to slow down ct, but it may not be
> >     a problem for proactive ct, and the feature could be used
> >     for partial traffic handovers, and to downgrade service if
> >     resources were not available. This is an enhancement of the
> >     admission control approach.
> >
> >   o The fourth approach relys on engineering the network so
> >     that the ARs are compatible (this probably won't work in an
> >     all-wireless network).
> >
> >   o The fifth approach does not care: if the ct fails because the
> >     receiving AR could not use the context, so what? At least you
> >     tried ;^}.
> >
> >Sorry for delving into solution space. Clearly some of these
> approaches
> >have impact on the ct requirements, and some do not. I
> haven't figured
> >out how to address all possibilities with a set of generic
> requirements
> >(other then to say that *some* mechanism must exist, which
> is fatuous).
> >
> >Thanks,
> >Gary
> >
> >
> >> -----Original Message-----
> >> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> >> Sent: Thursday, June 07, 2001 10:37 AM
> >> To: Syed, Hamid [WDLN2:AN22:EXCH]
> >> Cc: Seamless Mobility Working Group
> >> Subject: Re: [seamoby] I-D
> >> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt
> >>
> >>
> >> Hamid,
> >>
> >> here are a couple comments on
> >> draft-hamid-seamoby-ct-qos-context-00.txt.
> >>
> >> First, I think the title 'QoS (Diffserv) Context Transfer'
> is somewhat
> >> misleading,
> >> 'Requirements for...' would be more appropriate.
> >>
> >> Otherwise, I am quite confused by what you mean. About the timing
> >> requirement:
> >> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for
> >> packets to
> >> go
> >> unaccounted, then they go unaccounted at oldAR as well as newAR?
> >>
> >> Also, configuration context MUST be transferred before state
> >> context, so
> >> that newAR
> >> can make sense of the state context.
> >> Also, configuration context MUST be transferred to newAR
> before first
> >> packet arrival at the newAR, so that newAR can start
> metering, marking
> >> and such even though state context
> >> is missing.
> >>
> >> Now if you allow the metering to start before state context
> >> has arrived,
> >> then you assume
> >> the router has the ability to merge two states (the new
> state at newAR
> >> with the old (transferred)
> >> state), and thus 7.2.2 should be rephrased as something
> like: A state
> >> context transfer
> >> MUST be sent after the last packet arrival at the oldAR.
> >>
> >> Transport reliability section does not distinguish between
> state and
> >> config, and thus it is
> >> hard to know what you mean.
> >>
> >> Now, these are details. What I am confused about is this:
> you make the
> >> assumption that
> >> both oldAR and newAR are DS capable routers in the same
> domain. Which
> >> means that
> >> first the newAR has to tell this to the oldAR. So CT becomes
> >> oldAR ------> newAR: request for QoS CT classification
> >>           <-------            : QoS CT classification:
> DS/same domain:
> >> ok, so I'll use the QoS CT
> >> requirements
> >>           ------->            : config
> >>           -------->          : state
> >>
> >> which also means that a contest transfer context transfer
> (or meta-CT)
> >> has to be defined :)
> >>
> >> In the framework document
> >> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c
> >tv6-00.txt)
> >is described a
> >general framework to transfer QoS that does not requires a
> preliminary
> >handshake between
> >oldAR and newAR.
> >
> >Take care,
> >
> >Cedric.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

------_=_NextPart_001_01C0EF84.BED7F740-- From owner-seamoby@diameter.org Thu Jun 7 16:30: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 QAA13996 for ; Thu, 7 Jun 2001 16:30:42 -0400 (EDT) Received: (qmail 1502 invoked by alias); 7 Jun 2001 20:18:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1496 invoked by uid 200); 7 Jun 2001 20:18:19 -0000 Received: (qmail 1491 invoked from network); 7 Jun 2001 20:18:17 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 20:18:17 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA21528 for ; Thu, 7 Jun 2001 13:28:51 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA21473 for ; Thu, 7 Jun 2001 13:28:50 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:28:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C7B@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mankin@isi.edu'" , Gary Kenward Cc: "'seamoby'" , "'Pat Calhoun'" , sob@harvard.edu Subject: [seamoby] security for CT was [RE: Comments ct problem statement] Date: Thu, 7 Jun 2001 15:28:49 -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 Allison, I am Sending comments on the security concerns: We did have a section on security considerations originally, until we were advised to remove it, since CT was not considered an existing protocol. I don't want to argue that decision; I am just wondering what the procedure is. Anyway, the security considerations sounds mostly like security requirements, do we want to have security requirements in a problem statement? The reason I am saying this is that, in the security requirements, we did include a requirement for mutual authentication of CT-peer ARs so that each side authenticate the other side in order to prevent DoS attacks by illegitimate ARs. For reference I send portions of the security text that I originally sent for problem statement and I guess for the sake of conciseness did not make it in the draft (note the MUSTs and Shoulds might be subject to debate now). The first section is about security considerations of CT and the second about security being another reason why CT is beneficial Security considerations Security services can be categorized into two groups, those provided To fulfill the security requirements of the MH (mobile host), and those provided to fulfill the security requirements of the network. Examples of security services provided to an MH are: user data encryption, user data integrity protection, and MH location privacy protection. While, examples of network security requirements are: protection of network topology and policy information. The mechanisms for establishing trust between the two parties involved in context transfer in order to transfer context data securely (as described below) should be provided. Prior to the process of context transfer, a mutual authentication Between the CT peers should happen (this could utilize the AAA Hierarchy, in case AAA admin domains are present). During this Authentication, the party receiving the context and the party transmitting the context, each provides proof of legitimacy to the other side. Data integrity protection should provided, so that the context information is protected from tampering by a third party. Encryption of context data might be necessary, in case MH location privacy and network topology and policy protection are required. In case security and AAA context are being transferred, the context Data must be encrypted. The mobile node must ultimately retain control over whether it moves or not, and under what conditions it consents to have a network based move done on its behalf. In particular, the mobile node must have the ability to veto a move that could happen transparently, but may result in higher access charges, unexpected service degradation, loss of privacy, or other policy based exclusions. 2- Other security reasons for a context transfer protocol Context transfer, besides facilitating for mobility, can increase The protecting the integrity of networks. With existence of a standard approach such as context transfer, prior to which the peer networks establish a secure channel by mutual authentication, and other security measures (see requirements) if we choose to secure selected portions of context, we would be able to do so in a logically (maybe not physically) central manner, i.e. at the same instance as context transfer and without requiring multiple security requirements for various feature contexts. As an example, policy context, QoS context, mobile's service profiles and other data can all be secured at one stop point and transferred through one already secure channel (between CT peers), without compromising secret policy, network topology, user information, location, etc. to unwanted men-in the middle attempting denial of service attacks or simply tampering with the integrity of data that is being signaled. Regards, Madjid -----Original Message----- From: Allison Mankin [mailto:mankin@isi.edu] Sent: Friday, June 01, 2001 8:21 PM To: Gary Kenward Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu Subject: Comments Re: [seamoby] ct problem statement Hi, Gary, > Pat: > > I'm afraid to ask, but I must. What's up with the ct problem statement? > > Gary Since Pat said he'd consult the ADs to answer this: I note that the WG last call on the CT problem statement ended two days ago. Were there issues brought up to any of the authors or in the design team mailing list? The working group list did not surface any, that I saw, so I'll surface some that should be addressed before we put the draft forward for advancement: 1. The draft is very concise and easy to read - you want to spoil us in the IESG by continuing this good trend by Seamoby (in the footsteps of the paging problem statement)? [Needless to say, this is _not_ an issue :> ] 2. I would like to see some discussion of the problem space of how to evaluate when Internet CT makes sense and when it might not. For instance, the point that if a feature context has information that took many exchanges and/or computation to set up, it is a better candidate. Frequency of change of features would affect when CT is a good choice. The goal is not to make any evaluations, but to give a problem space for the protocol design work to come. How can the problem be described so that designers and eventual deployers can distinguish between optimizations that provide benefits only in narrowly constrained network circumstances and designs that provide broad enough benefits to be used at Internet level. 3. Security considerations - the point about the sensitivity of information carried in the CT is good, but the point about CT not raising new security concerns is too much of a leap. Even with the good design point of having the MN work but just have a slower handoff when CT fails, there are risks to net and nodes. Examples thought of quickly: Malicious context transferrors that give incorrect but information that is not malformed, and damage/alter the MN's connectivity Malicious CT requests causing DoS to the Forwarding Nodes that have to process them. These are from quick thought. A safer comment would be that CT probably will have novel security and requirements and design will have to address. Check out draft-rescorla-cons-03.txt for more ideas for the requirements phase. Thanks, Allison From owner-seamoby@diameter.org Thu Jun 7 16: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 QAA14263 for ; Thu, 7 Jun 2001 16:45:05 -0400 (EDT) Received: (qmail 2575 invoked by alias); 7 Jun 2001 20:33:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2569 invoked by uid 200); 7 Jun 2001 20:33:00 -0000 Received: (qmail 2564 invoked from network); 7 Jun 2001 20:32:58 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 20:32:58 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA06688 for ; Thu, 7 Jun 2001 13:37:01 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA02982 for ; Thu, 7 Jun 2001 13:43:31 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:43:31 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C7D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Gary Kenward Cc: "'mankin@isi.edu'" , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Thu, 7 Jun 2001 15:43:29 -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 Hi Charlie, Correct me if I am wrong, I have not been very successful in finding specs that discriminate between authentication and authorization. So far I have only seen it in AAA Arch. Otherwise people use authentication credentials and authorization credentials interchangably. So we created a requirement that the CT peers should mutual authenticate each other prior to CT. Do you think a separate requirement for authorization is needed? Thank, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Monday, June 04, 2001 11:00 AM To: Gary Kenward Cc: 'mankin@isi.edu'; 'seamoby' Subject: Re: Comments Re: [seamoby] ct problem statement Hello Gary, > The second point troubles me somewhat: ct is essentially an information > transfer operation. I do not understand (and I can only state this as my being > confusion) why it is not enough to say that this information transfer > must be secure. Why would a ct be any different from any other data transfer > that needs to be secured? Some features (e.g., QoS or security associations) that might be handled as part of the context transfer mechanism should be transferred only upon assurance that the requester has at least some implicit authorization to make the request. Regards, Charlie P. > I personally don't see any new vulnerabilities; based upon my superficial > understanding of security, I read the examples you have provided as specific > instances of general security problems which I understood to have been > addressed. In other words, how are these scenarios not already addressed by > the existing security solutions? > > I am not against providing security for ct - not at all. However, I do want > to ensure that security remains an option to the operator (and is not build > into the protocol), the overhead imparted the ct can be minimized, and the > performance goals attained. > > > I am sure the wg will have input on the security issue, and the security > section will be enhanced, I am uncomfortable with that idea that ct has novel > requirements. > > Thank you for the response, > Gary > > > -----Original Message----- > > From: Allison Mankin [mailto:mankin@isi.edu] > > Sent: Friday, June 01, 2001 9:21 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: 'seamoby'; 'Pat Calhoun'; sob@harvard.edu > > Subject: Comments Re: [seamoby] ct problem statement > > > > > > Hi, Gary, > > > > > Pat: > > > > > > I'm afraid to ask, but I must. What's up with the ct > > problem statement? > > > > > > Gary > > > > Since Pat said he'd consult the ADs to answer this: > > > > I note that the WG last call on the CT problem statement ended two > > days ago. Were there issues brought up to any of the authors or > > in the design team mailing list? The working group list did > > not surface > > any, that I saw, so I'll surface some that should be addressed before > > we put the draft forward for advancement: > > > > > > 1. The draft is very concise and easy to read - you want to spoil > > us in the IESG by continuing this good trend by Seamoby (in the > > footsteps of the paging problem statement)? [Needless > > to say, this is _not_ an issue :> ] > > > > 2. I would like to see some discussion of the problem space of > > how to evaluate when Internet CT makes sense and when it might > > not. For instance, the point that if a feature context has > > information that took many exchanges and/or computation to set > > up, it is a better candidate. Frequency of change of features > > would affect when CT is a good choice. The goal is not > > to make any evaluations, but to give a problem space for the > > protocol design work to come. > > > > How can the problem be described so that designers and eventual > > deployers can distinguish between optimizations that > > provide benefits > > only in narrowly constrained network circumstances and designs > > that provide broad enough benefits to be used at Internet level. > > > > 3. Security considerations - the point about the sensitivity of > > information carried in the CT is good, but the point about > > CT not raising new security concerns is too much of a leap. > > Even with the good design point of having the MN work but just > > have a slower handoff when CT fails, there are risks to net and > > nodes. Examples thought of quickly: > > > > Malicious context transferrors that give incorrect but > > information that is not malformed, and damage/alter the MN's > > connectivity > > > > Malicious CT requests causing DoS to the Forwarding Nodes that > > have to process them. > > > > These are from quick thought. A safer comment would be that CT > > probably will have novel security and requirements and design will > > have to address. Check out draft-rescorla-cons-03.txt for more > > ideas for the requirements phase. > > > > Thanks, > > > > Allison > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 7 16:52: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 QAA14399 for ; Thu, 7 Jun 2001 16:52:37 -0400 (EDT) Received: (qmail 3197 invoked by alias); 7 Jun 2001 20:41:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3191 invoked by uid 200); 7 Jun 2001 20:41:06 -0000 Received: (qmail 3182 invoked by uid 500); 7 Jun 2001 20:41:04 -0000 Date: Thu, 7 Jun 2001 13:41:04 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Charles E. Perkins'" , Gary Kenward , "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement Message-ID: <20010607134104.P12278@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" , Gary Kenward , "'mankin@isi.edu'" , 'seamoby' References: <35DBB8B7AC89D4118E98009027B1009B1B7C7D@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: <35DBB8B7AC89D4118E98009027B1009B1B7C7D@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Thu, Jun 07, 2001 at 03:43:29PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Hi Charlie, > > Correct me if I am wrong, > I have not been very successful in finding specs that > discriminate between authentication and authorization. > So far I have only seen it in AAA Arch. > Otherwise people use authentication credentials > and authorization credentials interchangably. > > So we created a requirement that the CT peers should > mutual authenticate each other prior to CT. Do you think > a separate requirement for authorization is needed? Authentication The act of verifying the identity of an entity (subject). Authorization The act of determining whether a requesting entity (subject) will be allowed access to a resource (object). PatC From owner-seamoby@diameter.org Thu Jun 7 17:00: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 QAA14497 for ; Thu, 7 Jun 2001 16:59:57 -0400 (EDT) Received: (qmail 3801 invoked by alias); 7 Jun 2001 20:47:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3795 invoked by uid 200); 7 Jun 2001 20:47:10 -0000 Received: (qmail 3790 invoked by uid 500); 7 Jun 2001 20:47:09 -0000 Date: Thu, 7 Jun 2001 13:47:09 -0700 From: Pat Calhoun To: seamoby@diameter.org Subject: [seamoby] Seamoby Charter Message-ID: <20010607134709.Q12278@charizard.diameter.org> Mail-Followup-To: seamoby@diameter.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 revised Seamoby charter, which has been through an initial IESG review. Note that the changes are very minor, and most were done to ease readability. Thanks, PatC ---- Context Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting (seamoby) Status: recharter Last modified: 7 Jun 2001 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 mobility devices. Examples of state information that could be useful to transfer is AAA information, security context, QOS properties assigned to the user, Robust Header Compression information, etc. Further, Standards Defining Organizations (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. In addition to Context Transfer, the working group has identified two more technologies that are important for use as tools for providing real-time services over IP wireless infrastructure: Handoff Candidate Discovery and Dormant Mode Host Alerting (aka "IP paging"). The present charter (revised from its original form) is to define and then possibly develop each of these. The WG will ensure that its deliverables are compatible with the Mobile IP Working Group's mobility management technology Context Transfer 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 the Mobile IP WG, there is a need for preserving the context of its active IP flows. The IP flow context that might be useful to transfer could include, but not be limited to security context, policy, QOS (diffserv or intserv as needed) header compression, and accounting/AAA information. 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 device. Depending on the results of the requirements analysis, the SeaMoby WG 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. Handoff Candidate Discovery While the Mobile IP Working Group in particular is developing protocols to provide "fast handoff" solutions, the mechanisms currently under development assume that a set of candidates has already been chosen and and that handoff should be initiated to all of them. However, the selection of suitable candidates is not part of the Mobile IP WG's overall scope. The Seamoby Working Group has documented that "seamless" handoffs can best be achieved by considering multiple handoff candidates and selecting one or more of them as targets for context transfer. This problem is within scope of Seamoby. Specifically, 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. Dormant Mode Host Alerting 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. Protocols developed will be accompanied by MIBs. The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. Goals and Milestones: Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements to IESG for consideration as Informational Jun 01 Submit Inter Access Point Context Transfer Problem Statement to IESG Jul 01 Submit Handoff Candidate Discovery Problem Statement to IESG Sep 01 Interim Meeting to review pending Inter Access Point Context Transfer and Handoff Candidate Discovery work Oct 01 Submit Inter Access Point Context Transfer Protocol Requirements 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 Jan 02 Dormant Mode Host Alerting Protocol 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 Thu Jun 7 17:02: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 RAA14551 for ; Thu, 7 Jun 2001 17:02:23 -0400 (EDT) Received: (qmail 2021 invoked by alias); 7 Jun 2001 20:25:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2009 invoked by uid 200); 7 Jun 2001 20:25:12 -0000 Received: (qmail 1999 invoked from network); 7 Jun 2001 20:25:09 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 20:25:09 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA17034 for ; Thu, 7 Jun 2001 13:35:41 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA27144 for ; Thu, 7 Jun 2001 13:35:41 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:35:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C7C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'john.loughney@nokia.com'" , seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording Date: Thu, 7 Jun 2001 15:35:40 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF91.6A5FBF10" 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_01C0EF91.6A5FBF10 Content-Type: text/plain; charset="iso-8859-1" John, I agree with Gary, considering that this is only problem statement, his mention of corrupted context transfer covers this. In requirement draft we have a requirement on mutual authentication between CT peers and that should cover this. I think DoS is a bottomless pit and we can never get around to list every possible DoS and protection against it in such texts. Regards, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, June 05, 2001 10:50 AM To: 'john.loughney@nokia.com'; seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: [seamoby-context] RE: [seamoby] Security Considerations - new wording Sensitivity: Confidential John: Good suggestions. I was actually referring to DOS and other similar attacks with the euphemism "transfer legitimacy". Not being a security guru myself, I wasn't sure if there was an acceptable general term, so I created one. I was purposely trying to avoid being too specific in the problem statement. I worry that we could end up with a shopping list of potential threats. Given the direction we are going, I suspect that we will have to enumerate the various threats in the requirements draft anyway, as we are attempting to do with reliability (although, my preference would be to defer such a list until a proper threat analysis could be performed on the protocol design). Either way, the analysis will be done at least once, and more likely many, many times. Anyway, that was my thinking. Of course, if the dt wants, it can all be changed. Comments? Gary > -----Original Message----- > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] > Sent: Tuesday, June 05, 2001 6:01 AM > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com; > mankin@east.isi.edu > Subject: RE: [seamoby] Security Considerations - new wording > Sensitivity: Confidential > > > Hi Gary, > > I think that we need to cover DOS attacks here. I don't > think we need to go into deep detail about it, but I > can envision some problems with CT w.r.t. DOS attacks. > > The CT protocol itself might not assume any state, but > if a bad guy could send context (i.e. - state) to an AR, > it might be able to overrun the ARs buffers. > > Alternatively, we need to ensure a third party cannot > re-direct context as well. > > These two subjects could fall under the 'transfer legitimacy' > bullet. > > So, text might be: > > - prevention of DOS-style attacks. Context transfer > MUST NOT create any new opportunities for denial of > service (DOS) attacks. These include (but are not > limited to): flooding of bogus context in order > to overrun the capacity of the target node; and the > redirection of context in order to prevent the > successful completion of the context transfer. > > How's that? > > ------_=_NextPart_001_01C0EF91.6A5FBF10 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Security Considerations - new wording
John,
 
I agree with Gary, considering that this is only problem statement, his
mention of corrupted context transfer covers this.
In requirement draft we have a requirement on mutual authentication between
CT peers and that should cover this.
 
I think DoS is a bottomless pit and we can never get around to list every
possible DoS and protection against it in such texts.
 
Regards,
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, June 05, 2001 10:50 AM
To: 'john.loughney@nokia.com'; seamoby@diameter.org
Cc: seamoby-context@cdma-2000.org
Subject: [seamoby-context] RE: [seamoby] Security Considerations - new wording
Sensitivity: Confidential

John:

  Good suggestions. I was actually referring to DOS and other
similar attacks with the euphemism "transfer legitimacy". Not
being a security guru myself, I wasn't sure if there was an
acceptable general term, so I created one.

  I was purposely trying to avoid being too specific in the problem
statement. I worry that we could end up with a shopping list of
potential threats.

Given the direction we are going, I suspect that we will have to
enumerate the various threats in the requirements draft anyway, as
we are attempting to do with reliability (although, my preference
would be to defer such a list until a proper threat analysis could
be performed on the protocol design). Either way, the analysis will
be done at least once, and more likely many, many times.

Anyway, that was my thinking. Of course, if the dt wants, it can
all be changed. Comments?

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Tuesday, June 05, 2001 6:01 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com;
> mankin@east.isi.edu
> Subject: RE: [seamoby] Security Considerations - new wording
> Sensitivity: Confidential
>
>
> Hi Gary,
>
> I think that we need to cover DOS attacks here.  I don't
> think we need to go into deep detail about it, but I
> can envision some problems with CT w.r.t. DOS attacks.
>
> The CT protocol itself might not assume any state, but
> if a bad guy could send context (i.e. - state) to an AR,
> it might be able to overrun the ARs buffers. 
>
> Alternatively, we need to ensure a third party cannot
> re-direct context as well.
>
> These two subjects could fall under the 'transfer legitimacy'
> bullet. 
>
> So, text might be:
>
>       - prevention of DOS-style attacks.  Context transfer
>       MUST NOT create any new opportunities for denial of
>       service (DOS) attacks.  These include (but are not
>       limited to): flooding of bogus context in order
>       to overrun the capacity of the target node; and the
>       redirection of context in order to prevent the
>       successful completion of the context transfer.
>
> How's that?
>      
>

------_=_NextPart_001_01C0EF91.6A5FBF10-- From owner-seamoby@diameter.org Thu Jun 7 17:06: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 RAA14584 for ; Thu, 7 Jun 2001 17:05:59 -0400 (EDT) Received: (qmail 4238 invoked by alias); 7 Jun 2001 20:51:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4228 invoked by uid 200); 7 Jun 2001 20:51:22 -0000 Received: (qmail 4213 invoked by uid 500); 7 Jun 2001 20:51:18 -0000 Date: Thu, 7 Jun 2001 13:51:18 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Gary Kenward'" , "'john.loughney@nokia.com'" , seamoby@diameter.org, seamoby-context@cdma-2000.org Subject: Re: [seamoby-context] RE: [seamoby] Security Considerations - new wording Message-ID: <20010607135118.S12278@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Gary Kenward' , "'john.loughney@nokia.com'" , seamoby@diameter.org, seamoby-context@cdma-2000.org References: <35DBB8B7AC89D4118E98009027B1009B1B7C7C@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: <35DBB8B7AC89D4118E98009027B1009B1B7C7C@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Thu, Jun 07, 2001 at 03:35:40PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 07, 2001 at 03:35:40PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > John, > > I agree with Gary, considering that this is only problem statement, his > mention of corrupted context transfer covers this. > In requirement draft we have a requirement on mutual authentication between > CT peers and that should cover this. > > I think DoS is a bottomless pit and we can never get around to list every > possible DoS and protection against it in such texts. btw, all the IESG cares about is that we don't introduce new DoS possibilities, so perhaps text along these lines would be sufficient? PatC > > Regards, > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, June 05, 2001 10:50 AM > To: 'john.loughney@nokia.com'; seamoby@diameter.org > Cc: seamoby-context@cdma-2000.org > Subject: [seamoby-context] RE: [seamoby] Security Considerations - new wording > Sensitivity: Confidential > > > > John: > > Good suggestions. I was actually referring to DOS and other > similar attacks with the euphemism "transfer legitimacy". Not > being a security guru myself, I wasn't sure if there was an > acceptable general term, so I created one. > > I was purposely trying to avoid being too specific in the problem > statement. I worry that we could end up with a shopping list of > potential threats. > > Given the direction we are going, I suspect that we will have to > enumerate the various threats in the requirements draft anyway, as > we are attempting to do with reliability (although, my preference > would be to defer such a list until a proper threat analysis could > be performed on the protocol design). Either way, the analysis will > be done at least once, and more likely many, many times. > > Anyway, that was my thinking. Of course, if the dt wants, it can > all be changed. Comments? > > Gary > > > -----Original Message----- > > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] > > Sent: Tuesday, June 05, 2001 6:01 AM > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > > Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com; > > mankin@east.isi.edu > > Subject: RE: [seamoby] Security Considerations - new wording > > Sensitivity: Confidential > > > > > > Hi Gary, > > > > I think that we need to cover DOS attacks here. I don't > > think we need to go into deep detail about it, but I > > can envision some problems with CT w.r.t. DOS attacks. > > > > The CT protocol itself might not assume any state, but > > if a bad guy could send context (i.e. - state) to an AR, > > it might be able to overrun the ARs buffers. > > > > Alternatively, we need to ensure a third party cannot > > re-direct context as well. > > > > These two subjects could fall under the 'transfer legitimacy' > > bullet. > > > > So, text might be: > > > > - prevention of DOS-style attacks. Context transfer > > MUST NOT create any new opportunities for denial of > > service (DOS) attacks. These include (but are not > > limited to): flooding of bogus context in order > > to overrun the capacity of the target node; and the > > redirection of context in order to prevent the > > successful completion of the context transfer. > > > > How's that? > > > > > From owner-seamoby@diameter.org Thu Jun 7 17: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 RAA14665 for ; Thu, 7 Jun 2001 17:11:14 -0400 (EDT) Received: (qmail 4935 invoked by alias); 7 Jun 2001 20:58:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4929 invoked by uid 200); 7 Jun 2001 20:58:04 -0000 Received: (qmail 4921 invoked from network); 7 Jun 2001 20:58:01 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jun 2001 20:58:01 -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 PAA00143; Thu, 7 Jun 2001 15:08:34 -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 OAA02751; Thu, 7 Jun 2001 14:08:34 -0700 (PDT) Message-Id: <200106072108.OAA02751@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 14:08:34 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] Seamoby Charter To: seamoby@diameter.org, pcalhoun@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: X/fqUVwwe/yHxOOt4aDHog== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Pat, I notice there is a date for context transfer and handoff candidate discovery protocols to be compared to requirements, but no such date for DMHA protocols. Also, the DMHA MIB submission preceedes the submission of the actual protocol. Isn't it usually the other way around. jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Thu, 7 Jun 2001 13:47:09 -0700 >From: Pat Calhoun >To: seamoby@diameter.org >Subject: [seamoby] Seamoby Charter >Mail-Followup-To: seamoby@diameter.org >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >All, > >Below is the revised Seamoby charter, which has been through an initial IESG >review. Note that the changes are very minor, and most were done to ease >readability. > >Thanks, > >PatC >---- > >Context Transfer, Handoff Candidate Discovery and Dormant Mode Host >Alerting (seamoby) > >Status: recharter > >Last modified: 7 Jun 2001 > >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 mobility devices. Examples of state information that could be >useful to transfer is AAA information, security context, QOS properties >assigned to the user, Robust Header Compression information, etc. > >Further, Standards Defining Organizations (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. > >In addition to Context Transfer, the working group has identified two more >technologies that are important for use as tools for providing real-time >services over IP wireless infrastructure: Handoff Candidate Discovery >and Dormant Mode Host Alerting (aka "IP paging"). The present charter >(revised from its original form) is to define and then possibly develop >each of these. The WG will ensure that its deliverables are compatible >with the Mobile IP Working Group's mobility management technology > >Context Transfer > >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 the Mobile IP WG, >there is a need for preserving the context of its active IP flows. The IP flow >context that might be useful to transfer could include, but not be limited >to security context, policy, QOS (diffserv or intserv as needed) >header compression, and accounting/AAA information. > >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 device. Depending on the results of the requirements analysis, the SeaMoby >WG 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. > > >Handoff Candidate Discovery > >While the Mobile IP Working Group in particular is developing >protocols to provide "fast handoff" solutions, the mechanisms >currently under development assume that a set of candidates has >already been chosen and and that handoff should be initiated to all of >them. However, the selection of suitable candidates is not part of the >Mobile IP WG's overall scope. The Seamoby Working Group has >documented that "seamless" handoffs can best be achieved by >considering multiple handoff candidates and selecting one or more of >them as targets for context transfer. This problem is within scope of >Seamoby. Specifically, 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. > > >Dormant Mode Host Alerting > >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. Protocols developed will be >accompanied by MIBs. > >The Working Group will coordinate closely with the aaa, mobileip, >pilc, and rohc working groups. > > >Goals and Milestones: > >Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements to IESG > for consideration as Informational >Jun 01 Submit Inter Access Point Context Transfer Problem Statement to IESG >Jul 01 Submit Handoff Candidate Discovery Problem Statement to IESG >Sep 01 Interim Meeting to review pending Inter Access Point Context > Transfer and Handoff Candidate Discovery work >Oct 01 Submit Inter Access Point Context Transfer Protocol Requirements > 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 >Jan 02 Dormant Mode Host Alerting Protocol 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 Thu Jun 7 18:12:39 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15356 for ; Thu, 7 Jun 2001 18:12:38 -0400 (EDT) Received: (qmail 1163 invoked by alias); 7 Jun 2001 22:01:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1157 invoked by uid 200); 7 Jun 2001 22:01:45 -0000 Received: (qmail 1147 invoked by uid 500); 7 Jun 2001 22:01:42 -0000 Date: Thu, 7 Jun 2001 15:01:42 -0700 From: Pat Calhoun To: James Kempf Cc: seamoby@diameter.org, pcalhoun@diameter.org, mankin@east.isi.edu Subject: [seamoby] Revised Seamoby Charter milestones Message-ID: <20010607150141.A1100@charizard.diameter.org> Mail-Followup-To: James Kempf , seamoby@diameter.org, pcalhoun@diameter.org, mankin@east.isi.edu References: <200106072108.OAA02751@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: <200106072108.OAA02751@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Thu, Jun 07, 2001 at 02:08:34PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk Jim, Thanks for the catch. I was rather harsh in moving the protocol to PS out, and forgot about the MIB. The work item to submit candidate protocols is now added with a Sep deadline. If the requirements I-D gets through IESG before that time, we can revise our times. Below is the latest charter. Thanks, PatC ---- Goals and Milestones: Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements to IESG for consideration as Informational Jun 01 Submit Inter Access Point Context Transfer Problem Statement to IESG Jul 01 Submit Handoff Candidate Discovery Problem Statement to IESG Sep 01 Interim Meeting to review pending Inter Access Point Context Transfer and Handoff Candidate Discovery work Sep 01 Candidate Mode Host Alerting Protocol Protocols are submitted, with accompanying comparison against requirements Oct 01 Submit Inter Access Point Context Transfer Protocol Requirements 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 Jan 02 Dormant Mode Host Alerting Protocol 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 May 02 Dormant Mode Host Alerting Protocol MIB 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 Thu Jun 7 22:58: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 WAA20000 for ; Thu, 7 Jun 2001 22:58:41 -0400 (EDT) Received: (qmail 2398 invoked by alias); 8 Jun 2001 02:46:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2392 invoked by uid 200); 8 Jun 2001 02:46:07 -0000 Received: (qmail 2387 invoked from network); 8 Jun 2001 02:46:06 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 02:46:06 -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 TAA27238; Thu, 7 Jun 2001 19:55:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f582tkN21986; Thu, 7 Jun 2001 19:55:46 -0700 X-mProtect: Thu, 7 Jun 2001 19:55:46 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0ZRo69; Thu, 07 Jun 2001 19:55:45 PDT Message-ID: <3B203EB2.2DED055A@iprg.nokia.com> Date: Thu, 07 Jun 2001 19:55:46 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Syed CC: "'Charles E. Perkins'" , Gary Kenward , Seamless Mobility Working Group Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt References: <9FBD322B7824D511B36900508BF93C9C1CD0C3@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hamid Syed wrote: > > > > "Shipping" contexts (some folks call it transferring contexts > BTW) is an > integral part of the Context Transfer Protocol. Indeed, you need > to know > the target router, which is a separate protocol/mechanism. Once > you do > know the target router, I guess you would be interested in > transferring > contexts in CT. It seems intuitively obvious to do CT along with > handovers. > [Syed, Hamid [WDLN2:AN22:EXCH]] I agree that handoff candidate > discovery could be done through a separate protocol (and btw that > is what our framework is suggesting) but I disagree isolating the > two problems or making assumptions about their interworking. How > the other protocol would work with any context transfer > protocol?. which entity would determine or enable a suitable > candidate discovery?. what are the related triggers or events?. > All this is the part of context transfer problem domain and we > cannot deny it. Any framework for context transfer must address > all the issues. We cannot go making assupmtions about phenomenon > that are closely realted to the context transfer. > > > Well, I don't deny that there are problems to consider in target router selection. Indeed, because the space is open and yet unknown, we cannot go into speculation. That's the point. The CT protocol work can continue without having to speculate on target router selection. I hope you would agree. > > handover. Identifying the potential context candidates and > a > > close interworking with the mobility mechanism are equally > > > important to be addressed in the context transfer > framework. Our > > draft is focused on distributing the functional roles to > the ct > > entities and defining interfaces between them. The context > > > transfer protocol is only one > > > > In the CT problem statement draft, we have identified the > entities: AR, > AP, MN, MH > [Syed, Hamid [WDLN2:AN22:EXCH]] Well..i do not disagree but AR > is a an entity that contains more than one function in it (see > the definition of AR). While our framework identifies the > entities that are specific to context transfer and actively > participates in the context transfer process. > > > aspect of the over all problem domain and that is what > your draft > > is proposing, a solution for shipping context from one AR > to the > > other. I may consider your submission as a candidate > solution for > > context trasnfer protocol but this is not a framework. I > believe > > that frameworks should focus on functional models and > interface > > definitions and the details of individual protocols must > be taken > > ouitside the framework document. > > > > By interface defintions do you mean protocol messages ? Or do you > have > 3G interfaces in mind ? > [Syed, Hamid [WDLN2:AN22:EXCH]] IETF protocols. which are > definitely interfaces between entities. > > I guess I don't have the same terminology as you do. I cannot think of a protocol as an interface between two entities (which BTW sounds lot like the 3G jargon). To me, a protocol is an understanding (formal rules) between communicating peers, whereas an interface is a boundary between two entities. [this is purely academic, but has some value to clear confusion in the future] > > > > > > > I would like to suggest that establishing communities or > > neighborhoods > > or groups of access routers could be handled by a protocol > which > > would > > be separate than the protocol for doing the context > transfer, and > > > > further that in many instances it wouldn't be necessary to > make > > the > > access router groups at all. > > [Syed, Hamid [WDLN2:AN22:EXCH]] This is what the > framework has > > captured, a separate protocol for context group management > and > > another protocol for context transfer. I would say, > identifying a > > suitable candidate for handover amongst the context group > members > > will help minimizing the service disruption during > handover. > > Defining a handover candidate discovery protocol is > already part > > of Seamoby WG charter and our framework shows how the > functional > > entities interact with each other through the standard > > interfaces. > > > > > > > You are right that target router discovery is part of seamoby > work. We > all have our views on how this would work with CT. Once we have > that > work (target router selection) done, we will be able to better > relate to > it. Until then, I think it suffices to say that some seamoby > entity > provides us the target router address. > [Syed, Hamid [WDLN2:AN22:EXCH]] Again..why try solving problems > by making assumptions about the important details. Why not work > on a framework that covers all the problem areas with no > assumptions. Try a high level design first and then go for > individual protocol definition. I do not understand the need for > a shortcut approach. > > > Why create a complex problem space when you can work on modular problems ? When there is better visibility, things will unfold. Regards, -Rajeev > > > > I wondered whether you had taken a look at our previous > framework > > > > draft, and if so whether you think meet the requirements. > If you > > > > didn't see it yet, and if you'd like to take a look, here > is the > > URL: > > > > > http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt > > > > > Regards, > > Charlie P. > > [Syed, Hamid [WDLN2:AN22:EXCH]] Thanx for your comments. > > > > > Hamid Syed wrote: > > > > > > Hello CT Folks, > > > > > > I have submitted a framework draft for context transfer. > I > > would appreciate > > > and welcome any comments on the draft. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > > > > > > > > cheers > > > > > > -Hamid > > > From owner-seamoby@diameter.org Thu Jun 7 23:06: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 XAA20108 for ; Thu, 7 Jun 2001 23:05:47 -0400 (EDT) Received: (qmail 2504 invoked by alias); 8 Jun 2001 02:46:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2497 invoked by uid 200); 8 Jun 2001 02:46:52 -0000 Received: (qmail 2476 invoked from network); 8 Jun 2001 02:46:44 -0000 Received: from d139-kauai-lih0.midpac.net (HELO young) (204.149.167.139) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 02:46:44 -0000 Message-ID: <30058200165824937930@young> 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] Your Order (MLM Plan) Date: Thu, 7 Jun 2001 16:49:37 -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 XAA20108 Dear Friend, here is your Multi-Level Marketing Plan: "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. Mitchell 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: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: C. Shaw P.O. Box 468 Schomberg, Ontario Canada L0G IT0 ============================================== 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 Fri Jun 8 01:48:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24144 for ; Fri, 8 Jun 2001 01:48:40 -0400 (EDT) Received: (qmail 3629 invoked by alias); 8 Jun 2001 05:37:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3623 invoked by uid 200); 8 Jun 2001 05:37:54 -0000 Received: (qmail 3602 invoked from network); 8 Jun 2001 05:37:50 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 05:37:50 -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 f585lHe15599 for ; Fri, 8 Jun 2001 08:47:17 +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, 8 Jun 2001 08:47:54 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Fri, 8 Jun 2001 08:47:54 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B0AA@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 08:47:51 +0300 Sensitivity: Company-Confidential 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 think DoS is a bottomless pit and we can never get around to list every possible DoS and protection against it in such texts. [ ] Of course, but if CT can introduce new DOS attacks (or novel at least) I believe the Problem Statement needs to mention what sorts of novel DOS may occur because of CT. John From owner-seamoby@diameter.org Fri Jun 8 09:28: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 JAA12176 for ; Fri, 8 Jun 2001 09:27:51 -0400 (EDT) Received: (qmail 5017 invoked by alias); 8 Jun 2001 13:11:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5010 invoked by uid 200); 8 Jun 2001 13:11:40 -0000 Received: (qmail 5002 invoked from network); 8 Jun 2001 13:11:37 -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; 8 Jun 2001 13:11:37 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f58DLAE09404; Fri, 8 Jun 2001 09:21:10 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 8 Jun 2001 09:21:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 09:21:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0C8@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Pat Calhoun'" , seamoby@diameter.org Subject: RE: [seamoby] Seamoby Charter Date: Fri, 8 Jun 2001 09:21:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F01D.F173A660" 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_01C0F01D.F173A660 Content-Type: text/plain; charset="ISO-8859-1" Hello Pat, I guess we need a milestone for context trasnfer framework before moving towards the protocols. cheers -Hamid > -----Original Message----- > From: Pat Calhoun [SMTP:pcalhoun@diameter.org] > Sent: Thursday, June 07, 2001 4:47 PM > To: seamoby@diameter.org > Subject: [seamoby] Seamoby Charter > > All, > > Below is the revised Seamoby charter, which has been through an initial > IESG > review. Note that the changes are very minor, and most were done to ease > readability. > > Thanks, > > PatC > ---- > > Context Transfer, Handoff Candidate Discovery and Dormant Mode Host > Alerting (seamoby) > > Status: recharter > > Last modified: 7 Jun 2001 > > 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 mobility devices. Examples of state information that could be > useful to transfer is AAA information, security context, QOS properties > assigned to the user, Robust Header Compression information, etc. > > Further, Standards Defining Organizations (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. > > In addition to Context Transfer, the working group has identified two more > technologies that are important for use as tools for providing real-time > services over IP wireless infrastructure: Handoff Candidate Discovery > and Dormant Mode Host Alerting (aka "IP paging"). The present charter > (revised from its original form) is to define and then possibly develop > each of these. The WG will ensure that its deliverables are compatible > with the Mobile IP Working Group's mobility management technology > > Context Transfer > > 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 the Mobile IP WG, > there is a need for preserving the context of its active IP flows. The IP > flow > context that might be useful to transfer could include, but not be limited > > to security context, policy, QOS (diffserv or intserv as needed) > header compression, and accounting/AAA information. > > 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 device. Depending on the results of the requirements analysis, the > SeaMoby > WG 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. > > > Handoff Candidate Discovery > > While the Mobile IP Working Group in particular is developing > protocols to provide "fast handoff" solutions, the mechanisms > currently under development assume that a set of candidates has > already been chosen and and that handoff should be initiated to all of > them. However, the selection of suitable candidates is not part of the > Mobile IP WG's overall scope. The Seamoby Working Group has > documented that "seamless" handoffs can best be achieved by > considering multiple handoff candidates and selecting one or more of > them as targets for context transfer. This problem is within scope of > Seamoby. Specifically, 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. > > > Dormant Mode Host Alerting > > 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. Protocols developed will be > accompanied by MIBs. > > The Working Group will coordinate closely with the aaa, mobileip, > pilc, and rohc working groups. > > > Goals and Milestones: > > Jun 01 Submit I-D on Dormant Mode Host Alerting Requirements to IESG > for consideration as Informational > Jun 01 Submit Inter Access Point Context Transfer Problem Statement to > IESG > Jul 01 Submit Handoff Candidate Discovery Problem Statement to IESG > Sep 01 Interim Meeting to review pending Inter Access Point Context > Transfer and Handoff Candidate Discovery work > Oct 01 Submit Inter Access Point Context Transfer Protocol Requirements > 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 > Jan 02 Dormant Mode Host Alerting Protocol 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_01C0F01D.F173A660 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Seamoby Charter

Hello Pat,

I guess we need a = milestone for context trasnfer framework before moving towards the = protocols.

cheers

-Hamid

    -----Original Message-----
    From:   Pat Calhoun [SMTP:pcalhoun@diameter.org]
    Sent:   Thursday, June 07, 2001 4:47 PM
    To:     seamoby@diameter.org
    Subject:       = [seamoby] Seamoby Charter

    All,

    Below is the revised Seamoby charter, = which has been through an initial IESG
    review. Note that the changes are = very minor, and most were done to ease
    readability.

    Thanks,

    PatC
    ----

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

    Status: recharter

    Last modified:  7 Jun 2001

    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 mobility devices. = Examples of state information that could be
    useful to transfer is AAA = information, security context, QOS properties
    assigned to the user, Robust Header = Compression information, etc. 

    Further, Standards Defining = Organizations (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.

    In addition to Context Transfer, the = working group has identified two more
    technologies that are important for = use as tools for providing real-time
    services over IP wireless = infrastructure:  Handoff Candidate Discovery
    and Dormant Mode Host Alerting (aka = "IP paging").  The present charter
    (revised from its original form) is = to define and then possibly develop
    each of these.  The WG will = ensure that its deliverables are compatible
    with the Mobile IP Working Group's = mobility management technology

    Context Transfer

    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 the Mobile IP WG,
    there is a need for preserving the = context of its active IP flows. The IP flow
    context that might be useful to = transfer could include, but not be limited
    to security context, policy, QOS = (diffserv or intserv as needed)
    header compression, and = accounting/AAA information.

    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 device. Depending on the = results of the requirements analysis, the SeaMoby
    WG 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.


    Handoff Candidate Discovery

    While the Mobile IP Working Group in = particular is developing
    protocols to provide "fast = handoff" solutions, the mechanisms
    currently under development assume = that a set of candidates has
    already been chosen and and that = handoff should be initiated to all of
    them.   However, the = selection of suitable candidates is not part of the
    Mobile IP WG's overall scope.  = The Seamoby Working Group has
    documented that "seamless" = handoffs can best be achieved by
    considering multiple handoff = candidates and selecting one or more of
    them as targets for context transfer. = This problem is within scope of
    Seamoby. Specifically, 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.


    Dormant Mode Host Alerting

    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.   Protocols developed will be
    accompanied by MIBs.

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


    Goals and Milestones:

    Jun 01  Submit I-D on Dormant = Mode Host Alerting Requirements to IESG
            for consideration as Informational
    Jun 01  Submit Inter Access = Point Context Transfer Problem Statement to IESG
    Jul 01  Submit Handoff Candidate = Discovery Problem Statement to IESG
    Sep 01  Interim Meeting to = review pending Inter Access Point Context
            Transfer and Handoff Candidate Discovery work
    Oct 01  Submit Inter Access = Point Context Transfer Protocol Requirements
            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
    Jan 02  Dormant Mode Host = Alerting Protocol 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_01C0F01D.F173A660-- From owner-seamoby@diameter.org Fri Jun 8 09:35:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12340 for ; Fri, 8 Jun 2001 09:35:46 -0400 (EDT) Received: (qmail 5211 invoked by alias); 8 Jun 2001 13:16:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5204 invoked by uid 200); 8 Jun 2001 13:16:13 -0000 Received: (qmail 5194 invoked from network); 8 Jun 2001 13:16:08 -0000 Received: from east.isi.edu (38.245.76.2) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 13:16:08 -0000 Received: from minotaur.east.isi.edu (minotaur.east.isi.edu [38.218.19.202]) by east.isi.edu (8.11.3/8.9.2) with ESMTP id f58DPnK08770; Fri, 8 Jun 2001 09:25:49 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.east.isi.edu (8.11.0/8.11.0) with ESMTP id f58DQ3w05782; Fri, 8 Jun 2001 09:26:03 -0400 Message-Id: <200106081326.f58DQ3w05782@minotaur.east.isi.edu> To: "Gary Kenward" cc: "'seamoby'" , pcalhoun@diameter.org, sob@harvard.edu Reply-To: mankin@isi.edu Subject: Re: Comments Re: [seamoby] ct problem statement In-reply-to: Your message of Mon, 04 Jun 2001 13:49:01 -0400. <9FBD322B7824D511B36900508BF93C9C9F5C8C@zcard031.ca.nortel.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Fri, 08 Jun 2001 09:26:03 -0400 From: Allison Mankin Sender: owner-seamoby@diameter.org Precedence: bulk All, I've been reading carefully the thread caused by my request to enhance the security considerations in the CT problem statement. My request reflects the view that IESG will take. In the past, an AD might have worked quietly with the editor and chair and then given the WG a last look, but the TSV area is trying to do the AD jobs as much as possible in the open now. We've gained by seeing the wide range of the WG's understandings of security in seamoby protocols. A few overall points, also made by others, that I want to underline: IETF security technologies are generally expressed as mandatory-to- implement but optional to deploy. Although vendors can elect to speed or price-cut their product by ignoring the mandatory-to-implement, they are nort then honest if they say they comply with the IETF standard. That's their choice, absolutely. Security considerations in a draft express risks that a user or operator may encounter, to help guide the decision about whether to deploy the available technology (and also whether to deploy a compliant product rather than one that lacks security protections). Going all the way back to Monday, Gary asked: > The second point troubles me somewhat: ct is essentially an information > transfer operation. I do not understand (and I can only state this as my > being confusion) why it is not enough to say that this information transfer > must be secure. Why would a ct be any different from any other data transfer > that needs to be secured? Besides the content transferred being given appropriate data confidentiality and integrity, the authority given to a CT arriving needs protection. Unlike an arbitrary user message, CT information quite possible can change what happens to the flow - unauthorized CT information that is accepted could alter characteristics the user paid or could disrupt the operator (service could be stolen). Note, both user and _operator_ have risks. All risks won't be identified and some won't have solutionss - as a number of people in the thread noted, some of the risks, such as general denial of service, are very hard to remedy. I would like to recommend that the requirements documents for each seamoby protocol include a section on a threat model. This should be the threats specific to the protocol, not all aspects of securing a (wireless) internet. As with all IETF work, the goal is not to try for perfection, but to add to everyone's technical depth in a best effort. Another recommendation I'll make is for more security experts to be involved in the seamoby protocol designs early on. I'm working on pointing some folks who haven't been involved into the requirements document work now. A goal will be able to state requirements and not have to create new technology to serve them. There'll be plenty of chance to complain, like I need to offer this ;>. Allison From owner-seamoby@diameter.org Fri Jun 8 09:51: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 JAA12577 for ; Fri, 8 Jun 2001 09:51:05 -0400 (EDT) Received: (qmail 5984 invoked by alias); 8 Jun 2001 13:31:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5978 invoked by uid 200); 8 Jun 2001 13:31:52 -0000 Received: (qmail 5973 invoked from network); 8 Jun 2001 13:31:50 -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; 8 Jun 2001 13:31:50 -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 f58DfSE13037 for ; Fri, 8 Jun 2001 09:41:28 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 09:41:26 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 09:41:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0C9@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Rajeev Koodli'" Cc: "'Charles E. Perkins'" , "Gary Kenward" , Seamless Mobility Working Group Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt Date: Fri, 8 Jun 2001 09:41:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F020.C9AE58C0" 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_01C0F020.C9AE58C0 Content-Type: text/plain; charset="ISO-8859-1" Rajeev, see my response below. > -----Original Message----- > From: Rajeev Koodli [SMTP:rajeev@IPRG.nokia.com] > Sent: Thursday, June 07, 2001 10:56 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: 'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless > Mobility Working Group > Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt > > Hamid Syed wrote: > > > > > > > > > "Shipping" contexts (some folks call it transferring contexts > > BTW) is an > > integral part of the Context Transfer Protocol. Indeed, you need > > to know > > the target router, which is a separate protocol/mechanism. Once > > you do > > know the target router, I guess you would be interested in > > transferring > > contexts in CT. It seems intuitively obvious to do CT along with > > handovers. > > [Syed, Hamid [WDLN2:AN22:EXCH]] I agree that handoff candidate > > discovery could be done through a separate protocol (and btw that > > is what our framework is suggesting) but I disagree isolating the > > two problems or making assumptions about their interworking. How > > the other protocol would work with any context transfer > > protocol?. which entity would determine or enable a suitable > > candidate discovery?. what are the related triggers or events?. > > All this is the part of context transfer problem domain and we > > cannot deny it. Any framework for context transfer must address > > all the issues. We cannot go making assupmtions about phenomenon > > that are closely realted to the context transfer. > > > > > > > > Well, I don't deny that there are problems to consider in target router > selection. Indeed, because the space is open and yet unknown, we cannot > go into speculation. That's the point. The CT protocol work can continue > without having to speculate on target router selection. I hope you would > agree. [Syed, Hamid [WDLN2:AN22:EXCH]] I disagree. I guess the whole purpose of this long process of going through the problem statement and capturing requirements was to understand the problem space in depth. Now as we know that the context transfer between ARs is not the only problem area in support of seamless mobility (which I believe is the goal for Seamoby WG), you are suggesting to make a short cut and define context transfer protocol only. Then why did we spent six months at least for problem statement and requirements gathering?. The inter AR context transfer problem was known from the begining and we only found out the other aspects (handoff candidate discovery for example) during this whole six months exercise. I dont believe that we just wasted time in the past. We had very useful discussions on the list and we had a better understanding of the problem. So lets work to understand the how these different problem areas are related to each other and how better solutions can be developed instead of rushing for context transfer protocol definition which is ,of course, one major aspect of the problem and we need to do this part. But the Wg is moving forward in steps (and I support this approach), we should first define a high level framework or design to show how different protocols can interact. This is exactly the way other WGs has been working in IETF (RAP WG is one example on top of my head). Now I hope that you would agree.....:-) > > > handover. Identifying the potential context candidates and > > a > > > close interworking with the mobility mechanism are equally > > > > > important to be addressed in the context transfer > > framework. Our > > > draft is focused on distributing the functional roles to > > the ct > > > entities and defining interfaces between them. The context > > > > > transfer protocol is only one > > > > > > > In the CT problem statement draft, we have identified the > > entities: AR, > > AP, MN, MH > > [Syed, Hamid [WDLN2:AN22:EXCH]] Well..i do not disagree but AR > > is a an entity that contains more than one function in it (see > > the definition of AR). While our framework identifies the > > entities that are specific to context transfer and actively > > participates in the context transfer process. > > > > > aspect of the over all problem domain and that is what > > your draft > > > is proposing, a solution for shipping context from one AR > > to the > > > other. I may consider your submission as a candidate > > solution for > > > context trasnfer protocol but this is not a framework. I > > believe > > > that frameworks should focus on functional models and > > interface > > > definitions and the details of individual protocols must > > be taken > > > ouitside the framework document. > > > > > > > By interface defintions do you mean protocol messages ? Or do you > > have > > 3G interfaces in mind ? > > [Syed, Hamid [WDLN2:AN22:EXCH]] IETF protocols. which are > > definitely interfaces between entities. > > > > > > I guess I don't have the same terminology as you do. I cannot think of a > protocol as an interface between two entities (which BTW sounds lot like > the 3G jargon). To me, a protocol is an understanding (formal rules) > between communicating peers, whereas an interface is a boundary between > two entities. > [this is purely academic, but has some value to clear confusion in the > future] [Syed, Hamid [WDLN2:AN22:EXCH]] Well. I dont want to start a debate on it..I guess we are on the same page. So I agree with you here.. > > > > > > > > > > > I would like to suggest that establishing communities or > > > neighborhoods > > > or groups of access routers could be handled by a protocol > > which > > > would > > > be separate than the protocol for doing the context > > transfer, and > > > > > > further that in many instances it wouldn't be necessary to > > make > > > the > > > access router groups at all. > > > [Syed, Hamid [WDLN2:AN22:EXCH]] This is what the > > framework has > > > captured, a separate protocol for context group management > > and > > > another protocol for context transfer. I would say, > > identifying a > > > suitable candidate for handover amongst the context group > > members > > > will help minimizing the service disruption during > > handover. > > > Defining a handover candidate discovery protocol is > > already part > > > of Seamoby WG charter and our framework shows how the > > functional > > > entities interact with each other through the standard > > > interfaces. > > > > > > > > > > > You are right that target router discovery is part of seamoby > > work. We > > all have our views on how this would work with CT. Once we have > > that > > work (target router selection) done, we will be able to better > > relate to > > it. Until then, I think it suffices to say that some seamoby > > entity > > provides us the target router address. > > [Syed, Hamid [WDLN2:AN22:EXCH]] Again..why try solving problems > > by making assumptions about the important details. Why not work > > on a framework that covers all the problem areas with no > > assumptions. Try a high level design first and then go for > > individual protocol definition. I do not understand the need for > > a shortcut approach. > > > > > > > > Why create a complex problem space when you can work on modular problems > ? When there is better visibility, things will unfold. [Syed, Hamid [WDLN2:AN22:EXCH]] See my response above. We did spent time to understand a "complex problem space" and we should define a modular high level design first. I do not believe that the ct problem areas are isolated from each other. There is a lot of dependency and we need to understand it. cheers Hamid > Regards, > > -Rajeev > > > > > > > > > > I wondered whether you had taken a look at our previous > > framework > > > > > > draft, and if so whether you think meet the requirements. > > If you > > > > > > didn't see it yet, and if you'd like to take a look, here > > is the > > > URL: > > > > > > > > > http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt > > > > > > > > Regards, > > > Charlie P. > > > [Syed, Hamid [WDLN2:AN22:EXCH]] Thanx for your comments. > > > > > > > Hamid Syed wrote: > > > > > > > > Hello CT Folks, > > > > > > > > I have submitted a framework draft for context transfer. > > I > > > would appreciate > > > > and welcome any comments on the draft. > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt > > > > > > > > > > > > > cheers > > > > > > > > -Hamid > > > > > > ------_=_NextPart_001_01C0F020.C9AE58C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt

Rajeev,

see my response = below.

    -----Original Message-----
    From:   Rajeev Koodli = [SMTP:rajeev@IPRG.nokia.com]
    Sent:   Thursday, June 07, 2001 10:56 PM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; = Seamless Mobility Working Group
    Subject:       = Re: [seamoby] I-D = ACTION:draft-hamid-seamoby-ct-fwk-00.txt

    Hamid Syed wrote:

    >
    >
    >
    >      = "Shipping" contexts (some folks call it transferring = contexts
    >      = BTW) is an
    >      = integral part of the Context Transfer Protocol. Indeed, you need
    >      to = know
    >      = the target router, which is a separate protocol/mechanism. Once
    >      = you do
    >      = know the target router, I guess you would be interested in
    >      = transferring
    >      = contexts in CT. It seems intuitively obvious to do CT along with
    >      = handovers.
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  I agree that handoff = candidate
    >      = discovery could be done through a separate protocol (and btw = that
    >      is = what our framework is suggesting) but I disagree isolating the
    >      = two problems or making assumptions about their interworking. How
    >      = the other protocol would work with any context transfer
    >      = protocol?. which entity would determine or enable a suitable
    >      = candidate discovery?. what are the related triggers or events?.
    >      = All this is the part of context transfer problem domain and we
    >      = cannot deny it. Any framework for context transfer must address
    >      = all the issues. We cannot go making assupmtions about phenomenon
    >      = that are closely realted to the context transfer.
    >
    >
    >

    Well, I don't deny that there are = problems to consider in target router
    selection. Indeed, because the space = is open and yet unknown, we cannot
    go into speculation. That's the = point. The CT protocol work can continue
    without having to speculate on target = router selection. I hope you would
    agree.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I disagree. I guess the whole purpose of this = long process of going through the problem statement and capturing = requirements was to understand the problem space in depth. Now as we = know that the context transfer between ARs is not the only problem area = in support of seamless mobility (which I believe is the goal for = Seamoby WG), you are suggesting to make a short cut and define context = transfer protocol only. Then why did we spent six months at least for = problem statement and requirements gathering?. The inter AR context = transfer problem was known from the begining and we only found out the = other aspects (handoff candidate discovery for example) during this = whole six months exercise. I dont believe that we just wasted time in = the past. We had very useful discussions on the list and we had a = better understanding of the problem. So lets work to understand the how = these different problem areas are related to each other and how better = solutions can be developed instead of rushing for context transfer = protocol definition which is ,of course, one major aspect of the = problem and we need to do this part. But the Wg is moving forward in = steps (and I support this approach), we should first define a high = level framework or design to show how different protocols can interact. = This is exactly the way other WGs has been working in IETF (RAP WG is = one example on top of my head).

    Now I hope that you = would agree.....:-)


    >      = >      handover. Identifying the potential = context candidates and
    >      = a
    >      = >      close interworking with the mobility = mechanism are equally
    >
    >      = >      important to be addressed in the = context transfer
    >      = framework. Our
    >      = >      draft is focused on distributing the = functional roles to
    >      = the ct
    >      = >      entities and defining interfaces = between them. The context
    >
    >      = >      transfer protocol is only one
    >      = >
    >
    >      In = the CT problem statement draft, we have identified the
    >      = entities: AR,
    >      = AP, MN, MH
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  Well..i do not disagree but = AR
    >      is = a an entity that contains more than one function in it (see
    >      = the definition of AR). While our framework identifies the
    >      = entities that are specific to context transfer and actively
    >      = participates in the context transfer process.
    >
    >      = >      aspect of the over all problem = domain and that is what
    >      = your draft
    >      = >      is proposing, a solution for = shipping context from one AR
    >      to = the
    >      = >      other. I may consider your = submission as a candidate
    >      = solution for
    >      = >      context trasnfer protocol but this = is not a framework. I
    >      = believe
    >      = >      that frameworks should focus on = functional models and
    >      = interface
    >      = >      definitions and the details of = individual protocols must
    >      be = taken
    >      = >      ouitside the framework = document.
    >      = >
    >
    >      By = interface defintions do you mean protocol messages ? Or do you
    >      = have
    >      3G = interfaces in mind ?
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  IETF protocols. which are
    >      = definitely interfaces between entities.
    >
    >

    I guess I don't have the same = terminology as you do. I cannot think of a
    protocol as an interface between two = entities (which BTW sounds lot like
    the 3G jargon). To me, a protocol is = an understanding (formal rules)
    between communicating peers, whereas = an interface is a boundary between
    two entities.
    [this is purely academic, but has = some value to clear confusion in the
    future]
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Well. I dont want to start a debate on it..I = guess we are on the same page. So I agree with you here..


    >
    >      = >
    >      = >
    >      = >      I would like to suggest that = establishing communities or
    >      = >      neighborhoods
    >      = >      or groups of access routers could be = handled by a protocol
    >      = which
    >      = >      would
    >      = >      be separate than the protocol for = doing the context
    >      = transfer, and
    >      = >
    >      = >      further that in many instances it = wouldn't be necessary to
    >      = make
    >      = >      the
    >      = >      access router groups at all.
    >      = >      [Syed, Hamid = [WDLN2:AN22:EXCH]]   This is what the
    >      = framework has
    >      = >      captured, a separate protocol for = context group management
    >      = and
    >      = >      another protocol for context = transfer. I would say,
    >      = identifying a
    >      = >      suitable candidate for handover = amongst the context group
    >      = members
    >      = >      will help minimizing the service = disruption during
    >      = handover.
    >      = >      Defining a handover candidate = discovery protocol is
    >      = already part
    >      = >      of Seamoby WG charter and our = framework shows how the
    >      = functional
    >      = >      entities interact with each other = through the standard
    >      = >      interfaces.
    >      = >
    >      = >
    >      = >
    >      = You are right that target router discovery is part of seamoby
    >      = work. We
    >      = all have our views on how this would work with CT. Once we have
    >      = that
    >      = work (target router selection) done, we will be able to better
    >      = relate to
    >      = it. Until then, I think it suffices to say that some seamoby
    >      = entity
    >      = provides us the target router address.
    >      = [Syed, Hamid [WDLN2:AN22:EXCH]]  Again..why try solving = problems
    >      by = making assumptions about the important details. Why not work
    >      on = a framework that covers all the problem areas with no
    >      = assumptions. Try a high level design first and then go for
    >      = individual protocol definition. I do not understand the need for
    >      a = shortcut approach.
    >
    >
    >

    Why create a complex problem space = when you can work on modular problems
    ? When there is better visibility, = things will unfold.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  See my response above. We did spent time to = understand a "complex problem space" and we should define a = modular high level design first. I do not believe that the ct problem = areas are isolated from each other. There is a lot of dependency and we = need to understand it.

    cheers

    Hamid

    Regards,

    -Rajeev




    >      = >
    >      = >      I wondered whether you had taken a = look at our previous
    >      = framework
    >      = >
    >      = >      draft, and if so whether you think = meet the requirements.
    >      If = you
    >      = >
    >      = >      didn't see it yet, and if you'd like = to take a look, here
    >      is = the
    >      = >      URL:
    >      = >
    >      = >
    >      = http://search.ietf.org/internet-drafts/draft-= koodli-seamoby-ctv6-00.txt
    >
    >      = >
    >      = >      Regards,
    >      = >      Charlie P.
    >      = >      [Syed, Hamid = [WDLN2:AN22:EXCH]]  Thanx for your comments.
    >      = >
    >      = >      > Hamid Syed wrote:
    >      = >      >
    >      = >      > Hello CT Folks,
    >      = >      >
    >      = >      > I have submitted a framework = draft for context transfer.
    >      = I
    >      = >      would appreciate
    >      = >      > and welcome any comments on the = draft.
    >      = >      >
    >      = >      > A URL for this Internet-Draft = is:
    >      = >      >
    >      = >
    >      http://www.ietf.org/internet-drafts/draft-hamid-seamob= y-ct-fwk-00.txt
    >
    >      = >
    >      = >      >
    >      = >      > cheers
    >      = >      >
    >      = >      > -Hamid
    >      = >
    >

------_=_NextPart_001_01C0F020.C9AE58C0-- From owner-seamoby@diameter.org Fri Jun 8 10:05: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 KAA12822 for ; Fri, 8 Jun 2001 10:05:42 -0400 (EDT) Received: (qmail 6519 invoked by alias); 8 Jun 2001 13:53:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6513 invoked by uid 200); 8 Jun 2001 13:53:02 -0000 Received: (qmail 6507 invoked from network); 8 Jun 2001 13:53:01 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 13:53:01 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 10:03:13 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454FC@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'mankin@isi.edu'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Fri, 8 Jun 2001 10:03:09 -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 Hi Allison, I have a few questions > -----Original Message----- > From: Allison Mankin [mailto:mankin@isi.edu] > Sent: Friday, June 08, 2001 9:26 AM > To: Gary Kenward > Cc: 'seamoby'; pcalhoun@diameter.org; sob@harvard.edu > Subject: Re: Comments Re: [seamoby] ct problem statement > > > Security considerations in a draft express risks that a user or > operator may encounter, to help guide the decision about whether to > deploy the available technology (and also whether to deploy a > compliant > product rather than one that lacks security protections). Wouldn't this same statement apply to everything on the Internet? Why can't WGs that are not security specialists leave the security issues to the security WG? I don't understand this. Why can't all proposed standards get funnelled through the security WG before they go to RFC? I think there is lots of empire building and wheel reinventing with respect to security in the IETF at this time. Let me give a bizarre counter-example to illustrate my point. Suppose we reach the true age of wireless and almost everything is connected with wireless routers and terminals. Would we want every IETF WG draft to have sub-sections on how to deal with wirelesss? No we would hope that groups like MIP, SeaMoby, and MANET would have solved those issues for us and that those issues would be transparent to us. If the IETF were a business, it would make more economic sense to focus the experts in the security WG on the over arching security issues of the entire Internet rather than have fragmentation of implementations popping up in every WG. I guess I have a really hard time understanding the motivation behind bogging every work group down with security issues. Thanks, Phil From owner-seamoby@diameter.org Fri Jun 8 10:10: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 KAA12904 for ; Fri, 8 Jun 2001 10:10:40 -0400 (EDT) Received: (qmail 7007 invoked by alias); 8 Jun 2001 13:59:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7001 invoked by uid 200); 8 Jun 2001 13:59:21 -0000 Received: (qmail 6996 invoked by uid 500); 8 Jun 2001 13:59:20 -0000 Date: Fri, 8 Jun 2001 06:59:20 -0700 From: Pat Calhoun To: seamoby@diameter.org Subject: [seamoby] Wireless Terminology Draft Message-ID: <20010608065919.C4931@charizard.diameter.org> Mail-Followup-To: seamoby@diameter.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, Having discussed this over with our AD, the best approach would be to run the document through WG last call in the Working Groups that work in this area. All last calls would work in parallel, and the editor would have to address all comments received. The document would be informational, but recognized as having consensus. If this works with the WG, I can discuss this with other relevant WG chairs. PatC From owner-seamoby@diameter.org Fri Jun 8 10:23: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 KAA13086 for ; Fri, 8 Jun 2001 10:23:10 -0400 (EDT) Received: (qmail 7543 invoked by alias); 8 Jun 2001 14:12:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7537 invoked by uid 200); 8 Jun 2001 14:12:18 -0000 Received: (qmail 7532 invoked from network); 8 Jun 2001 14:12:16 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 14:12:16 -0000 Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f58EMBU24957; Fri, 8 Jun 2001 07:22:11 -0700 (PDT) Received: from spandex (rtp-vpn-127.cisco.com [10.82.192.127]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AIQ04559; Fri, 8 Jun 2001 07:21:47 -0700 (PDT) Message-ID: <035c01c0f026$75920060$d45904d1@cisco.com> From: "Melinda Shore" To: "Phillip Neumiller" Cc: "'seamoby'" References: <0DF9FBC42474A24CA50F7A27FB08E0484454FC@meshpdc.meshnetworks.com> Subject: Re: Comments Re: [seamoby] ct problem statement Date: Fri, 8 Jun 2001 10:22:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > I guess I have a really > hard time understanding the motivation behind bogging every work > group down with security issues. Down on the farm the policy is "when you open a gate, close it behind you." It seems to me that if you're introducing security exposures in your protocols it's your responsibility to deal with those exposures. Also, there are domain security experts who can help with specific security mechanisms or securing particular types of application security environments. "Security" by itself is probably too broad a word to be meaningful in discussing where responsibility for this stuff lies. Melinda From owner-seamoby@diameter.org Fri Jun 8 10:38: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 KAA13278 for ; Fri, 8 Jun 2001 10:38:01 -0400 (EDT) Received: (qmail 8109 invoked by alias); 8 Jun 2001 14:27:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8103 invoked by uid 200); 8 Jun 2001 14:27:03 -0000 Received: (qmail 8095 invoked from network); 8 Jun 2001 14:27:01 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 14:27:01 -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 HAA22571; Fri, 8 Jun 2001 07:36:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58EamO06964; Fri, 8 Jun 2001 07:36:48 -0700 X-mProtect: Fri, 8 Jun 2001 07:36:48 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdl8CBMQ; Fri, 08 Jun 2001 07:36:47 PDT Message-ID: <3B20E2FF.32F29794@iprg.nokia.com> Date: Fri, 08 Jun 2001 07:36:47 -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: Pat Calhoun CC: Seamless Mobility Working Group Subject: Re: [seamoby] Wireless Terminology Draft References: <20010608065919.C4931@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pat, That sounds like a good plan. What working groups will be contacted besides [manet]? Regards, Charlie P. Pat Calhoun wrote: > > All, > > Having discussed this over with our AD, the best approach would be to > run the document through WG last call in the Working Groups that work > in this area. All last calls would work in parallel, and the editor > would have to address all comments received. > > The document would be informational, but recognized as having consensus. > > If this works with the WG, I can discuss this with other relevant WG > chairs. > > PatC From owner-seamoby@diameter.org Fri Jun 8 10:42: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 KAA13366 for ; Fri, 8 Jun 2001 10:42:47 -0400 (EDT) Received: (qmail 8467 invoked by alias); 8 Jun 2001 14:29:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8459 invoked by uid 200); 8 Jun 2001 14:29:20 -0000 Received: (qmail 8450 invoked from network); 8 Jun 2001 14:29:17 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 14:29:17 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 10:39:35 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484454FE@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Melinda Shore'" , Phillip Neumiller Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Fri, 8 Jun 2001 10:39:34 -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 I like the farm thing, but.... The internet is much more like a city these days. Cities have police forces, we have the FBI, we have the national gaurd, etc. People aren't supposed to carry guns around like in the old west. I imagine that is what it was like in the early days of the Internet. Let's face it. The scale of the security problem is huge, and the IETF needs its own police force or army, if you will, to work the issues and protect the rest of us from the script kiddy weenies out there vandalizing the net. I still don't get it.... -pdn > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > > Down on the farm the policy is "when you open a gate, > close it behind you." It seems to me that if you're > introducing security exposures in your protocols it's > your responsibility to deal with those exposures. > > From owner-seamoby@diameter.org Fri Jun 8 10:46: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 KAA13440 for ; Fri, 8 Jun 2001 10:46:24 -0400 (EDT) Received: (qmail 8595 invoked by alias); 8 Jun 2001 14:30:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8587 invoked by uid 200); 8 Jun 2001 14:30:25 -0000 Received: (qmail 8574 invoked by uid 500); 8 Jun 2001 14:30:23 -0000 Date: Fri, 8 Jun 2001 07:30:23 -0700 From: Pat Calhoun To: "Charles E. Perkins" Cc: Pat Calhoun , Seamless Mobility Working Group Subject: Re: [seamoby] Wireless Terminology Draft Message-ID: <20010608073023.M4931@charizard.diameter.org> Mail-Followup-To: "Charles E. Perkins" , Pat Calhoun , Seamless Mobility Working Group References: <20010608065919.C4931@charizard.diameter.org> <3B20E2FF.32F29794@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B20E2FF.32F29794@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 08, 2001 at 07:36:47AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 08, 2001 at 07:36:47AM -0700, Charles E. Perkins wrote: > That sounds like a good plan. Good. > > What working groups will be contacted besides [manet]? I'd propose seamoby, manet, mobile-ip and (perhaps) ROHC (since their charter is very wireless centric). Any other WGs you'd like to propose? Thanks, PatC From owner-seamoby@diameter.org Fri Jun 8 10:50: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 KAA13551 for ; Fri, 8 Jun 2001 10:50:50 -0400 (EDT) Received: (qmail 9552 invoked by alias); 8 Jun 2001 14:39:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9546 invoked by uid 200); 8 Jun 2001 14:39:06 -0000 Received: (qmail 9538 invoked from network); 8 Jun 2001 14:39:03 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 14:39:03 -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 f58EmWe24592; Fri, 8 Jun 2001 17:48:32 +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, 8 Jun 2001 17:49:19 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Fri, 8 Jun 2001 17:49:19 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1079EE51A@eseis04nok> From: Kimmo.Raatikainen@nokia.com To: pcalhoun@diameter.org, charliep@IPRG.nokia.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Wireless Terminology Draft Date: Fri, 8 Jun 2001 17:49:15 +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 I think that also pilc should be included on the same reason as ROHC. - Kimmo Raatikaien > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 08. June 2001 17:30 > To: Charles E. Perkins > Cc: Pat Calhoun; Seamless Mobility Working Group > Subject: Re: [seamoby] Wireless Terminology Draft > > > On Fri, Jun 08, 2001 at 07:36:47AM -0700, Charles E. Perkins wrote: > > That sounds like a good plan. > > Good. > > > > > What working groups will be contacted besides [manet]? > > I'd propose seamoby, manet, mobile-ip and (perhaps) ROHC (since their > charter is very wireless centric). > > Any other WGs you'd like to propose? > > Thanks, > > PatC > From owner-seamoby@diameter.org Fri Jun 8 11:16: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 LAA14130 for ; Fri, 8 Jun 2001 11:16:13 -0400 (EDT) Received: (qmail 10153 invoked by alias); 8 Jun 2001 15:04:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10134 invoked by uid 200); 8 Jun 2001 15:04:19 -0000 Received: (qmail 10124 invoked from network); 8 Jun 2001 15:04:16 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 15:04:16 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA23470 for ; Fri, 8 Jun 2001 08:08:01 -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 IAA07140 for ; Fri, 8 Jun 2001 08:14:33 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 10:14:33 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C81@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'seamoby'" Cc: "'seamoby-context'" , "'Pat Calhoun'" , "'Allison Mankin'" Subject: RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 10:14:25 -0500 Sensitivity: Company-Confidential 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, This is good wording, expect the last sentence (below). However, although I think it covers a lot of things, it does it implicitly (or maybe I read it the way I like to :) ). I actually can go as far as saying that your first bullet covers the third one as well, if you want. However, since we have entered a stage of iterations of deleting and then adding text back on again. We might as well wait and see if this satisfies IESG concerns for security and if it does not, then we can be less implicit. As far as the last sentence, I agree with Henrik, I think it promises more than intended. I would say either change "must" to "may" or write it in a way that does not mean we turn seamoby into a security WG :) Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Monday, June 04, 2001 2:22 PM To: 'seamoby' Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison Mankin' Subject: [seamoby] Security Considerations - new wording Sensitivity: Confidential Below is a possible new wording for section 9 of the problem statement draft. I have *tried* to write it so that it identifies the concern over ct security, and the intent to investigate requirements, while asserting that ct will use what is available first, and only if justified, attempt to develop new security solutions. Opinions welcome - contributed text preferred, please! Gary ========================================================================= 9 Security Considerations Some of the considerations for context transfer security include: - information privacy: the context may contain information which the end user would prefer to keep hidden from unauthorized viewers. - transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving forwarding node, and therefore could potentially effect the operation of the access network itself; context transfer must only occur between forwarding nodes that have an established trust relationship. - security preservation: part of the context transfer may include information pertinent to a security association established between the mobile node and another entity on the network; for this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures. It is expected that the measures used to secure the transport of information between peers in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions. The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions. From owner-seamoby@diameter.org Fri Jun 8 12:24: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 MAA15741 for ; Fri, 8 Jun 2001 12:24:05 -0400 (EDT) Received: (qmail 11146 invoked by alias); 8 Jun 2001 16:13:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11140 invoked by uid 200); 8 Jun 2001 16:13:05 -0000 Received: (qmail 11132 invoked from network); 8 Jun 2001 16:13:03 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 16:13:03 -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 JAA08601; Fri, 8 Jun 2001 09:22:38 -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 JAA21478; Fri, 8 Jun 2001 09:21:35 -0700 (PDT) Message-Id: <200106081621.JAA21478@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 09:21:35 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] Wireless Terminology Draft To: charliep@IPRG.nokia.com, pcalhoun@diameter.org Cc: pcalhoun@diameter.org, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FJ6zyysJTTR1OPtmeo5MSg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk What about pilc? jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Fri, 8 Jun 2001 07:30:23 -0700 >From: Pat Calhoun >To: "Charles E. Perkins" >Cc: Pat Calhoun , Seamless Mobility Working Group >Subject: Re: [seamoby] Wireless Terminology Draft >Mail-Followup-To: "Charles E. Perkins" , Pat Calhoun , Seamless Mobility Working Group >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >On Fri, Jun 08, 2001 at 07:36:47AM -0700, Charles E. Perkins wrote: >> That sounds like a good plan. > >Good. > >> >> What working groups will be contacted besides [manet]? > >I'd propose seamoby, manet, mobile-ip and (perhaps) ROHC (since their >charter is very wireless centric). > >Any other WGs you'd like to propose? > >Thanks, > >PatC From owner-seamoby@diameter.org Fri Jun 8 13:09: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 NAA17198 for ; Fri, 8 Jun 2001 13:09:47 -0400 (EDT) Received: (qmail 11937 invoked by alias); 8 Jun 2001 16:50:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11931 invoked by uid 200); 8 Jun 2001 16:50:44 -0000 Received: (qmail 11921 invoked from network); 8 Jun 2001 16:50:41 -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; 8 Jun 2001 16:50:41 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f58H0EE13341 for ; Fri, 8 Jun 2001 13:00:14 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 8 Jun 2001 12:59:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 12:59:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CBD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , Madjid.Nakhjiri@motorola.com, seamoby@diameter.org Cc: seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 13:00:13 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F03C.7C3B02C0" 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_01C0F03C.7C3B02C0 Content-Type: text/plain; charset="ISO-8859-1" John: I understand your concern, and certainly this is echoed by Allison, but I hope that we don't have to perform the threat analysis for the problem statement. We don't have the protocols yet, how can we? Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, June 08, 2001 1:48 AM > To: Madjid.Nakhjiri@motorola.com; seamoby@diameter.org > Cc: seamoby-context@cdma-2000.org > Subject: [seamoby-context] RE: [seamoby] Security Considerations - new > wording > Sensitivity: Confidential > > > Hi Madjid, > > I think DoS is a bottomless pit and we can never get around > to list every > possible DoS and protection against it in such texts. > > [ ] Of course, but if CT can introduce new DOS attacks (or > novel at least) I believe the Problem Statement needs to mention > what sorts of novel DOS may occur because of CT. > > John > > ------_=_NextPart_001_01C0F03C.7C3B02C0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording

John:

  I understand your concern, and certainly this is echoed by Allison,
but I hope that we don't have to perform the threat analysis for the
problem statement. We don't have the protocols yet, how can we?

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Friday, June 08, 2001 1:48 AM
> To: Madjid.Nakhjiri@motorola.com; seamoby@diameter.org
> Cc: seamoby-context@cdma-2000.org
> Subject: [seamoby-context] RE: [seamoby] Security Considerations - new
> wording
> Sensitivity: Confidential
>
>
> Hi Madjid,
>
> I think DoS is a bottomless pit and we can never get around
> to list every
> possible DoS and protection against it in such texts.
>
> [<JAL> ] Of course, but if CT can introduce new DOS attacks (or
> novel at least) I believe the Problem Statement needs to mention
> what sorts of novel DOS may occur because of CT.
> 
> John
>
>

------_=_NextPart_001_01C0F03C.7C3B02C0-- From owner-seamoby@diameter.org Fri Jun 8 13:26: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 NAA17517 for ; Fri, 8 Jun 2001 13:26:02 -0400 (EDT) Received: (qmail 11804 invoked by alias); 8 Jun 2001 16:49:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11791 invoked by uid 200); 8 Jun 2001 16:49:06 -0000 Received: (qmail 11779 invoked from network); 8 Jun 2001 16:49:02 -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; 8 Jun 2001 16:49:02 -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 f58GwME13061; Fri, 8 Jun 2001 12:58:22 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 12:57:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 12:58:08 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CBC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'john.loughney@nokia.com'" , seamoby@diameter.org, seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 12:58:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F03C.3CAB09C0" 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_01C0F03C.3CAB09C0 Content-Type: text/plain; charset="ISO-8859-1" Sounds good Pat, I ask is the text that I posted sufficient, and if not, what change would you propose? Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 07, 2001 4:51 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com'; > seamoby@diameter.org; seamoby-context@cdma-2000.org > Subject: Re: [seamoby-context] RE: [seamoby] Security Considerations - > new wording > > > On Thu, Jun 07, 2001 at 03:35:40PM -0500, Nakhjiri > Madjid-MNAKHJI1 wrote: > > John, > > > > I agree with Gary, considering that this is only problem > statement, his > > mention of corrupted context transfer covers this. > > In requirement draft we have a requirement on mutual > authentication between > > CT peers and that should cover this. > > > > I think DoS is a bottomless pit and we can never get around > to list every > > possible DoS and protection against it in such texts. > > btw, all the IESG cares about is that we don't introduce new > DoS possibilities, > so perhaps text along these lines would be sufficient? > > PatC > > > > Regards, > > Madjid > > > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Tuesday, June 05, 2001 10:50 AM > > To: 'john.loughney@nokia.com'; seamoby@diameter.org > > Cc: seamoby-context@cdma-2000.org > > Subject: [seamoby-context] RE: [seamoby] Security > Considerations - new wording > > Sensitivity: Confidential > > > > > > > > John: > > > > Good suggestions. I was actually referring to DOS and other > > similar attacks with the euphemism "transfer legitimacy". Not > > being a security guru myself, I wasn't sure if there was an > > acceptable general term, so I created one. > > > > I was purposely trying to avoid being too specific in the problem > > statement. I worry that we could end up with a shopping list of > > potential threats. > > > > Given the direction we are going, I suspect that we will have to > > enumerate the various threats in the requirements draft anyway, as > > we are attempting to do with reliability (although, my preference > > would be to defer such a list until a proper threat analysis could > > be performed on the protocol design). Either way, the analysis will > > be done at least once, and more likely many, many times. > > > > Anyway, that was my thinking. Of course, if the dt wants, it can > > all be changed. Comments? > > > > Gary > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [ > mailto:john.loughney@nokia.com ] > > > Sent: Tuesday, June 05, 2001 6:01 AM > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com; > > > mankin@east.isi.edu > > > Subject: RE: [seamoby] Security Considerations - new wording > > > Sensitivity: Confidential > > > > > > > > > Hi Gary, > > > > > > I think that we need to cover DOS attacks here. I don't > > > think we need to go into deep detail about it, but I > > > can envision some problems with CT w.r.t. DOS attacks. > > > > > > The CT protocol itself might not assume any state, but > > > if a bad guy could send context (i.e. - state) to an AR, > > > it might be able to overrun the ARs buffers. > > > > > > Alternatively, we need to ensure a third party cannot > > > re-direct context as well. > > > > > > These two subjects could fall under the 'transfer legitimacy' > > > bullet. > > > > > > So, text might be: > > > > > > - prevention of DOS-style attacks. Context transfer > > > MUST NOT create any new opportunities for denial of > > > service (DOS) attacks. These include (but are not > > > limited to): flooding of bogus context in order > > > to overrun the capacity of the target node; and the > > > redirection of context in order to prevent the > > > successful completion of the context transfer. > > > > > > How's that? > > > > > > > > > ------_=_NextPart_001_01C0F03C.3CAB09C0 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording

Sounds good Pat, I ask is the text that I posted sufficient, and
if not, what change would you propose?

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Thursday, June 07, 2001 4:51 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> seamoby@diameter.org; seamoby-context@cdma-2000.org
> Subject: Re: [seamoby-context] RE: [seamoby] Security Considerations -
> new wording
>
>
> On Thu, Jun 07, 2001 at 03:35:40PM -0500, Nakhjiri
> Madjid-MNAKHJI1 wrote:
> > John,
> > 
> > I agree with Gary, considering that this is only problem
> statement, his
> > mention of corrupted context transfer covers this.
> > In requirement draft we have a requirement on mutual
> authentication between
> > CT peers and that should cover this.
> > 
> > I think DoS is a bottomless pit and we can never get around
> to list every
> > possible DoS and protection against it in such texts.
>
> btw, all the IESG cares about is that we don't introduce new
> DoS possibilities,
> so perhaps text along these lines would be sufficient?
>
> PatC
> > 
> > Regards,
> > Madjid
> >
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, June 05, 2001 10:50 AM
> > To: 'john.loughney@nokia.com'; seamoby@diameter.org
> > Cc: seamoby-context@cdma-2000.org
> > Subject: [seamoby-context] RE: [seamoby] Security
> Considerations - new wording
> > Sensitivity: Confidential
> >
> >
> >
> > John:
> >
> >   Good suggestions. I was actually referring to DOS and other
> > similar attacks with the euphemism "transfer legitimacy". Not
> > being a security guru myself, I wasn't sure if there was an
> > acceptable general term, so I created one.
> >
> >   I was purposely trying to avoid being too specific in the problem
> > statement. I worry that we could end up with a shopping list of
> > potential threats.
> >
> > Given the direction we are going, I suspect that we will have to
> > enumerate the various threats in the requirements draft anyway, as
> > we are attempting to do with reliability (although, my preference
> > would be to defer such a list until a proper threat analysis could
> > be performed on the protocol design). Either way, the analysis will
> > be done at least once, and more likely many, many times.
> >
> > Anyway, that was my thinking. Of course, if the dt wants, it can
> > all be changed. Comments?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: john.loughney@nokia.com [
> mailto:john.loughney@nokia.com <mailto:john.loughney@nokia.com> ]
> > > Sent: Tuesday, June 05, 2001 6:01 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@diameter.org
> > > Cc: seamoby-context@cdma-2000.org; Pat.Calhoun@eng.sun.com;
> > > mankin@east.isi.edu
> > > Subject: RE: [seamoby] Security Considerations - new wording
> > > Sensitivity: Confidential
> > >
> > >
> > > Hi Gary,
> > >
> > > I think that we need to cover DOS attacks here.  I don't
> > > think we need to go into deep detail about it, but I
> > > can envision some problems with CT w.r.t. DOS attacks.
> > >
> > > The CT protocol itself might not assume any state, but
> > > if a bad guy could send context (i.e. - state) to an AR,
> > > it might be able to overrun the ARs buffers. 
> > >
> > > Alternatively, we need to ensure a third party cannot
> > > re-direct context as well.
> > >
> > > These two subjects could fall under the 'transfer legitimacy'
> > > bullet. 
> > >
> > > So, text might be:
> > >
> > >       - prevention of DOS-style attacks.  Context transfer
> > >       MUST NOT create any new opportunities for denial of
> > >       service (DOS) attacks.  These include (but are not
> > >       limited to): flooding of bogus context in order
> > >       to overrun the capacity of the target node; and the
> > >       redirection of context in order to prevent the
> > >       successful completion of the context transfer.
> > >
> > > How's that?
> > >      
> > >
> >
>

------_=_NextPart_001_01C0F03C.3CAB09C0-- From owner-seamoby@diameter.org Fri Jun 8 13:34: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 NAA17804 for ; Fri, 8 Jun 2001 13:34:00 -0400 (EDT) Received: (qmail 13105 invoked by alias); 8 Jun 2001 17:23:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13099 invoked by uid 200); 8 Jun 2001 17:23:03 -0000 Received: (qmail 13094 invoked from network); 8 Jun 2001 17:23:01 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 17:23:01 -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 LAA00892 for ; Fri, 8 Jun 2001 11:33:19 -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 KAA24043 for ; Fri, 8 Jun 2001 10:33:19 -0700 (PDT) Message-Id: <200106081733.KAA24043@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 10:33:19 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] DMHA (aka paging) Interim Meeting in Sept.? To: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KDC/vqUaYIawAJUhBdOkDQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Hi folks, We've discussed this a couple times, but I wanted to get another sense about what the working group thinks. Basically, the idea is to have an informal "bar bof" kind of meeting at IETF 51 in London to talk about DMHA then have an interim meeting in Sept. I am willing to look into reserving a conference room on a Sun campus in Menlo Park or Santa Clara, but I need to know now so that I can get the room reserved. If the IESG approves the requirements by the interim meeting and we get any protocol proposals, we could use the interim meeting to perform a comparison of protocol proposals against requirements, with the purpose of making a recommendation about which proposal should be selected. If the IESG doesn't approve the requirements by then, or we don't get more than the one proposal we currently have, we could use the meeting to craft the beginnings of a working group draft for a protocol, based on the current candidate, for later modification as the IESG's concerns (if any) about the requirements are addressed. jak From owner-seamoby@diameter.org Fri Jun 8 14:39:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18782 for ; Fri, 8 Jun 2001 14:39:45 -0400 (EDT) Received: (qmail 13862 invoked by alias); 8 Jun 2001 18:25:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13855 invoked by uid 200); 8 Jun 2001 18:25:40 -0000 Received: (qmail 13846 invoked from network); 8 Jun 2001 18:25:37 -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; 8 Jun 2001 18:25:37 -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 f58IZEE26931 for ; Fri, 8 Jun 2001 14:35:14 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 14:34:58 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 14:35:09 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CC1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby'" Cc: "'seamoby-context'" , "'Pat Calhoun'" , "'Allison Mankin'" Subject: RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 14:35:30 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F049.CB666C60" 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_01C0F049.CB666C60 Content-Type: text/plain; charset="ISO-8859-1" Thanks Madjid. Your comment on bullet three is interesting. I was trying hard in all of this to imply that we would undertaken security solutions only if we absolutely have to. Obviously, bullet three needs to be fixed to make this more clear. I will work on it. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, June 08, 2001 11:14 AM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby' > Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison Mankin' > Subject: RE: [seamoby] Security Considerations - new wording > Sensitivity: Confidential > > > Gary, > > This is good wording, expect the last sentence (below). > However, although I think it covers a lot of things, > it does it implicitly (or maybe I read it the way I like to :) ). > I actually can go as far as saying that > your first bullet covers the third one as well, if you want. > However, since we have entered a stage of iterations of > deleting and then adding text back on again. We might as well wait > and see if this satisfies IESG concerns for security and if it > does not, then we can be less implicit. > > As far as the last sentence, I agree with Henrik, I think > it promises more than intended. I would say either change > "must" to "may" or write it in a way that does not mean > we turn seamoby into a security WG :) > > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Monday, June 04, 2001 2:22 PM > To: 'seamoby' > Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison Mankin' > Subject: [seamoby] Security Considerations - new wording > Sensitivity: Confidential > > > Below is a possible new wording for section 9 of the problem statement > draft. I have *tried* to write it so that it identifies the > concern over > ct security, and the intent to investigate requirements, > while asserting > that ct will use what is available first, and only if > justified, attempt > to develop new security solutions. > > Opinions welcome - contributed text preferred, please! > > Gary > > ============================================================== > =========== > > 9 Security Considerations > > Some of the considerations for context transfer > security include: > > - information privacy: the context may contain > information > which the end user would prefer to keep hidden from > unauthorized viewers. > > - transfer legitimacy: a false or purposely corrupted > context transfer could have a severe impact upon the > operation of the receiving forwarding node, > and therefore > could potentially effect the operation of the access > network itself; context transfer must only > occur between > forwarding nodes that have an established trust > relationship. > > - security preservation: part of the context > transfer may > include information pertinent to a security > association > established between the mobile node and > another entity on > the network; for this security association to > be preserved > during handover, the transfer of the security context > must include the appropriate security measures. > > It is expected that the measures used to secure the transport of > information between peers in an IP network should be > sufficient for > context transfer. However, given the above > considerations, there > may be reason to provide for additional security > measures beyond the > available IETF solutions. > > The context transfer investigation must identify any > novel security > measures required for context transfer that exceed the > capabilities > of the existing or emerging IETF solutions. > ------_=_NextPart_001_01C0F049.CB666C60 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Security Considerations - new wording

Thanks Madjid.

Your comment on bullet three is interesting. I was = trying hard in all of this
to imply that we would undertaken security solutions = only if we absolutely have
to. Obviously, bullet three needs to be fixed to = make this more clear. I will work
on it.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Friday, June 08, 2001 11:14 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; = 'seamoby'
> Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison = Mankin'
> Subject: RE: [seamoby] Security Considerations = - new wording
> Sensitivity: Confidential
>
>
> Gary,
>
> This is good wording, expect the last sentence = (below).
>  However, although I think it covers a lot = of things,
> it does it implicitly (or maybe I read it the = way I like to :) ).
> I actually can go as far as saying that
> your first bullet covers the third one as well, = if you want.
> However, since we have entered a stage of = iterations of
> deleting and then adding text back on again. We = might as well wait
> and see if this satisfies IESG concerns for = security and if it
> does not, then we can be less implicit.
>
> As far as the last sentence, I agree with = Henrik, I think
> it promises more than intended. I would say = either change
> "must" to "may" or write it = in a way that does not mean
> we turn seamoby into a security WG :)
>
> Madjid
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Monday, June 04, 2001 2:22 PM
> To: 'seamoby'
> Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison = Mankin'
> Subject: [seamoby] Security Considerations - = new wording
> Sensitivity: Confidential
>
>
> Below is a possible new wording for section 9 = of the problem statement
> draft. I have *tried* to write it so that it = identifies the
> concern over
> ct security, and the intent to investigate = requirements,
> while asserting
> that ct will use what is available first, and = only if
> justified, attempt
> to develop new security solutions.
>
> Opinions welcome - contributed text preferred, = please!
>
> Gary
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 9     Security = Considerations
>
>       Some of the = considerations for context transfer
> security include:
>
>       =         - information privacy: the = context may contain
> information
>       =           which the end = user would prefer to keep hidden from
>       =           unauthorized = viewers.
>
>       =         - transfer legitimacy: a = false or purposely corrupted
>       =           context transfer = could have a severe impact upon the
>       =           operation of the = receiving forwarding node,
> and therefore
>       =           could = potentially effect the operation of the access
>       =           network itself; = context transfer must only
> occur between
>       =           forwarding nodes = that have an established trust
>       =           = relationship.
>       =        
>       =         - security preservation: = part of the context
> transfer may
>       =           include = information pertinent to a security
> association
>       =           established = between the mobile node and
> another entity on
>       =           the network; for = this security association to
> be preserved
>       =           during handover, = the transfer of the security context
>       =           must include the = appropriate security measures.
>
>       It is expected = that the measures used to secure the transport of
>       information = between peers in an IP network should be
> sufficient for
>       context transfer.= However, given the above
> considerations, there
>       may be reason to = provide for additional security
> measures beyond the
>       available IETF = solutions.
>
>       The context = transfer investigation must identify any
> novel security
>       measures = required for context transfer that exceed the
> capabilities
>       of the existing = or emerging IETF solutions.
>

------_=_NextPart_001_01C0F049.CB666C60-- From owner-seamoby@diameter.org Fri Jun 8 15: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 PAA19909 for ; Fri, 8 Jun 2001 15:55:06 -0400 (EDT) Received: (qmail 14889 invoked by alias); 8 Jun 2001 19:44:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14883 invoked by uid 200); 8 Jun 2001 19:44:07 -0000 Received: (qmail 14875 invoked from network); 8 Jun 2001 19:44:05 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 19:44:05 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA03989; Fri, 8 Jun 2001 12:54:24 -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 MAA25038; Fri, 8 Jun 2001 12:54:23 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 14:54:24 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'Charles E. Perkins'" , Gary Kenward , "'mankin@isi.edu'" , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Fri, 8 Jun 2001 14:54:20 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 07, 2001 3:41 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' Subject: Re: Comments Re: [seamoby] ct problem statement On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Hi Charlie, > > Correct me if I am wrong, > I have not been very successful in finding specs that > discriminate between authentication and authorization. > So far I have only seen it in AAA Arch. > Otherwise people use authentication credentials > and authorization credentials interchangably. > > So we created a requirement that the CT peers should > mutual authenticate each other prior to CT. Do you think > a separate requirement for authorization is needed? Authentication The act of verifying the identity of an entity (subject). Authorization The act of determining whether a requesting entity (subject) will be allowed access to a resource (object). MN>> Sure. I get it, but my question is: do we have different credential for authentication and authorization today? Madjid From owner-seamoby@diameter.org Fri Jun 8 16:05: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 QAA20013 for ; Fri, 8 Jun 2001 16:05:30 -0400 (EDT) Received: (qmail 15379 invoked by alias); 8 Jun 2001 19:54:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15373 invoked by uid 200); 8 Jun 2001 19:54:31 -0000 Received: (qmail 15368 invoked from network); 8 Jun 2001 19:54:30 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 19:54:30 -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 NAA19616; Fri, 8 Jun 2001 13:04:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58K4IG05699; Fri, 8 Jun 2001 13:04:18 -0700 X-mProtect: Fri, 8 Jun 2001 13:04:18 -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 smtpdfcf7ci; Fri, 08 Jun 2001 13:04:17 PDT Message-ID: <3B212FC1.D96C2DC4@iprg.nokia.com> Date: Fri, 08 Jun 2001 13:04:17 -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: "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@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 Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > MN>> Sure. I get it, but my question is: > do we have different credential for authentication and authorization today? > > Madjid It seems to me that today we typically use authentication when we really need authorization. I guess the theory is that if you really know who is on the other side of the communiations fence, you'll be able to track them down if anything goes wrong. Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 8 16:30: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 QAA20336 for ; Fri, 8 Jun 2001 16:30:54 -0400 (EDT) Received: (qmail 15941 invoked by alias); 8 Jun 2001 20:19:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15928 invoked by uid 200); 8 Jun 2001 20:19:34 -0000 Received: (qmail 15909 invoked from network); 8 Jun 2001 20:19:30 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 20:19:30 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA05217; Fri, 8 Jun 2001 13:29:48 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA17349; Fri, 8 Jun 2001 13:29:48 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 15:29:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C91@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'Gary Kenward'" , "'john.loughney@nokia.com'" , seamoby@diameter.org, seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] RE: [seamoby] Security Considerations - new wording Date: Fri, 8 Jun 2001 15:29:46 -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 Pat, John, comments on DoS below: From Pat> btw, all the IESG cares about is that we don't introduce new DoS possibilities, so perhaps text along these lines would be sufficient? [ ] Of course, but if CT can introduce new DOS attacks (or novel at least) I believe the Problem Statement needs to mention what sorts of novel DOS may occur because of CT. MN>> I think we originally talked about mutual authentication between CT peers, and then in the interest of timeliness for security, we assumed pre-established security association between CT peers. This seemed to be viable when CT peers are ARs. Now there are a couple of issues here: 1- If we really want to have all DoS scenarios covered, we need to see whether we want to allow any other network elements besides ARs to do CT. and see whether other non-AR-AR CT scenarios exist, say in case we assume a fall back case where MN negotiates its own context with newAR exists, too many optimizations might lead to DoS, but are we considering such cases? 2-If we now say that only ARs can do CT, assuming pre-established SAs eliminates most of CT-DoS scenarios and the rest are not just specific to CT. Assume the following: (This is inspired by Melinda's farm example on close the door behind you;) If all of sudden one AR goes nuts and starts sending a lot of junk to another AR (or to many ARs) and pretending it is doing CT, then you have a problem. However, this is more of "do an authorization for each CT session and then cease the authorization afterward" problem. Not only this introduces timing issues, but also I don't see how this problem is specific to CT and not the same for Mobile IP or any other protocol. If it is really necessary, we can expand on Gary's second bullet (transfer legitimacy) to be more explicit about DoS protection. Regards, Madjid From owner-seamoby@diameter.org Fri Jun 8 16:50: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 QAA20475 for ; Fri, 8 Jun 2001 16:50:29 -0400 (EDT) Received: (qmail 16507 invoked by alias); 8 Jun 2001 20:39:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16501 invoked by uid 200); 8 Jun 2001 20:39:27 -0000 Received: (qmail 16496 invoked from network); 8 Jun 2001 20:39:26 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 20:39:26 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA14407 for ; Fri, 8 Jun 2001 13:49:44 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA20774 for ; Fri, 8 Jun 2001 13:43:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 15:49:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C92@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Fri, 8 Jun 2001 15:49:36 -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 Thanks Charlie, see below -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, June 08, 2001 3:04 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'mankin@isi.edu'; 'seamoby' Subject: Re: Comments Re: [seamoby] ct problem statement Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > MN>> Sure. I get it, but my question is: > do we have different credential for authentication and authorization today? > > Madjid It seems to me that today we typically use authentication when we really need authorization. I guess the theory is that if you really know who is on the other side of the communiations fence, you'll be able to track them down if anything goes wrong. Regards, Charlie P. ------------- That was exactly my point, today there is no difference between the credential The reason that I asked the question was your following answers to Phil: [ > Is authentication needed? Probably not. > Is authorization needed? I think this is the central requirement. ] how would we separate the two? This is actually a question that I have? (now I am contradicting myself with the DoS email that I just sent, but anyway). Sorry for getting philosophical, but that is in theory, tracking down the attacker afterward might not get the damage undone. , and the statistics (I don't remember) says that a lot of DoS and security attacks comes from inside firewalls, but I don't know how we can separate peer authentication from just in time authorization for each session without requiring registrations or introducing delays? Regards, Madjid From owner-seamoby@diameter.org Fri Jun 8 16:55: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 QAA20517 for ; Fri, 8 Jun 2001 16:55:34 -0400 (EDT) Received: (qmail 16995 invoked by alias); 8 Jun 2001 20:44:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16989 invoked by uid 200); 8 Jun 2001 20:44:36 -0000 Received: (qmail 16984 invoked from network); 8 Jun 2001 20:44:34 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 20:44:34 -0000 Received: from [206.112.123.185] ([206.112.123.185] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9430986; Fri, 08 Jun 2001 16:53:50 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <3B212FC1.D96C2DC4@iprg.nokia.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> Date: Fri, 8 Jun 2001 13:54:47 -0700 To: "Charles E. Perkins" , Nakhjiri Madjid-MNAKHJI1 From: Arthur Ross Subject: Re: Comments Re: [seamoby] ct problem statement Cc: "'mankin@isi.edu'" , "'seamoby'" Sender: owner-seamoby@diameter.org Precedence: bulk At 13:04 -0700 06/08/2001, Charles E. Perkins wrote: > >It seems to me that today we typically use authentication when >we really need authorization. I guess the theory is that if you >really know who is on the other side of the communiations fence, >you'll be able to track them down if anything goes wrong. > Close ... Arthur's [slightly cynical] definitions: Authentication = the person/thing is indeed really who they claim to be. Authorization = the bill is likely to be paid, i.e. it's ok to run up charges. Different functions, but, as several folks have said, intertwined & often treated as though they are the same thing. -- ahmr From owner-seamoby@diameter.org Fri Jun 8 19:13: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 TAA21587 for ; Fri, 8 Jun 2001 19:13:06 -0400 (EDT) Received: (qmail 18187 invoked by alias); 8 Jun 2001 23:01:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18181 invoked by uid 200); 8 Jun 2001 23:01:53 -0000 Received: (qmail 18176 invoked from network); 8 Jun 2001 23:01:52 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jun 2001 23:01:52 -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 QAA04182; Fri, 8 Jun 2001 16:11:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58NBeF13769; Fri, 8 Jun 2001 16:11:40 -0700 X-mProtect: Fri, 8 Jun 2001 16:11:40 -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 smtpd6v2Ap8; Fri, 08 Jun 2001 16:11:38 PDT Message-ID: <3B215BAB.375172EE@iprg.nokia.com> Date: Fri, 08 Jun 2001 16:11:39 -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: "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <35DBB8B7AC89D4118E98009027B1009B1B7C92@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 Madjid, I think people usually want secure authorization, and they ask for authentication because it's less abstract somehow. You and I wrote: >> Sure. I get it, but my question is: >> do we have different credential for authentication and authorization today? > > It seems to me that today we typically use authentication when > we really need authorization. I guess the theory is that if you > really know who is on the other side of the communiations fence, > you'll be able to track them down if anything goes wrong. Then you wrote: > That was exactly my point, today there is no difference between > the credential I'm not very clear on what you mean. If you mean that today people usually accept authentication credentials as good enough for authorization, then I reckon that may be true, but I am not sure why it is relevant to the discussion we were having. > The reason that I asked the question > was your following answers to Phil: > > [ > > Is authentication needed? > > Probably not. > > > Is authorization needed? > > I think this is the central requirement. > ] > > how would we separate the two? We can separate the two in a lot of ways, depending on the purpose for which authorization is needed. If you want to know that someone can pay, and the credit card company says they can pay, that is good enough. If you want assurance that someone is authorized to see your documents, you need some other sort of authorization; it still doesn't have to be done by authenticating their identity. If you have an access control list of authorized identities, then you can use authentication. It seems to me that we don't need a general authorization algorithm. We could use a general authentication algorithm, but then we have to decide whether that implicitly solves the authorization problem (whatever the latter is determined to be). I believe that we can and should separate authorization and authentication for the purpose of context transfer. All that matters is that the requester is the same node that used to own the context at the previous access router. It doesn't really matter what IP address belongs to the requester (for this purpose of authorizing a context transfer). Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 8 20:39: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 UAA22402 for ; Fri, 8 Jun 2001 20:39:43 -0400 (EDT) Received: (qmail 18987 invoked by alias); 9 Jun 2001 00:28:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18981 invoked by uid 200); 9 Jun 2001 00:28:42 -0000 Received: (qmail 18976 invoked from network); 9 Jun 2001 00:28:40 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 00:28:40 -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 f590cVU06490; Fri, 8 Jun 2001 17:38:31 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHV17966; Fri, 8 Jun 2001 17:38:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA10554; Fri, 8 Jun 2001 17:38:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.28676.72102.282920@thomasm-u1.cisco.com> Date: Fri, 8 Jun 2001 17:38:28 -0700 (PDT) To: "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement In-Reply-To: <3B212FC1.D96C2DC4@iprg.nokia.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> <3B212FC1.D96C2DC4@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > MN>> Sure. I get it, but my question is: > > do we have different credential for authentication and authorization today? > > > > Madjid > > It seems to me that today we typically use authentication when > we really need authorization. I guess the theory is that if you > really know who is on the other side of the communiations fence, > you'll be able to track them down if anything goes wrong. I really wish you'd read a book or something. The two are not comparable; you need both to make decisions, and the entities that make each decision are separable. Mike From owner-seamoby@diameter.org Fri Jun 8 20:54: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 UAA22524 for ; Fri, 8 Jun 2001 20:54:29 -0400 (EDT) Received: (qmail 19472 invoked by alias); 9 Jun 2001 00:43:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19466 invoked by uid 200); 9 Jun 2001 00:43:23 -0000 Received: (qmail 19461 invoked from network); 9 Jun 2001 00:43:22 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 00:43:22 -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 RAA10434; Fri, 8 Jun 2001 17:53:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f590rBA32527; Fri, 8 Jun 2001 17:53:11 -0700 X-mProtect: Fri, 8 Jun 2001 17:53:11 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdoY5Loh; Fri, 08 Jun 2001 17:53:09 PDT Message-ID: <3B2173A4.67963BD6@iprg.nokia.com> Date: Fri, 08 Jun 2001 17:53:56 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Nakhjiri Madjid-MNAKHJI1 , "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> <3B212FC1.D96C2DC4@iprg.nokia.com> <15137.28676.72102.282920@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Rather than slinging mud onto a well-intentioned piece of e-mail, maybe you could point out what is wrong with what I said. Maybe I read the wrong book for my information, or maybe I missed the part that would have pointed out the error in my thinking. > > It seems to me that today we typically use authentication when > > we really need authorization. I guess the theory is that if you > > really know who is on the other side of the communiations fence, > > you'll be able to track them down if anything goes wrong. > > I really wish you'd read a book or something. The two > are not comparable; you need both to make decisions, > and the entities that make each decision are separable. I'm pretty sure this is wrong, but you seem so certain of your statement that I wonder where the mismatch could be. I do not think that one always needs authentication to perform authorization, and I do not think that one always needs authorization to perform authentication. Do you have anything more that would clarify this? What was wrong with my examples? Or did you mean something else? ... Charlie P. From owner-seamoby@diameter.org Fri Jun 8 21:09: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 VAA22630 for ; Fri, 8 Jun 2001 21:09:16 -0400 (EDT) Received: (qmail 19977 invoked by alias); 9 Jun 2001 00:57:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19971 invoked by uid 200); 9 Jun 2001 00:57:53 -0000 Received: (qmail 19966 invoked from network); 9 Jun 2001 00:57:51 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 00:57:51 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f59165F24706; Fri, 8 Jun 2001 18:06:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHV18435; Fri, 8 Jun 2001 18:07:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA10565; Fri, 8 Jun 2001 18:07:37 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.30425.724237.52553@thomasm-u1.cisco.com> Date: Fri, 8 Jun 2001 18:07:37 -0700 (PDT) To: "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement In-Reply-To: <3B215BAB.375172EE@iprg.nokia.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C92@IL27EXM10.cig.mot.com> <3B215BAB.375172EE@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > I think people usually want secure authorization, and they > ask for authentication because it's less abstract somehow. Bzzt. You need authentication to know whether somebody's *impersonating* somebody who has authorization to do what the attacker wants to do. > > That was exactly my point, today there is no difference between > > the credential > > I'm not very clear on what you mean. If you mean that today people > usually accept authentication credentials as good enough for authorization, > then I reckon that may be true, but I am not sure why it is relevant > to the discussion we were having. False. On your typical OS, you log in first. That is authentication first and foremost. It may also authorize you for, say, a shell, but that's orthogonal. Other services may use your user name or UID, to determine finer grained authorization, but they all expect that the OS has provided a sufficient authentication. Indeed, if the credentials are either not sufficient, or perhaps in a different realm, it's up to the application to authenticate itself using whichever authentication methods it deems appropriate. > > how would we separate the two? > > We can separate the two in a lot of ways, depending on the > purpose for which authorization is needed. If you want to > know that someone can pay, and the credit card company says > they can pay, that is good enough. Uh, do you *really* think that credit card company doesn't attempt to authenticate you before they issue a card? All you're saying here is that you trust third party authentication (the credit card company) to make an authorization decision based on that identity (give service). > If you want assurance > that someone is authorized to see your documents, you need > some other sort of authorization; it still doesn't have to > be done by authenticating their identity. False. Only a fool would authorize something without authenticating them first. > It seems to me that we don't need a general authorization > algorithm. There is no such thing. > We could use a general authentication algorithm, > but then we have to decide whether that implicitly solves > the authorization problem (whatever the latter is determined > to be). Authentication can never solve authorization. They're apples and oranges. > I believe that we can and should separate authorization and > authentication for the purpose of context transfer. All that > matters is that the requester is the same node that used to > own the context at the previous access router. It doesn't > really matter what IP address belongs to the requester (for > this purpose of authorizing a context transfer). Pray tell, how can you tell if they are "the same node" if you don't authenticate them? Just because you claim to be the same node? Please people, I urge people who are confused to do some reading. This is really basic stuff and we're headed off into durable nonsense la-la land. Mike From owner-seamoby@diameter.org Fri Jun 8 21:14: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 VAA22693 for ; Fri, 8 Jun 2001 21:14:04 -0400 (EDT) Received: (qmail 20454 invoked by alias); 9 Jun 2001 01:03:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20449 invoked by uid 200); 9 Jun 2001 01:03:04 -0000 Received: (qmail 20444 invoked from network); 9 Jun 2001 01:02:57 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 01:02:57 -0000 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f591BgF26049; Fri, 8 Jun 2001 18:11:42 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHV18508; Fri, 8 Jun 2001 18:13:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA10576; Fri, 8 Jun 2001 18:13:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.30762.948661.105058@thomasm-u1.cisco.com> Date: Fri, 8 Jun 2001 18:13:14 -0700 (PDT) To: Charlie Perkins Cc: Michael Thomas , Nakhjiri Madjid-MNAKHJI1 , "'mankin@isi.edu'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement In-Reply-To: <3B2173A4.67963BD6@iprg.nokia.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> <3B212FC1.D96C2DC4@iprg.nokia.com> <15137.28676.72102.282920@thomasm-u1.cisco.com> <3B2173A4.67963BD6@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > Rather than slinging mud onto a well-intentioned piece of > e-mail, maybe you could point out what is wrong with > what I said. Maybe I read the wrong book for my > information, or maybe I missed the part that would have > pointed out the error in my thinking. Charlie, See my next piece of mail. You have consistantly not understood this as was abundantly evident at the last IETF about the BU problem. All you've managed to do is replace in your mind that it was really authorization instead of authentication which was the root problem, when in fact it has always been *both* which are necessary. It has never been either/or. Never. If you're going to be conversant about both this and the BU problem, you need to grasp these concepts. Mike From owner-seamoby@diameter.org Fri Jun 8 21:29: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 VAA22755 for ; Fri, 8 Jun 2001 21:29:09 -0400 (EDT) Received: (qmail 21052 invoked by alias); 9 Jun 2001 01:17:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21046 invoked by uid 200); 9 Jun 2001 01:17:33 -0000 Received: (qmail 21041 invoked from network); 9 Jun 2001 01:17:31 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 01:17:31 -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 SAA12161; Fri, 8 Jun 2001 18:27:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f591RHk26901; Fri, 8 Jun 2001 18:27:17 -0700 X-mProtect: Fri, 8 Jun 2001 18:27:17 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdV5kFfh; Fri, 08 Jun 2001 18:27:15 PDT Message-ID: <3B217BA0.8D99F0B4@iprg.nokia.com> Date: Fri, 08 Jun 2001 18:28:00 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <35DBB8B7AC89D4118E98009027B1009B1B7C92@IL27EXM10.cig.mot.com> <3B215BAB.375172EE@iprg.nokia.com> <15137.30425.724237.52553@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > Bzzt. You need authentication to know whether somebody's > *impersonating* somebody who has authorization to do > what the attacker wants to do. This is manifestly wrong, because one can carry something that gives authorization for some resource without having to be identified. > > > That was exactly my point, today there is no difference between > > > the credential > > > > I'm not very clear on what you mean. If you mean that today people > > usually accept authentication credentials as good enough for authorization, > > then I reckon that may be true, but I am not sure why it is relevant > > to the discussion we were having. > > False. On your typical OS, you log in first. That is > authentication first and foremost. ... This is a case where authentication provides sufficient authorization (according to the system design). > > > We can separate the two in a lot of ways, depending on the > > purpose for which authorization is needed. If you want to > > know that someone can pay, and the credit card company says > > they can pay, that is good enough. > > Uh, do you *really* think that credit card > company doesn't attempt to authenticate you > before they issue a card? All you're saying > here is that you trust third party authentication > (the credit card company) to make an authorization > decision based on that identity (give service). It's often enough true, however, that someone can use a credit card to get authorization for transfer of resources, without being the owner of the card. And this is often enough quite legitimate. > > If you want assurance > > that someone is authorized to see your documents, you need > > some other sort of authorization; it still doesn't have to > > be done by authenticating their identity. > > False. Only a fool would authorize something > without authenticating them first. False. I would authorize a lot of things if you give me enough money, and I wouldn't care who you are. > > It seems to me that we don't need a general authorization > > algorithm. > > There is no such thing. You seem so sure of yourself. > > We could use a general authentication algorithm, > > but then we have to decide whether that implicitly solves > > the authorization problem (whatever the latter is determined > > to be). > > Authentication can never solve authorization. They're > apples and oranges. What about your OS login example? Never say never. It depends on the system design. > > I believe that we can and should separate authorization and > > authentication for the purpose of context transfer. All that > > matters is that the requester is the same node that used to > > own the context at the previous access router. It doesn't > > really matter what IP address belongs to the requester (for > > this purpose of authorizing a context transfer). > > Pray tell, how can you tell if they are "the same node" > if you don't authenticate them? Just because you claim > to be the same node? If the node exhibits knowledge of a particular secret, I can believe they are authorized no matter who they are. > Please people, I urge people who are confused > to do some reading. This is really basic stuff > and we're headed off into durable nonsense > la-la land. It's always good to read and study and understand more. It's furthermore typically good to help others understand, given that time is available. You seem to have enough time on your hands. ... Charlie P. From owner-seamoby@diameter.org Fri Jun 8 21:58: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 VAA23862 for ; Fri, 8 Jun 2001 21:58:19 -0400 (EDT) Received: (qmail 21554 invoked by alias); 9 Jun 2001 01:46:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21548 invoked by uid 200); 9 Jun 2001 01:46:34 -0000 Received: (qmail 21543 invoked from network); 9 Jun 2001 01:46:32 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 01:46:32 -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 f591uD916188; Fri, 8 Jun 2001 18:56:13 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHV19010; Fri, 8 Jun 2001 18:56:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA10611; Fri, 8 Jun 2001 18:56:12 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.33340.630408.626330@thomasm-u1.cisco.com> Date: Fri, 8 Jun 2001 18:56:12 -0700 (PDT) To: Charlie Perkins Cc: Michael Thomas , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement In-Reply-To: <3B217BA0.8D99F0B4@iprg.nokia.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C92@IL27EXM10.cig.mot.com> <3B215BAB.375172EE@iprg.nokia.com> <15137.30425.724237.52553@thomasm-u1.cisco.com> <3B217BA0.8D99F0B4@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie, There is no point in arguing with you. I gave you the benefit of the doubt which was clearly not justified; this is security 101. There is nothing here in your rebuttal that shows that you have even elementary clues. Please take some time to educate yourself so that you can stop spewing this uneducated nonsense. As for my supposed free time, I have better uses for it. Maybe Dan Harkins would be willing to help you. Mike Charlie Perkins writes: > > > > Bzzt. You need authentication to know whether somebody's > > *impersonating* somebody who has authorization to do > > what the attacker wants to do. > > This is manifestly wrong, because one can carry something > that gives authorization for some resource without having > to be identified. > > > > > That was exactly my point, today there is no difference between > > > > the credential > > > > > > I'm not very clear on what you mean. If you mean that today people > > > usually accept authentication credentials as good enough for authorization, > > > then I reckon that may be true, but I am not sure why it is relevant > > > to the discussion we were having. > > > > False. On your typical OS, you log in first. That is > > authentication first and foremost. ... > > This is a case where authentication provides sufficient authorization > (according to the system design). > > > > > > We can separate the two in a lot of ways, depending on the > > > purpose for which authorization is needed. If you want to > > > know that someone can pay, and the credit card company says > > > they can pay, that is good enough. > > > > Uh, do you *really* think that credit card > > company doesn't attempt to authenticate you > > before they issue a card? All you're saying > > here is that you trust third party authentication > > (the credit card company) to make an authorization > > decision based on that identity (give service). > > It's often enough true, however, that someone can use a > credit card to get authorization for transfer of resources, > without being the owner of the card. And this is often > enough quite legitimate. > > > > If you want assurance > > > that someone is authorized to see your documents, you need > > > some other sort of authorization; it still doesn't have to > > > be done by authenticating their identity. > > > > False. Only a fool would authorize something > > without authenticating them first. > > False. I would authorize a lot of things if you give > me enough money, and I wouldn't care who you are. > > > > It seems to me that we don't need a general authorization > > > algorithm. > > > > There is no such thing. > > You seem so sure of yourself. > > > > We could use a general authentication algorithm, > > > but then we have to decide whether that implicitly solves > > > the authorization problem (whatever the latter is determined > > > to be). > > > > Authentication can never solve authorization. They're > > apples and oranges. > > What about your OS login example? Never say never. > It depends on the system design. > > > > I believe that we can and should separate authorization and > > > authentication for the purpose of context transfer. All that > > > matters is that the requester is the same node that used to > > > own the context at the previous access router. It doesn't > > > really matter what IP address belongs to the requester (for > > > this purpose of authorizing a context transfer). > > > > Pray tell, how can you tell if they are "the same node" > > if you don't authenticate them? Just because you claim > > to be the same node? > > If the node exhibits knowledge of a particular secret, I can > believe they are authorized no matter who they are. > > > Please people, I urge people who are confused > > to do some reading. This is really basic stuff > > and we're headed off into durable nonsense > > la-la land. > > It's always good to read and study and understand more. > It's furthermore typically good to help others understand, > given that time is available. You seem to have enough time > on your hands. > > ... > Charlie P. > > From owner-seamoby@diameter.org Sat Jun 9 02:18: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 CAA08357 for ; Sat, 9 Jun 2001 02:18:51 -0400 (EDT) Received: (qmail 22356 invoked by alias); 9 Jun 2001 06:06:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22350 invoked by uid 200); 9 Jun 2001 06:06:34 -0000 Cc: recipient list not shown: ; Received: (qmail 22345 invoked from network); 9 Jun 2001 06:06:31 -0000 Received: from unknown (HELO macgyver.howay.com.tw) (210.64.210.160) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jun 2001 06:06:31 -0000 Received: from YHQ00y08q (slip-12-64-6-171.mis.prserv.net [12.64.6.171]) by macgyver.howay.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id MQHM719B; Sat, 9 Jun 2001 12:57:48 +0800 DATE: 08 Jun 24 10:07:06 PM FROM: c6D89KAJZ@ureach.com Message-ID: Content-Type: text/html SUBJECT: (None) Sender: owner-seamoby@diameter.org Precedence: bulk Untitled Document Educate yourself about everything you ever wanted to know !!!

Individually, these products often sell for as much as $100!!!

1. Satellite TV/RCA Dish Descrambler

Our unique, complete plans for building your own home satellite TV descrambler. For access to a clear reception of pay TV signals on your home satellite dish! It does not require any additional equipment! Complete PC board template & instructions! This also includes a manual for accessing the RCA/DSS satellite dish to receive free pay channels. All the latest information for doing it right.

2. X-Ray Envelope Spray

Have you ever wanted to read the contents of an envelope without opening it? Many government and other organizations use what is known as X-Ray Envelope Spray to do this! An envelope is sprayed with this secret chemical and it becomes translucent for a short period of time, which allows the contents to be read without opening. Private supply houses sell small cans of this aerosol spray for up to $50 a can! The spray is actually a commonly available item found in major grocery and discount stores. No modification of the spray is needed, as it is ready to use as X-Ray Envelope Spray and sells for about $1.99 in retail stores!

3. How to Find Anyone and Obtain Unlisted Phone Numbers

Tired of getting the wrong number? Stop looking! We can help! We'll show you how to get the unlisted phone number of anyone. No one can hide now! Simple. Skip tracers use these tricks. We also include everything you need to know about finding missing people or loved ones from the comfort of your home. Why pay money when you can do it yourself?

4. Radar Zapper

This simply technique converts existing radar detectors into a device that will jam police radar. This device sends false readings back to the police radar! Works on virtually all detectors and easy to use!

5. Untraceable E-Mail

How to send totally anonymous and untraceable E-mail. We're not talking about those generic Yahoo! Accounts -- this is the real McCoy, anonymous email. Everything explained. Absolutely untraceable.

6. Underground Guide to Utility Meters

The illustrated guide to gas, water & electric meters! We show you in detail methods many people use to stop, slow down, even reverse all three types! This underground manual is one of our most popular items! Complete illustrated techniques and easy to do. Shows how to defeat all major brands & models of gas, water & electric meters.

7. Scan-Tron Genius

Here at last!! This very controversial report describes in detail how any student can easily defeat Scan-Tron test readers to pass a test even though he does not know the answer! This simple method will fool the scan reader into thinking you answered correctly! No tools needed. Completely tested. You won't believe how simple this method is!

8. Bad Credit Cleaning Manual

Simple ways to restore your bad credit rating to A++. Don't pay a credit counselor good money to do what you can do yourself. Many methods presented here - some legal & some "not so legal". Wipe your slate clean from your own home. Get a fresh start.

9. Pass Drug Tests

Don't use of drugs! However, many innocent people are victims of drug testing. Some over the counter medicine can trigger false results & cost you your job. Proven methods to beat drug tests. We show you how to build a simple device that can fool the best! Protect yourself & your job, even if you don't use drugs.

10.Cable TV Decoders

How to get cable TV and turn your converter box into "full service" mode. This is the latest and best way to gain access. Also, how to build your own "snooper stopper" for pennies. Prevents cable companies from spying on you.

11. Free Long Distance

You can make long distance calls to other countries at no cost! The information in these reports explains everything you need to call other countries! Country codes, city codes, overseas sender codes! Call England, Germany, the UK, practically anywhere!

12. Dissolving Checks

We show you in detail the "insufficient funds" checks scam used by people to obtain goods & cash without having any money in the account. Many people do not even use false ID's in pulling this scam off. Complete detailed instructions plus rare information on the famous "dissolving" checks. These checks "dissolve" after being chemically coated & deposited in the bank leaving no trace of the writer or account number. Not for illegal purposes. See how others do it.

13. Outsmart Lie Detector Tests

Hundreds of thousands of people in this country are wrongfully fired or not hired simply because they did not pass the lie detector test even though they've done nothing wrong! Read drugless methods to help pass whether you are lying or not! A valuable tool for any job seeker. Don't be harassed by your employer ever again. Tested and proven.

14. Lock-picks & Lock-picking.

Why buy expensive lock-picks & pay for rip-off mail order locksmith courses? We'll show you how to make your own professional lock-picks. Exact detailed drawings & construction techniques! This is perhaps the easiest to understand course ever published on this hush-hush subject. You won't believe how easy it is to make these tools! We also show you how a basic lock works & how they are picked. This publication is complete with detailed drawings & illustrations.

ALL IN ONE!!! PREVIOUSLY SOLD FOR HUNDREDS!!! ORDER NOW!!!

That's 14 products, all for just $29.95 [shipping & handling included]. CA residents please add sales tax

We accept cash, personal checks, money orders and cashiers checks. You must include a

Primary and secondary E-mail address, as we will be emailing you all the reports as soon as your payment is received.

Print the following form & mail it to:

Info 4 Edu Only

1300 N. Cahuenga Blvd # 362
Los Angeles, CA 9002

Please Print Clearly

Name: _________________________________________________

Primary Email Address: ___________________________________

Secondary Email Address: _________________________________

Make your check payable to: Info 4 Edu Only

DISCLAIMER: Please note that this information is being provided for educational purposes only. The information itself is legal, while the usage of such information may be illegal. We do not advocate unauthorized use or theft of any services. If in doubt, check your local laws and act accordingly. NOTE: All of the publications are Copyright 2001 by Info 4 Edu Only . We aggressively protect our copyrights and will seek prosecution of any website, web-master, web hosting service or anyone else that is in violation of US & International Copyright Laws.

To be removed from our future mailing please email optout7846@aol.com with the word remove in the subject line From owner-seamoby@diameter.org Sat Jun 9 21:26: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 VAA21266 for ; Sat, 9 Jun 2001 21:26:53 -0400 (EDT) Received: (qmail 24623 invoked by alias); 10 Jun 2001 01:14:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24617 invoked by uid 200); 10 Jun 2001 01:14:39 -0000 Received: (qmail 24612 invoked from network); 10 Jun 2001 01:14:37 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 01:14:37 -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 SAA19607 for ; Sat, 9 Jun 2001 18:24:21 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5A1OKx26724 for ; Sat, 9 Jun 2001 18:24:20 -0700 X-mProtect: Sat, 9 Jun 2001 18:24:20 -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 smtpdCfPdet; Sat, 09 Jun 2001 18:24:19 PDT Message-ID: <3B22CC43.B5A05C0A@iprg.nokia.com> Date: Sat, 09 Jun 2001 18:24:19 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "'seamoby'" Subject: [seamoby] Authorization vs. authentication References: <35DBB8B7AC89D4118E98009027B1009B1B7C92@IL27EXM10.cig.mot.com> <3B215BAB.375172EE@iprg.nokia.com> <15137.30425.724237.52553@thomasm-u1.cisco.com> <3B217BA0.8D99F0B4@iprg.nokia.com> <15137.33340.630408.626330@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, It seems to me that this issue is too important to leave unsettled. I didn't find anything in the books I looked at to resolve the issue, but it's true that I don't necessarily know which books are best to consult. Help will be appreciated, at least by me. If this mailing list is considered to be the wrong place for such information, let me know and I'll not post any more requests. Roughly speaking, I understand a node to be "authorized" if it has permission to do something. I understand the node to be "authenticated" if its identify has been verified. If that's wrong, then I'd like to find out why. If it's right, then I'd like to find out why my discussion in the message below should be considered uneducated, nonsensical spew. If the bottom line is that these concepts are too hard for people like me to understand, then the relevant charter items should be moved to a working group where the right kind of people are able to put in the effort to carry out the work. I find that very hard to believe, but I'm willing to be educated. Thanks for your consideration of my request. Regards, Charlie P. Michael Thomas wrote: > > Charlie, > > There is no point in arguing with you. I gave you > the benefit of the doubt which was clearly not > justified; this is security 101. There is nothing > here in your rebuttal that shows that you have > even elementary clues. Please take some time to > educate yourself so that you can stop spewing this > uneducated nonsense. As for my supposed free time, > I have better uses for it. Maybe Dan Harkins would > be willing to help you. > > Mike > > Charlie Perkins writes: >> >> >>> Bzzt. You need authentication to know whether somebody's >>> *impersonating* somebody who has authorization to do >>> what the attacker wants to do. >> >> This is manifestly wrong, because one can carry something >> that gives authorization for some resource without having >> to be identified. >> >>>>> That was exactly my point, today there is no difference between >>>>> the credential >>>> >>>> I'm not very clear on what you mean. If you mean that today people >>>> usually accept authentication credentials as good enough for authorization, >>>> then I reckon that may be true, but I am not sure why it is relevant >>>> to the discussion we were having. >>> >>> False. On your typical OS, you log in first. That is >>> authentication first and foremost. ... >> >> This is a case where authentication provides sufficient authorization >> (according to the system design). >> >>> >>>> We can separate the two in a lot of ways, depending on the >>>> purpose for which authorization is needed. If you want to >>>> know that someone can pay, and the credit card company says >>>> they can pay, that is good enough. >>> >>> Uh, do you *really* think that credit card >>> company doesn't attempt to authenticate you >>> before they issue a card? All you're saying >>> here is that you trust third party authentication >>> (the credit card company) to make an authorization >>> decision based on that identity (give service). >> >> It's often enough true, however, that someone can use a >> credit card to get authorization for transfer of resources, >> without being the owner of the card. And this is often >> enough quite legitimate. >> >>>> If you want assurance >>>> that someone is authorized to see your documents, you need >>>> some other sort of authorization; it still doesn't have to >>>> be done by authenticating their identity. >>> >>> False. Only a fool would authorize something >>> without authenticating them first. >> >> False. I would authorize a lot of things if you give >> me enough money, and I wouldn't care who you are. >> >>>> It seems to me that we don't need a general authorization >>>> algorithm. >>> >>> There is no such thing. >> >> You seem so sure of yourself. >> >>>> We could use a general authentication algorithm, >>>> but then we have to decide whether that implicitly solves >>>> the authorization problem (whatever the latter is determined >>>> to be). >>> >>> Authentication can never solve authorization. They're >>> apples and oranges. >> >> What about your OS login example? Never say never. >> It depends on the system design. >> >>>> I believe that we can and should separate authorization and >>>> authentication for the purpose of context transfer. All that >>>> matters is that the requester is the same node that used to >>>> own the context at the previous access router. It doesn't >>>> really matter what IP address belongs to the requester (for >>>> this purpose of authorizing a context transfer). >>> >>> Pray tell, how can you tell if they are "the same node" >>> if you don't authenticate them? Just because you claim >>> to be the same node? >> >> If the node exhibits knowledge of a particular secret, I can >> believe they are authorized no matter who they are. >> >>> Please people, I urge people who are confused >>> to do some reading. This is really basic stuff >>> and we're headed off into durable nonsense >>> la-la land. >> >> It's always good to read and study and understand more. >> It's furthermore typically good to help others understand, >> given that time is available. You seem to have enough time >> on your hands. >> >> ... >> Charlie P. From owner-seamoby@diameter.org Sun Jun 10 00:01: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 AAA24651 for ; Sun, 10 Jun 2001 00:00:59 -0400 (EDT) Received: (qmail 25184 invoked by alias); 10 Jun 2001 03:48:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25178 invoked by uid 200); 10 Jun 2001 03:48:38 -0000 Received: (qmail 25173 invoked from network); 10 Jun 2001 03:48:37 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 03:48:37 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sat, 9 Jun 2001 23:58:24 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD0@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Charles E. Perkins'" , "'seamoby'" Subject: RE: [seamoby] Authorization vs. authentication Date: Sat, 9 Jun 2001 23:58:24 -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 I believe it has to do with the level of permission granted and the scope of permission granted. Just becuase your identity has been authenticated does not mean that you will recieve the highest level of permission and the widest scope of permission within the network. Your scope and level of permission will be appropriate with your job function/service aggreement. For example, a node belonging to a End-User will not be authorized to do the same things as a node belonging to the network administrator (higher permission level). Also, a node belonging to the network administrator will not be able to access and control the same financial resources as a node belonging to the Chief Financial Officer (Different Scope). The scope has to be related to the area of expertise. Consider a node that has been authenticated, but has an overdue bill. Should the Cellular Operator authorize the node to use wireless services anyway? Also, consider an employee that has been authenticated as being on the payroll, but is trying to access resources on the network that the employee is not qualified to control. For example, a production worker in a factory trying to change the software of a piece of machinery. A node may only be permitted to access the network at: - a certain time, - a certain place, - and use certain resources. The fact that the node has had its identity confirmed is but a single input into the authorization decision making process. - Kulwinder. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Saturday, June 09, 2001 9:24 PM > To: 'seamoby' > Subject: [seamoby] Authorization vs. authentication > > > > Hello folks, > > It seems to me that this issue is too important to leave unsettled. > I didn't find anything in the books I looked at to resolve the > issue, but it's true that I don't necessarily know which books > are best to consult. Help will be appreciated, at least by me. > If this mailing list is considered to be the wrong place for such > information, let me know and I'll not post any more requests. > > Roughly speaking, I understand a node to be "authorized" > if it has permission to do something. I understand the node > to be "authenticated" if its identify has been verified. > If that's wrong, then I'd like to find out why. > > If it's right, then I'd like to find out why my discussion in > the message below should be considered uneducated, nonsensical > spew. > > If the bottom line is that these concepts are too hard for > people like me to understand, then the relevant charter items > should be moved to a working group where the right kind of > people are able to put in the effort to carry out the work. > I find that very hard to believe, but I'm willing to be > educated. > > Thanks for your consideration of my request. > > Regards, > Charlie P. > > > > Michael Thomas wrote: > > > > Charlie, > > > > There is no point in arguing with you. I gave you > > the benefit of the doubt which was clearly not > > justified; this is security 101. There is nothing > > here in your rebuttal that shows that you have > > even elementary clues. Please take some time to > > educate yourself so that you can stop spewing this > > uneducated nonsense. As for my supposed free time, > > I have better uses for it. Maybe Dan Harkins would > > be willing to help you. > > > > Mike > > > > Charlie Perkins writes: > >> > >> > >>> Bzzt. You need authentication to know whether somebody's > >>> *impersonating* somebody who has authorization to do > >>> what the attacker wants to do. > >> > >> This is manifestly wrong, because one can carry something > >> that gives authorization for some resource without having > >> to be identified. > >> > >>>>> That was exactly my point, today there is no difference between > >>>>> the credential > >>>> > >>>> I'm not very clear on what you mean. If you mean that > today people > >>>> usually accept authentication credentials as good enough > for authorization, > >>>> then I reckon that may be true, but I am not sure why it > is relevant > >>>> to the discussion we were having. > >>> > >>> False. On your typical OS, you log in first. That is > >>> authentication first and foremost. ... > >> > >> This is a case where authentication provides sufficient > authorization > >> (according to the system design). > >> > >>> > >>>> We can separate the two in a lot of ways, depending on the > >>>> purpose for which authorization is needed. If you want to > >>>> know that someone can pay, and the credit card company says > >>>> they can pay, that is good enough. > >>> > >>> Uh, do you *really* think that credit card > >>> company doesn't attempt to authenticate you > >>> before they issue a card? All you're saying > >>> here is that you trust third party authentication > >>> (the credit card company) to make an authorization > >>> decision based on that identity (give service). > >> > >> It's often enough true, however, that someone can use a > >> credit card to get authorization for transfer of resources, > >> without being the owner of the card. And this is often > >> enough quite legitimate. > >> > >>>> If you want assurance > >>>> that someone is authorized to see your documents, you need > >>>> some other sort of authorization; it still doesn't have to > >>>> be done by authenticating their identity. > >>> > >>> False. Only a fool would authorize something > >>> without authenticating them first. > >> > >> False. I would authorize a lot of things if you give > >> me enough money, and I wouldn't care who you are. > >> > >>>> It seems to me that we don't need a general authorization > >>>> algorithm. > >>> > >>> There is no such thing. > >> > >> You seem so sure of yourself. > >> > >>>> We could use a general authentication algorithm, > >>>> but then we have to decide whether that implicitly solves > >>>> the authorization problem (whatever the latter is determined > >>>> to be). > >>> > >>> Authentication can never solve authorization. They're > >>> apples and oranges. > >> > >> What about your OS login example? Never say never. > >> It depends on the system design. > >> > >>>> I believe that we can and should separate authorization and > >>>> authentication for the purpose of context transfer. All that > >>>> matters is that the requester is the same node that used to > >>>> own the context at the previous access router. It doesn't > >>>> really matter what IP address belongs to the requester (for > >>>> this purpose of authorizing a context transfer). > >>> > >>> Pray tell, how can you tell if they are "the same node" > >>> if you don't authenticate them? Just because you claim > >>> to be the same node? > >> > >> If the node exhibits knowledge of a particular secret, I can > >> believe they are authorized no matter who they are. > >> > >>> Please people, I urge people who are confused > >>> to do some reading. This is really basic stuff > >>> and we're headed off into durable nonsense > >>> la-la land. > >> > >> It's always good to read and study and understand more. > >> It's furthermore typically good to help others understand, > >> given that time is available. You seem to have enough time > >> on your hands. > >> > >> ... > >> Charlie P. > From owner-seamoby@diameter.org Sun Jun 10 03:34: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 DAA02478 for ; Sun, 10 Jun 2001 03:34:44 -0400 (EDT) Received: (qmail 25840 invoked by alias); 10 Jun 2001 07:23:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25834 invoked by uid 200); 10 Jun 2001 07:23:20 -0000 Received: (qmail 25826 invoked from network); 10 Jun 2001 07:23:19 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 07:23:19 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Jun 2001 03:33:12 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Charles E. Perkins'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Sun, 10 Jun 2001 03:33:11 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, June 08, 2001 3:54 PM > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 07, 2001 3:41 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri > Madjid-MNAKHJI1 wrote: > > Hi Charlie, > > > > Correct me if I am wrong, > > I have not been very successful in finding specs that > > discriminate between authentication and authorization. > > So far I have only seen it in AAA Arch. > > Otherwise people use authentication credentials > > and authorization credentials interchangably. > > > > So we created a requirement that the CT peers should > > mutual authenticate each other prior to CT. Do you think > > a separate requirement for authorization is needed? > > > Authentication > The act of verifying the identity of an entity (subject). > > Authorization > The act of determining whether a requesting entity > (subject) will > be allowed access to a resource (object). > Hello Kulwinder Thanks for the answer. It conforms exactly with my previous understanding. If you want to quote this message and answer to the mailing list, that would be fine with me, but I didn't see a reason to send my request for clarification to the mailing list. Regards, Charlie P. > MN>> Sure. I get it, but my question is: > do we have different credential for authentication and > authorization today? I believe the confusion was started by this statement. Some definitions: 1. Credential: A certificate (Indentification Card, Digital Signature) issued by a trusted third party. 2. Authentication: The act of verifying the indentity of an entity by checking for a valid credential. 3. Authorization: The act of determining whether a requesting entity will be allowed access to a resource which may depend on several inputs of which authentication one such input. (others: job function/service aggreement) Consider the following process: 1. Present Credential to Security Authority. 2. Authenticated? Yes. 3. Authorized? Yes. 4. Grant Access. Or, 1. Present Credential to Security Authority. 2. Authenticated? No. 3. Deny Access. The Authorization step is moot after failing the Authentication step. Therefore, the term "Authorization Credential" has no value, since the credential is never presented to the authorization process, but to the authentication process. Without Authentication there can be no Authorization. Present Credential -> Authenticate -> Authorize -> Grant Access. Read the first few lines of: http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 Infact, the term "credential" stands on its own to convey the correct meaning. It does not need adjectives like authentication, security, or authorization. - Kulwinder. > > Madjid > From owner-seamoby@diameter.org Sun Jun 10 05:09: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 FAA08500 for ; Sun, 10 Jun 2001 05:09:30 -0400 (EDT) Received: (qmail 26358 invoked by alias); 10 Jun 2001 08:53:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26352 invoked by uid 200); 10 Jun 2001 08:53:37 -0000 Received: (qmail 26347 invoked from network); 10 Jun 2001 08:53:36 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 08:53:36 -0000 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5A93M922196; Sun, 10 Jun 2001 02:03:22 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5A93OH02773; Sun, 10 Jun 2001 02:03:24 -0700 (PDT) Received: from pyegani-w2k.cisco.com ([10.19.162.132]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA26431; Sun, 10 Jun 2001 02:03:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20010610013743.00baaeb0@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Jun 2001 02:06:17 -0700 To: Kulwinder Atwal From: Parviz Yegani Subject: RE: [seamoby] Authorization vs. authentication Cc: "'Charles E. Perkins'" , "'seamoby'" In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD0@NEPTUNE.zucotto.com > Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_187701961==_.ALT" Sender: owner-seamoby@diameter.org Precedence: bulk --=====================_187701961==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree . In cellular, for example, authentication and authorization are not= the same.=20 Authentication is the process by which information is exchanged between a=20 mobile station and base station for the purpose of confirming the identity= of the=20 mobile station. A successful outcome of the authentication process occurs= =20 only when it can be demonstrated that the mobile station and base station=20 possess identical sets of shared secret data. Authorization, however, is an action to make a service available to a= subscriber.=20 The provision may be: =95 general: where the service is made available to all subscribers (subject= to compatibility restrictions enforced) without prior arrangements being made= with the service provider. =95 pre-arranged: where the service is made available to an individual= subscriber only after the necessary arrangements have been made with the service= provider. Hope this would help the group settle the issue as quickly as possible. No= more flames please! Thanks, Parviz At 11:58 PM 6/9/2001 -0400, Kulwinder Atwal wrote: >I believe it has to do with the level of permission granted and the scope= of >permission granted. > >Just becuase your identity has been authenticated does not mean that you >will recieve the highest level of permission and the widest scope of >permission within the network. Your scope and level of permission will be >appropriate with your job function/service aggreement. > >For example, a node belonging to a End-User will not be authorized to do= the >same things as a node belonging to the network administrator (higher >permission level). > >Also, a node belonging to the network administrator will not be able to >access and control the same financial resources as a node belonging to the >Chief Financial Officer (Different Scope). The scope has to be related to >the area of expertise. > >Consider a node that has been authenticated, but has an overdue bill. >Should the Cellular Operator authorize the node to use wireless services >anyway? > >Also, consider an employee that has been authenticated as being on the >payroll, but is trying to access resources on the network that the employee >is not qualified to control. For example, a production worker in a factory >trying to change the software of a piece of machinery. > >A node may only be permitted to access the network at: > >- a certain time,=20 >- a certain place,=20 >- and use certain resources.=20 > >The fact that the node has had its identity confirmed is but a single input >into the authorization decision making process. =20 > >- Kulwinder. > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] >> Sent: Saturday, June 09, 2001 9:24 PM >> To: 'seamoby' >> Subject: [seamoby] Authorization vs. authentication >>=20 >>=20 >>=20 >> Hello folks, >>=20 >> It seems to me that this issue is too important to leave unsettled. >> I didn't find anything in the books I looked at to resolve the >> issue, but it's true that I don't necessarily know which books >> are best to consult. Help will be appreciated, at least by me. >> If this mailing list is considered to be the wrong place for such >> information, let me know and I'll not post any more requests. >>=20 >> Roughly speaking, I understand a node to be "authorized" >> if it has permission to do something. I understand the node >> to be "authenticated" if its identify has been verified. >> If that's wrong, then I'd like to find out why. >>=20 >> If it's right, then I'd like to find out why my discussion in >> the message below should be considered uneducated, nonsensical >> spew. >>=20 >> If the bottom line is that these concepts are too hard for >> people like me to understand, then the relevant charter items >> should be moved to a working group where the right kind of >> people are able to put in the effort to carry out the work. >> I find that very hard to believe, but I'm willing to be >> educated. >>=20 >> Thanks for your consideration of my request. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>=20 >> Michael Thomas wrote: >> >=20 >> > Charlie, >> >=20 >> > There is no point in arguing with you. I gave you >> > the benefit of the doubt which was clearly not >> > justified; this is security 101. There is nothing >> > here in your rebuttal that shows that you have >> > even elementary clues. Please take some time to >> > educate yourself so that you can stop spewing this >> > uneducated nonsense. As for my supposed free time, >> > I have better uses for it. Maybe Dan Harkins would >> > be willing to help you. >> >=20 >> > Mike >> >=20 >> > Charlie Perkins writes: >> >> >> >> >> >>> Bzzt. You need authentication to know whether somebody's >> >>> *impersonating* somebody who has authorization to do >> >>> what the attacker wants to do. >> >> >> >> This is manifestly wrong, because one can carry something >> >> that gives authorization for some resource without having >> >> to be identified. >> >> >> >>>>> That was exactly my point, today there is no difference between >> >>>>> the credential >> >>>> >> >>>> I'm not very clear on what you mean. If you mean that=20 >> today people >> >>>> usually accept authentication credentials as good enough=20 >> for authorization, >> >>>> then I reckon that may be true, but I am not sure why it=20 >> is relevant >> >>>> to the discussion we were having. >> >>> >> >>> False. On your typical OS, you log in first. That is >> >>> authentication first and foremost. ... >> >> >> >> This is a case where authentication provides sufficient=20 >> authorization >> >> (according to the system design). >> >> >> >>> >> >>>> We can separate the two in a lot of ways, depending on the >> >>>> purpose for which authorization is needed. If you want to >> >>>> know that someone can pay, and the credit card company says >> >>>> they can pay, that is good enough. >> >>> >> >>> Uh, do you *really* think that credit card >> >>> company doesn't attempt to authenticate you >> >>> before they issue a card? All you're saying >> >>> here is that you trust third party authentication >> >>> (the credit card company) to make an authorization >> >>> decision based on that identity (give service). >> >> >> >> It's often enough true, however, that someone can use a >> >> credit card to get authorization for transfer of resources, >> >> without being the owner of the card. And this is often >> >> enough quite legitimate. >> >> >> >>>> If you want assurance >> >>>> that someone is authorized to see your documents, you need >> >>>> some other sort of authorization; it still doesn't have to >> >>>> be done by authenticating their identity. >> >>> >> >>> False. Only a fool would authorize something >> >>> without authenticating them first. >> >> >> >> False. I would authorize a lot of things if you give >> >> me enough money, and I wouldn't care who you are. >> >> >> >>>> It seems to me that we don't need a general authorization >> >>>> algorithm. >> >>> >> >>> There is no such thing. >> >> >> >> You seem so sure of yourself. >> >> >> >>>> We could use a general authentication algorithm, >> >>>> but then we have to decide whether that implicitly solves >> >>>> the authorization problem (whatever the latter is determined >> >>>> to be). >> >>> >> >>> Authentication can never solve authorization. They're >> >>> apples and oranges. >> >> >> >> What about your OS login example? Never say never. >> >> It depends on the system design. >> >> >> >>>> I believe that we can and should separate authorization and >> >>>> authentication for the purpose of context transfer. All that >> >>>> matters is that the requester is the same node that used to >> >>>> own the context at the previous access router. It doesn't >> >>>> really matter what IP address belongs to the requester (for >> >>>> this purpose of authorizing a context transfer). >> >>> >> >>> Pray tell, how can you tell if they are "the same node" >> >>> if you don't authenticate them? Just because you claim >> >>> to be the same node? >> >> >> >> If the node exhibits knowledge of a particular secret, I can >> >> believe they are authorized no matter who they are. >> >> >> >>> Please people, I urge people who are confused >> >>> to do some reading. This is really basic stuff >> >>> and we're headed off into durable nonsense >> >>> la-la land. >> >> >> >> It's always good to read and study and understand more. >> >> It's furthermore typically good to help others understand, >> >> given that time is available. You seem to have enough time >> >> on your hands. >> >> >> >> ... >> >> Charlie P. >>=20 --=====================_187701961==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree . In cellular, for example, authentication and authorization are not the same.
Authentication is the process by which information is exchanged between a
mobile station and base station for the purpose of confirming the identity of the
mobile station.  A successful outcome of the authentication process occurs
only when it can be demonstrated that the mobile station and base station
possess identical sets of shared secret data.

Authorization, however, is an action to make a service available to a subscriber.
The provision may be:
=95 general: where the service is made available to all subscribers (subject to
compatibility restrictions enforced) without prior arrangements being made with
the service provider.
=95 pre-arranged: where the service is made available to an individual subscriber
only after the necessary arrangements have been made with the service provider.

Hope this would help the group settle the issue as quickly as possible. No more
flames please!

Thanks,
Parviz


At 11:58 PM 6/9/2001 -0400, Kulwinder Atwal wrote:
I believe it has to do with the level of permission granted and the scope of
permission granted.

Just becuase your identity has been authenticated does not mean that you
will recieve the highest level of permission and the widest scope=20 of
permission within the network.  Your scope and level of permission will be
appropriate with your job function/service aggreement.

For example, a node belonging to a End-User will not be authorized to do the
same things as a node belonging to the network administrator=20 (higher
permission level).

Also, a node belonging to the network administrator will not be able to
access and control the same financial resources as a node belonging to the
Chief Financial Officer (Different Scope).  The scope has to be related to
the area of expertise.

Consider a node that has been authenticated, but has an overdue bill.
Should the Cellular Operator authorize the node to use wireless services
anyway?

Also, consider an employee that has been authenticated as being on the
payroll, but is trying to access resources on the network that the employee
is not qualified to control.  For example, a production worker in a factory
trying to change the software of a piece of machinery.

A node may only be permitted to access the network at:

- a certain time,
- a certain place,
- and use certain resources.

The fact that the node has had its identity confirmed is but a single input
into the authorization decision making process.  

- Kulwinder.

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Saturday, June 09, 2001 9:24 PM
> To: 'seamoby'
> Subject: [seamoby] Authorization vs. authentication
>
>
>
> Hello folks,
>
> It seems to me that this issue is too important to leave unsettled.
> I didn't find anything in the books I looked at to resolve the
> issue, but it's true that I don't necessarily know which books
> are best to consult.  Help will be appreciated, at least by me.
> If this mailing list is considered to be the wrong place for such
> information, let me know and I'll not post any more requests.
>
> Roughly speaking, I understand a node to be "authorized"
> if it has permission to do something.  I understand the node
> to be "authenticated" if its identify has been verified.
> If that's wrong, then I'd like to find out why.
>
> If it's right, then I'd like to find out why my discussion in
> the message below should be considered uneducated, nonsensical
> spew.
>
> If the bottom line is that these concepts are too hard for
> people like me to understand, then the relevant charter items
> should be moved to a working group where the right kind of
> people are able to put in the effort to carry out the work.
> I find that very hard to believe, but I'm willing to be
> educated.
>
> Thanks for your consideration of my request.
>
> Regards,
> Charlie P.
>
>
>
> Michael Thomas wrote:
> >
> > Charlie,
> >
> > There is no point in arguing with you. I gave you
> > the benefit of the doubt which was clearly not
> > justified; this is security 101. There is nothing
> > here in your rebuttal that shows that you have
> > even elementary clues. Please take some time to
> > educate yourself so that you can stop spewing this
> > uneducated nonsense. As for my supposed free time,
> > I have better uses for it. Maybe Dan Harkins would
> > be willing to help you.
> >
> >            =   Mike
> >
> > Charlie Perkins writes:
> >>
> >>
> >>>    Bzzt. You need authentication to know whether somebody's
> >>>    *impersonating* somebody who has authorization to do
> >>>    what the attacker wants to do.
> >>
> >> This is manifestly wrong, because one can carry something
> >> that gives authorization for some resource without having
> >> to be identified.
> >>
> >>>>> That was exactly my point, today there is no difference between
> >>>>> the credential
> >>>>
> >>>> I'm not very clear on what you mean.  If you mean that
> today people
> >>>> usually accept authentication credentials as good enough
> for authorization,
> >>>> then I reckon that may be true, but I am not sure why it
> is relevant
> >>>> to the discussion we were having.
> >>>
> >>>    False. On your typical OS, you log in first. That is
> >>>    authentication first and foremost.   ...
> >>
> >> This is a case where authentication provides sufficient
> authorization
> >> (according to the system design).
> >>
> >>>
> >>>> We can separate the two in a lot of ways, depending on the
> >>>> purpose for which authorization is needed.  If you want to
> >>>> know that someone can pay, and the credit card company says
> >>>> they can pay, that is good enough.
> >>>
> >>>    Uh, do you *really* think that credit card
> >>>    company doesn't attempt to authenticate you
> >>>    before they issue a card? All you're saying
> >>>    here is that you trust third party authentication
> >>>    (the credit card company) to make an authorization
> >>>    decision based on that identity (give service).
> >>
> >> It's often enough true, however, that someone can use a
> >> credit card to get authorization for transfer of resources,
> >> without being the owner of the card.  And this is often
> >> enough quite legitimate.
> >>
> >>>> If you want assurance
> >>>> that someone is authorized to see your documents, you need
> >>>> some other sort of authorization; it still doesn't have to
> >>>> be done by authenticating their identity.
> >>>
> >>>    False. Only a fool would authorize something
> >>>    without authenticating them first.
> >>
> >> False.  I would authorize a lot of things if you give
> >> me enough money, and I wouldn't care who you are.
> >>
> >>>> It seems to me that we don't need a general authorization
> >>>> algorithm.
> >>>
> >>>    There is no such thing.
> >>
> >> You seem so sure of yourself.
> >>
> >>>> We could use a general authentication algorithm,
> >>>> but then we have to decide whether that implicitly solves
> >>>> the authorization problem (whatever the latter is determined
> >>>> to be).
> >>>
> >>>    Authentication can never solve authorization. They're
> >>>    apples and oranges.
> >>
> >> What about your OS login example?  Never say never.
> >> It depends on the system design.
> >>
> >>>> I believe that we can and should separate authorization and
> >>>> authentication for the purpose of context transfer.  All that
> >>>> matters is that the requester is the same node that used to
> >>>> own the context at the previous access router.  It doesn't
> >>>> really matter what IP address belongs to the requester (for
> >>>> this purpose of authorizing a context transfer).
> >>>
> >>>    Pray tell, how can you tell if they are "the same node"
> >>>    if you don't authenticate them? Just because you claim
> >>>    to be the same node?
> >>
> >> If the node exhibits knowledge of a particular secret, I can
> >> believe they are authorized no matter who they are.
> >>
> >>>    Please people, I urge people who are confused
> >>>    to do some reading. This is really basic stuff
> >>>    and we're headed off into durable nonsense
> >>>    la-la land.
> >>
> >> It's always good to read and study and understand more.
> >> It's furthermore typically good to help others understand,
> >> given that time is available.  You seem to have enough time
> >> on your hands.
> >>
> >> ...
> >> Charlie P.
>
--=====================_187701961==_.ALT-- From owner-seamoby@diameter.org Sun Jun 10 07:26: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 HAA09563 for ; Sun, 10 Jun 2001 07:26:27 -0400 (EDT) Received: (qmail 27117 invoked by alias); 10 Jun 2001 11:15:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27111 invoked by uid 200); 10 Jun 2001 11:15:26 -0000 Received: (qmail 27106 invoked from network); 10 Jun 2001 11:15:23 -0000 Received: from scaup.mail.pas.earthlink.net (207.217.121.49) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 11:15:23 -0000 Received: from earthlink.net (ip245.winterpark.fl.pub-ip.psi.net [38.11.233.245]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id EAA15949 for ; Sun, 10 Jun 2001 04:25:45 -0700 (PDT) Message-ID: <3B235883.B95A9B01@earthlink.net> Date: Sun, 10 Jun 2001 06:22:43 -0500 From: "Phillip D. Neumiller" X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@diameter.org Subject: Re: [seamoby] Authorization vs. authentication Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit I prefer not to alter the English language. If one just uses the English definition, authentication tells me undeniably who somebody is, and authorization gives the somebody the right to act. So authentication is something you would normally do before authorization according to the Queen's English. The Queen tells the gaurds in her garrison to authenticate the identify of would-be visitors before authorizing them passage to her throne room. au·then·ti·cate (ô-thnt-kt) tr.v. au·then·ti·cat·ed, au·then·ti·cat·ing, au·then·ti·cates To establish the authenticity of; prove genuine: a specialist who authenticated the antique samovar. Synonyms: confirm, corroborate, substantiate, authenticate, validate, verify These verbs mean to affirm the truth, accuracy, or genuineness of something. Confirm implies removal of all doubt: "We must never make experiments to confirm our ideas, but simply to control them" (Claude Bernard). Corroborate refers to supporting something by means of strengthening evidence: The witness is expected to corroborate the plaintiff's testimony. To substantiate is to establish by presenting substantial or tangible evidence: "one of the most fully substantiated of historical facts" (James Harvey Robinson). Authenticate implies the establishment of genuineness of something by the testimony of an expert: Never purchase an antique before it has been authenticated. Validate refers to establishing the validity of something, such as a theory, claim, or judgment: The divorce validated my parents' original objection to the marriage. Verify implies proving by comparison with an original or with established fact: The bank refused to cash the check until the signature was verified. au·thor·ize (ôth-rz) tr.v. au·thor·ized, au·thor·iz·ing, au·thor·iz·es 1.To grant authority or power to. 2.To give permission for; sanction: the city agency that authorizes construction projects. 3.To be sufficient grounds for; justify. Synonyms: authorize, accredit, commission, empower, license These verbs mean to give someone the authority to act: authorized her partner to negotiate on her behalf; a representative who was accredited by his government; commissioned the real-estate agent to purchase the house; was empowered to make decisions during the president's absence; a pharmacist licensed to practice in two states. Tally ho, Phil From owner-seamoby@diameter.org Sun Jun 10 10:22:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11136 for ; Sun, 10 Jun 2001 10:22:38 -0400 (EDT) Received: (qmail 573 invoked by alias); 10 Jun 2001 14:04:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 566 invoked by uid 200); 10 Jun 2001 14:04:53 -0000 Received: (qmail 551 invoked from network); 10 Jun 2001 14:04:46 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 14:04:46 -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 HAA08275; Sun, 10 Jun 2001 07:14:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5AEEaA25249; Sun, 10 Jun 2001 07:14:36 -0700 X-mProtect: Sun, 10 Jun 2001 07:14:36 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdJo3yRf; Sun, 10 Jun 2001 07:14:33 PDT Message-ID: <3B2380F9.F2AA55E9@iprg.nokia.com> Date: Sun, 10 Jun 2001 07:15:21 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@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 Hello Kulwinder, I'm still trying to identify the problem that prevented me from satisfying 's "security 101" criterion. Thanks for your comments. I have a couple of follow-on questions. Isn't it possible to have authorization without authentication? In other words, isn't it possible to grant authorization based on verification of some credential that doesn't provide any assurance of identity? Currency comes to mind, and then electronic cash, but other credentials are possible and relevant to the discussion. I realize that such things begin to blur the line between a credential and a tradable resource. As you have pointed out, relying on credential verification itself begins to blur the line between authentication and authorization. Maybe an example would help. Suppose I put something in a treasure chest, which cannot be opened except with a key I happen to have. Then I give you the key and tell you how to use it to open the treasure chest. Doesn't your possession of that key mean that you have authorization to open the treasure chest? Surely, the treasure chest isn't going to care about your identity. To me, this means that authorization does not require authentication. It should be clear how to map this example into the [seamoby] realm of authorizing access to transferable context information, and very relevant to the eventual discussion we should be having. Regards, Charlie P. Kulwinder Atwal wrote: > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Friday, June 08, 2001 3:54 PM > > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 07, 2001 3:41 PM > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > > > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri > > Madjid-MNAKHJI1 wrote: > > > Hi Charlie, > > > > > > Correct me if I am wrong, > > > I have not been very successful in finding specs that > > > discriminate between authentication and authorization. > > > So far I have only seen it in AAA Arch. > > > Otherwise people use authentication credentials > > > and authorization credentials interchangably. > > > > > > So we created a requirement that the CT peers should > > > mutual authenticate each other prior to CT. Do you think > > > a separate requirement for authorization is needed? > > > > > > Authentication > > The act of verifying the identity of an entity (subject). > > > > Authorization > > The act of determining whether a requesting entity > > (subject) will > > be allowed access to a resource (object). > > > > Hello Kulwinder > > Thanks for the answer. It conforms exactly with my previous understanding. > > If you want to quote this message and answer to the mailing list, that > would be fine with me, but I didn't see a reason to send my request > for clarification to the mailing list. > > Regards, > Charlie P. > > > MN>> Sure. I get it, but my question is: > > do we have different credential for authentication and > > authorization today? > > I believe the confusion was started by this statement. > > Some definitions: > > 1. Credential: A certificate (Indentification Card, Digital Signature) > issued by a trusted third party. > > 2. Authentication: The act of verifying the indentity of an entity by > checking for a valid credential. > > 3. Authorization: The act of determining whether a requesting entity will be > allowed access to a resource which may depend on several inputs of which > authentication one such input. (others: job function/service aggreement) > > Consider the following process: > > 1. Present Credential to Security Authority. > 2. Authenticated? Yes. > 3. Authorized? Yes. > 4. Grant Access. > > Or, > > 1. Present Credential to Security Authority. > 2. Authenticated? No. > 3. Deny Access. > > The Authorization step is moot after failing the Authentication step. > Therefore, the term "Authorization Credential" has no value, since the > credential is never presented to the authorization process, but to the > authentication process. Without Authentication there can be no > Authorization. > > Present Credential -> Authenticate -> Authorize -> Grant Access. > > Read the first few lines of: > http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 > > Infact, the term "credential" stands on its own to convey the correct > meaning. It does not need adjectives like authentication, security, or > authorization. > > - Kulwinder. > > > > > Madjid > > From owner-seamoby@diameter.org Sun Jun 10 10:39:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11222 for ; Sun, 10 Jun 2001 10:39:43 -0400 (EDT) Received: (qmail 479 invoked by alias); 10 Jun 2001 14:04:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 472 invoked by uid 200); 10 Jun 2001 14:04:03 -0000 Received: (qmail 466 invoked from network); 10 Jun 2001 14:04:01 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 14:04:01 -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 f5AEDxU00111; Sun, 10 Jun 2001 07:13:59 -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 AHV23725; Sun, 10 Jun 2001 07:13:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11198; Sun, 10 Jun 2001 07:13:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15139.32930.576097.145900@thomasm-u1.cisco.com> Date: Sun, 10 Jun 2001 07:13:54 -0700 (PDT) To: Kulwinder Atwal Cc: "'Charles E. Perkins'" , "'seamoby'" Subject: RE: [seamoby] Authorization vs. authentication In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD0@NEPTUNE.zucotto.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD0@NEPTUNE.zucotto.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 Exactly. Something to note is that authentication doesn't imply cryptographic authentication or even strong authentication. It's just the process of identifying an entity using some methodology, including sticking a key into a lock and having the tumblers line up (shared secret), looking across the counter to visually cross check a license (third party through DMV), searching a finger print database for a match from a crime scene (third party through cops), accepting your mother's birth name and your social security number to issue a credit card (very weak form of shared secret), public key digital signatures verified through a private database of public keys (strong, quasi shared secret) or digital signatures over X.509 certificates (strong, third party). None of these has the least bit to do with authorization, and in fact just because you can be authenticated in one realm implies that you should be _authorized_ in another realm. For example, I have a shared secret between my key and my door lock. Presentation of that key to a bank teller to, oh say, get $18,000,000 is not going to be authorized because of an authentication failure. The reason is not because the key was bogus or anything like that, it's because the realm I was trying to authenticate myself in does not have any trust relationship with the door lock's realm. Note also that the ultimate authorization of my $18,000,000 is by no means guaranteed even if I do manage to properly authenticate in the bank's realm: I need to have access via funds or credit to that money. Notice that authorization checks are necessarily a two step process: determine the identity of the requestor within the realm, and then determine whether the request from that identity is allowable within the realm. Note also that this has nothing to do with unique identites either. In the case of my door lock, I may give that shared secret to any number of humans I see fit, which for the purposes of authentication within my door lock's realm are equivalent. To conclude this analogy, notice that mere insertion of the key into my lock is not in and of itself authorization; it is merely a potential. If I were to throw a deadbolt or somehow override the default authorization of allowing the bolt to be retracted, the key would have authenticated itself successfully to the lock, but it still wouldn't have gained the necessary authorization to pass. Mike Kulwinder Atwal writes: > I believe it has to do with the level of permission granted and the scope of > permission granted. > > Just becuase your identity has been authenticated does not mean that you > will recieve the highest level of permission and the widest scope of > permission within the network. Your scope and level of permission will be > appropriate with your job function/service aggreement. > > For example, a node belonging to a End-User will not be authorized to do the > same things as a node belonging to the network administrator (higher > permission level). > > Also, a node belonging to the network administrator will not be able to > access and control the same financial resources as a node belonging to the > Chief Financial Officer (Different Scope). The scope has to be related to > the area of expertise. > > Consider a node that has been authenticated, but has an overdue bill. > Should the Cellular Operator authorize the node to use wireless services > anyway? > > Also, consider an employee that has been authenticated as being on the > payroll, but is trying to access resources on the network that the employee > is not qualified to control. For example, a production worker in a factory > trying to change the software of a piece of machinery. > > A node may only be permitted to access the network at: > > - a certain time, > - a certain place, > - and use certain resources. > > The fact that the node has had its identity confirmed is but a single input > into the authorization decision making process. > > - Kulwinder. > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > > Sent: Saturday, June 09, 2001 9:24 PM > > To: 'seamoby' > > Subject: [seamoby] Authorization vs. authentication > > > > > > > > Hello folks, > > > > It seems to me that this issue is too important to leave unsettled. > > I didn't find anything in the books I looked at to resolve the > > issue, but it's true that I don't necessarily know which books > > are best to consult. Help will be appreciated, at least by me. > > If this mailing list is considered to be the wrong place for such > > information, let me know and I'll not post any more requests. > > > > Roughly speaking, I understand a node to be "authorized" > > if it has permission to do something. I understand the node > > to be "authenticated" if its identify has been verified. > > If that's wrong, then I'd like to find out why. > > > > If it's right, then I'd like to find out why my discussion in > > the message below should be considered uneducated, nonsensical > > spew. > > > > If the bottom line is that these concepts are too hard for > > people like me to understand, then the relevant charter items > > should be moved to a working group where the right kind of > > people are able to put in the effort to carry out the work. > > I find that very hard to believe, but I'm willing to be > > educated. > > > > Thanks for your consideration of my request. > > > > Regards, > > Charlie P. > > > > > > > > Michael Thomas wrote: > > > > > > Charlie, > > > > > > There is no point in arguing with you. I gave you > > > the benefit of the doubt which was clearly not > > > justified; this is security 101. There is nothing > > > here in your rebuttal that shows that you have > > > even elementary clues. Please take some time to > > > educate yourself so that you can stop spewing this > > > uneducated nonsense. As for my supposed free time, > > > I have better uses for it. Maybe Dan Harkins would > > > be willing to help you. > > > > > > Mike > > > > > > Charlie Perkins writes: > > >> > > >> > > >>> Bzzt. You need authentication to know whether somebody's > > >>> *impersonating* somebody who has authorization to do > > >>> what the attacker wants to do. > > >> > > >> This is manifestly wrong, because one can carry something > > >> that gives authorization for some resource without having > > >> to be identified. > > >> > > >>>>> That was exactly my point, today there is no difference between > > >>>>> the credential > > >>>> > > >>>> I'm not very clear on what you mean. If you mean that > > today people > > >>>> usually accept authentication credentials as good enough > > for authorization, > > >>>> then I reckon that may be true, but I am not sure why it > > is relevant > > >>>> to the discussion we were having. > > >>> > > >>> False. On your typical OS, you log in first. That is > > >>> authentication first and foremost. ... > > >> > > >> This is a case where authentication provides sufficient > > authorization > > >> (according to the system design). > > >> > > >>> > > >>>> We can separate the two in a lot of ways, depending on the > > >>>> purpose for which authorization is needed. If you want to > > >>>> know that someone can pay, and the credit card company says > > >>>> they can pay, that is good enough. > > >>> > > >>> Uh, do you *really* think that credit card > > >>> company doesn't attempt to authenticate you > > >>> before they issue a card? All you're saying > > >>> here is that you trust third party authentication > > >>> (the credit card company) to make an authorization > > >>> decision based on that identity (give service). > > >> > > >> It's often enough true, however, that someone can use a > > >> credit card to get authorization for transfer of resources, > > >> without being the owner of the card. And this is often > > >> enough quite legitimate. > > >> > > >>>> If you want assurance > > >>>> that someone is authorized to see your documents, you need > > >>>> some other sort of authorization; it still doesn't have to > > >>>> be done by authenticating their identity. > > >>> > > >>> False. Only a fool would authorize something > > >>> without authenticating them first. > > >> > > >> False. I would authorize a lot of things if you give > > >> me enough money, and I wouldn't care who you are. > > >> > > >>>> It seems to me that we don't need a general authorization > > >>>> algorithm. > > >>> > > >>> There is no such thing. > > >> > > >> You seem so sure of yourself. > > >> > > >>>> We could use a general authentication algorithm, > > >>>> but then we have to decide whether that implicitly solves > > >>>> the authorization problem (whatever the latter is determined > > >>>> to be). > > >>> > > >>> Authentication can never solve authorization. They're > > >>> apples and oranges. > > >> > > >> What about your OS login example? Never say never. > > >> It depends on the system design. > > >> > > >>>> I believe that we can and should separate authorization and > > >>>> authentication for the purpose of context transfer. All that > > >>>> matters is that the requester is the same node that used to > > >>>> own the context at the previous access router. It doesn't > > >>>> really matter what IP address belongs to the requester (for > > >>>> this purpose of authorizing a context transfer). > > >>> > > >>> Pray tell, how can you tell if they are "the same node" > > >>> if you don't authenticate them? Just because you claim > > >>> to be the same node? > > >> > > >> If the node exhibits knowledge of a particular secret, I can > > >> believe they are authorized no matter who they are. > > >> > > >>> Please people, I urge people who are confused > > >>> to do some reading. This is really basic stuff > > >>> and we're headed off into durable nonsense > > >>> la-la land. > > >> > > >> It's always good to read and study and understand more. > > >> It's furthermore typically good to help others understand, > > >> given that time is available. You seem to have enough time > > >> on your hands. > > >> > > >> ... > > >> Charlie P. > > From owner-seamoby@diameter.org Sun Jun 10 10:56: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 KAA11306 for ; Sun, 10 Jun 2001 10:56:17 -0400 (EDT) Received: (qmail 1485 invoked by alias); 10 Jun 2001 14:44:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1479 invoked by uid 200); 10 Jun 2001 14:44:54 -0000 Received: (qmail 1474 invoked from network); 10 Jun 2001 14:44:52 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jun 2001 14:44:52 -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 f5AEspU06558; Sun, 10 Jun 2001 07:54:51 -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 AHV23802; Sun, 10 Jun 2001 07:54:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11204; Sun, 10 Jun 2001 07:54:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15139.35381.654283.828984@thomasm-u1.cisco.com> Date: Sun, 10 Jun 2001 07:54:45 -0700 (PDT) To: Charlie Perkins Cc: Kulwinder Atwal , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement In-Reply-To: <3B2380F9.F2AA55E9@iprg.nokia.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Charlie Perkins writes: > > Hello Kulwinder, > > I'm still trying to identify the problem that prevented me from > satisfying 's "security 101" criterion. Thanks > for your comments. I have a couple of follow-on questions. > > Isn't it possible to have authorization without authentication? > > In other words, isn't it possible to grant authorization based > on verification of some credential that doesn't provide any > assurance of identity? > > Currency comes to mind, and then electronic cash, but other > credentials are possible and relevant to the discussion. > I realize that such things begin to blur the line between a > credential and a tradable resource. As you have pointed > out, relying on credential verification itself begins to blur the > line between authentication and authorization. I don't think so. Unless you just found the money laying on the street or something, the authentication step happened when the previous entity gave *you* the money. Even if you found it on the street, you are just pointing out a weakness in the security scheme (I doubt that ecash carries this vulnerability forward). Note also that there is an explicit authentication step being done by the merchant: that the currency is a valid currency backed by name-your-government. This serves as a trusted third party. Note also that there may be many levels of hierarchy here: VISA/BofA/Federal Reserve/US gubberment. > Maybe an example would help. Suppose I put something > in a treasure chest, which cannot be opened except with > a key I happen to have. Then I give you the key and tell > you how to use it to open the treasure chest. > > Doesn't your possession of that key mean that you have > authorization to open the treasure chest? Surely, the > treasure chest isn't going to care about your identity. > To me, this means that authorization does not require > authentication. No. I could have given you the key but put restrictions on your authorization to open it (do not open unless I'm dead...). Again, don't conflate the strength of either the authentication or authorization checks (honor in the latter case) with their existence. > It should be clear how to map this example into the [seamoby] > realm of authorizing access to transferable context information, > and very relevant to the eventual discussion we should be > having. What is pertinent with SEAMOBY is third party delegation and transitive trust arrangements. The MN delegates (authorizes) the oldAR to act on its behalf after being authenticated by oldAR in the first place. OldAR and newAR have their own trust arrangement, which includes methods to authenticate and what is authorized within that authentication realm/identity. One of those may be the acceptance of CT. Even then, the job is not done. NewAR must complete the transaction by demanding that MN prove its identity to authorize use of that context. That can either be done directly (as in the way it initially authenticated via AAA, say), or through some new authentication realm (ie, via new secret in the realm of the AR's). Mike From owner-seamoby@diameter.org Mon Jun 11 00:26: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 AAA18564 for ; Mon, 11 Jun 2001 00:26:02 -0400 (EDT) Received: (qmail 2565 invoked by alias); 11 Jun 2001 04:15:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2559 invoked by uid 200); 11 Jun 2001 04:15:03 -0000 Received: (qmail 2551 invoked from network); 11 Jun 2001 04:15:01 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 04:15:01 -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 f5B4RWh10517; Mon, 11 Jun 2001 07:27:32 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 11 Jun 2001 07:25:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 11 Jun 2001 07:25:25 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B0B8@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org Cc: seamoby@diameter.org Subject: RE: [seamoby] Wireless Terminology Draft Date: Mon, 11 Jun 2001 07:25: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 Pat, > Having discussed this over with our AD, the best approach would be to > run the document through WG last call in the Working Groups that work > in this area. All last calls would work in parallel, and the editor > would have to address all comments received. > > The document would be informational, but recognized as having > consensus. > > If this works with the WG, I can discuss this with other relevant WG > chairs. I think that this is a great idea. John From owner-seamoby@diameter.org Mon Jun 11 01: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 BAA18822 for ; Mon, 11 Jun 2001 01:03:00 -0400 (EDT) Received: (qmail 3159 invoked by alias); 11 Jun 2001 04:50:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3153 invoked by uid 200); 11 Jun 2001 04:50:26 -0000 Received: (qmail 3148 invoked from network); 11 Jun 2001 04:50:25 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 04:50:25 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 01:00:21 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD2@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Charlie Perkins'" , Kulwinder Atwal Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 11 Jun 2001 01:00:20 -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: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Sunday, June 10, 2001 10:15 AM > To: Kulwinder Atwal > Cc: 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > Hello Kulwinder, > > I'm still trying to identify the problem that prevented me from > satisfying 's "security 101" criterion. Thanks > for your comments. I have a couple of follow-on questions. > > Isn't it possible to have authorization without authentication? No. Even when it seems like it maybe, the authentication is implicit, or "out of band". > > In other words, isn't it possible to grant authorization based > on verification of some credential that doesn't provide any > assurance of identity? > > Currency comes to mind, and then electronic cash, but other > credentials are possible and relevant to the discussion. Lets consider currency. A one hundred dollar bill issued by a central bank looks quite different than a one hundred dollar bill drawn by six year old child. The authentication process happens when you pick up the two bills and realize one is authentic. When you hand the two bills to a merchant the merchant will also look at the two bills determine one is authentic (Authentication) and allow (Authorization) you to make a purchase with only the authenticated bill. But, the merchant may realize sufficient funds are not available to make change for you, if you decide only to purchase a piece of gum. In this case the merchant has authenticated the currency, but not authorized the use of the currency. The indentity being verified with currency is the indentity of the central bank. Looking at a twenty dollar bill in my wallet, I notice that the bill is signed by two individuals with the central bank, under the statement "This note is legal tender" and the name of the central bank. The currency itself is a credential of the central bank. The indentity being verified by the credential is the indentity of the central bank. Since we believe it is unlikely that the bill is forged, it is our trust (trust relationship) in the central bank that allows us to use it. Currency has value and is a credential that verifies the identity of the central bank. > I realize that such things begin to blur the line between a > credential and a tradable resource. As you have pointed > out, relying on credential verification itself begins to blur the > line between authentication and authorization. > > Maybe an example would help. Suppose I put something > in a treasure chest, which cannot be opened except with > a key I happen to have. Then I give you the key and tell > you how to use it to open the treasure chest. > > Doesn't your possession of that key mean that you have > authorization to open the treasure chest? It is not my identity the chest is verifying. It it the indentity of the key. If the identity of the key is correct (Authenticated) such that its pattern matches the lock, the lock will allow (Authorize) the chest to open. > Surely, the > treasure chest isn't going to care about your identity. > To me, this means that authorization does not require > authentication. Further you verified my identity before giving me the key. You authenticated me as really being me and not some imposter posing as me. After you were certain it was me you authorized my access to the chest by giving me the key. There are two seperate Authentication/Authorization processes invovled. 1. You authenticate my identity and authorize me to hold the key. 2. The lock authenticates the key and authorizes the chest to open. This is possible because a key holder (you) can delate trust by passing the key after completing step 1. Most people do not consider step 1. as a 'real' step becuase it is usually implicit. But, consider that the shared secret (credential) is not a key/lock combination, but instead is a username/password combination. Software has no way of performing implicit 'delagation of trust' operations on the username/password combination. For Context Transfer to work, software MUST have a method of delagating trust between an MN and ARs so that a MN can move from oldAR to newAR without a breach in security. - Kulwinder. > > It should be clear how to map this example into the [seamoby] > realm of authorizing access to transferable context information, > and very relevant to the eventual discussion we should be > having. > > Regards, > Charlie P. > > > > > > Kulwinder Atwal wrote: > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Friday, June 08, 2001 3:54 PM > > > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; > 'seamoby' > > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, June 07, 2001 3:41 PM > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; > 'seamoby' > > > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > > > > > > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri > > > Madjid-MNAKHJI1 wrote: > > > > Hi Charlie, > > > > > > > > Correct me if I am wrong, > > > > I have not been very successful in finding specs that > > > > discriminate between authentication and authorization. > > > > So far I have only seen it in AAA Arch. > > > > Otherwise people use authentication credentials > > > > and authorization credentials interchangably. > > > > > > > > So we created a requirement that the CT peers should > > > > mutual authenticate each other prior to CT. Do you think > > > > a separate requirement for authorization is needed? > > > > > > > > > Authentication > > > The act of verifying the identity of an entity (subject). > > > > > > Authorization > > > The act of determining whether a requesting entity > > > (subject) will > > > be allowed access to a resource (object). > > > > > > > Hello Kulwinder > > > > Thanks for the answer. It conforms exactly with my > previous understanding. > > > > If you want to quote this message and answer to the mailing > list, that > > would be fine with me, but I didn't see a reason to send my request > > for clarification to the mailing list. > > > > Regards, > > Charlie P. > > > > > MN>> Sure. I get it, but my question is: > > > do we have different credential for authentication and > > > authorization today? > > > > I believe the confusion was started by this statement. > > > > Some definitions: > > > > 1. Credential: A certificate (Indentification Card, Digital > Signature) > > issued by a trusted third party. > > > > 2. Authentication: The act of verifying the indentity of an > entity by > > checking for a valid credential. > > > > 3. Authorization: The act of determining whether a > requesting entity will be > > allowed access to a resource which may depend on several > inputs of which > > authentication one such input. (others: job > function/service aggreement) > > > > Consider the following process: > > > > 1. Present Credential to Security Authority. > > 2. Authenticated? Yes. > > 3. Authorized? Yes. > > 4. Grant Access. > > > > Or, > > > > 1. Present Credential to Security Authority. > > 2. Authenticated? No. > > 3. Deny Access. > > > > The Authorization step is moot after failing the > Authentication step. > > Therefore, the term "Authorization Credential" has no > value, since the > > credential is never presented to the authorization process, > but to the > > authentication process. Without Authentication there can be no > > Authorization. > > > > Present Credential -> Authenticate -> Authorize -> Grant Access. > > > > Read the first few lines of: > > http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 > > > > Infact, the term "credential" stands on its own to convey > the correct > > meaning. It does not need adjectives like authentication, > security, or > > authorization. > > > > - Kulwinder. > > > > > > > > Madjid > > > > From owner-seamoby@diameter.org Mon Jun 11 01:06:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18948 for ; Mon, 11 Jun 2001 01:06:26 -0400 (EDT) Received: (qmail 3424 invoked by alias); 11 Jun 2001 04:53:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3418 invoked by uid 200); 11 Jun 2001 04:52:59 -0000 Received: (qmail 3406 invoked from network); 11 Jun 2001 04:52:56 -0000 Received: from porsta.cs.helsinki.fi (root@128.214.48.124) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 04:52:56 -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 f5B534m27532; Mon, 11 Jun 2001 08:03:04 +0300 Date: Mon, 11 Jun 2001 08:03:05 +0300 (EEST) From: Jukka Manner To: "Charles E. Perkins" cc: Pat Calhoun , Seamless Mobility Working Group Subject: Re: [seamoby] Wireless Terminology Draft In-Reply-To: <3B20E2FF.32F29794@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Sounds like a good plan. I will now try to join the current terminology draft with the old MANET-terminology. I will send you, Charlie, the new version for comments this week. BR, Jukka On Fri, 8 Jun 2001, Charles E. Perkins wrote: > > Hello Pat, > > That sounds like a good plan. > > What working groups will be contacted besides [manet]? > > > Regards, > Charlie P. > > > > Pat Calhoun wrote: > > > > All, > > > > Having discussed this over with our AD, the best approach would be to > > run the document through WG last call in the Working Groups that work > > in this area. All last calls would work in parallel, and the editor > > would have to address all comments received. > > > > The document would be informational, but recognized as having consensus. > > > > If this works with the WG, I can discuss this with other relevant WG > > chairs. > > > > PatC > From owner-seamoby@diameter.org Mon Jun 11 01:40: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 BAA21050 for ; Mon, 11 Jun 2001 01:40:28 -0400 (EDT) Received: (qmail 4262 invoked by alias); 11 Jun 2001 05:29:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4256 invoked by uid 200); 11 Jun 2001 05:29:17 -0000 Received: (qmail 4251 invoked from network); 11 Jun 2001 05:29:15 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 05:29: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 f5B5dnb20092 for ; Mon, 11 Jun 2001 08:39:49 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 11 Jun 2001 08:39:40 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 11 Jun 2001 08:39:40 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B0BC@eseis04nok> From: john.loughney@nokia.com To: seamoby@diameter.org Subject: [seamoby] Authentication vs Authorization Date: Mon, 11 Jun 2001 08:39:37 +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, I started to read the thread having to do with Authentication vs Authorization, but gave up - I get enough of playing with mud when I play with my 4 year old ... so for give me if I missed a pearl of wisdom in the mails I skipped. What I wonder is, if the issue of authentication vs authorization has more to do with: when you are authenticated, when you are authorized, who authenticates you, who authorizes you I'd suggest that you the two do not always need to go together. For example, if one is authenticated when attaching to the network, it might not be necessary to re-authenticate the user at each handover - especially if one is moving within an AD. One might want to re-authenticate a user when moving across AD boundaries. Of course, this is assume that the underlying protocols are secured, so that we can rely on the fact that once someone is authenticated, we can assume that we 'know' the user. best regards, John From owner-seamoby@diameter.org Mon Jun 11 04:12: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 EAA04645 for ; Mon, 11 Jun 2001 04:12:01 -0400 (EDT) Received: (qmail 5006 invoked by alias); 11 Jun 2001 07:58:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5000 invoked by uid 200); 11 Jun 2001 07:58:36 -0000 Received: (qmail 4995 invoked from network); 11 Jun 2001 07:58:35 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 07:58:35 -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 BAA04957; Mon, 11 Jun 2001 01:08:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5B88Vd02306; Mon, 11 Jun 2001 01:08:31 -0700 X-mProtect: Mon, 11 Jun 2001 01:08:31 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdNcfKB7; Mon, 11 Jun 2001 01:08:28 PDT Message-ID: <3B247C79.578AEC12@iprg.nokia.com> Date: Mon, 11 Jun 2001 01:08:25 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: "'Charlie Perkins'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD2@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: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Sunday, June 10, 2001 10:15 AM > > To: Kulwinder Atwal > > Cc: 'seamoby' > > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > > > > > Hello Kulwinder, > > > > I'm still trying to identify the problem that prevented me from > > satisfying 's "security 101" criterion. Thanks > > for your comments. I have a couple of follow-on questions. > > > > Isn't it possible to have authorization without authentication? > > No. Even when it seems like it maybe, the authentication is implicit, or > "out of band". > [Cedric] I think most of the confusion here comes from different level of authentications. Personal authentication vs. group authentication strong authentication vs. weak authentication. In order to get authorization, you need some level of authentication. You don't have to be identified all the way to your finger prints. Proving that you belong to a given group is usually enough. So you are right when you say that showing some credentials does relieve you of (strong/personal) authenticating, since the credential is already a (weak/group) authentication. > > > > > In other words, isn't it possible to grant authorization based > > on verification of some credential that doesn't provide any > > assurance of identity? [Cedric] It is possible, as long as the credential give some assurance of belonging to the authorized group. So it is a weak authentication. (that there is a strong authentication to get the credential is not a requirement, and as long as you accept the credential, who cares. Take credit card on-line. As long as someone gives you a credit card number (the credential) that is valid (the weak authentication), then that person can access your service. You don't give a damn how the user got the card number in the first place. > > > > > Currency comes to mind, and then electronic cash, but other > > credentials are possible and relevant to the discussion. > > Lets consider currency. A one hundred dollar bill issued by a central bank > looks quite different than a one hundred dollar bill drawn by six year old > child. The authentication process happens when you pick up the two bills > and realize one is authentic. [Cedric] As far as the user is concerned, he provides a weak authentication (belongs to the group: has the ability to pay/has the right credential, not the credential drawn by a 6-yo). > When you hand the two bills to a merchant the merchant will also look at the > two bills determine one is authentic (Authentication) and allow > (Authorization) you to make a purchase with only the authenticated bill. > But, the merchant may realize sufficient funds are not available to make > change for you, if you decide only to purchase a piece of gum. In this case > the merchant has authenticated the currency, but not authorized the use of > the currency. > > The indentity being verified with currency is the indentity of the central > bank. Looking at a twenty dollar bill in my wallet, I notice that the bill > is signed by two individuals with the central bank, under the statement > "This note is legal tender" and the name of the central bank. [Cedric] The identity really verified is that the user belongs the the authorized group (valid money=right credential=belongs to 'can access service since he/she has paid' group). > The currency itself is a credential of the central bank. The indentity > being verified by the credential is the indentity of the central bank. > Since we believe it is unlikely that the bill is forged, it is our trust > (trust relationship) in the central bank that allows us to use it. > > Currency has value and is a credential that verifies the identity of the > central bank. > > > I realize that such things begin to blur the line between a > > credential and a tradable resource. As you have pointed > > out, relying on credential verification itself begins to blur the > > line between authentication and authorization. [Cedric] Question is: why do you do authentication for? If you eventual purpose is to charge the user for the service he receives, then the credential is a solvability credential anyway, so why not currency. > > Maybe an example would help. Suppose I put something > > in a treasure chest, which cannot be opened except with > > a key I happen to have. Then I give you the key and tell > > you how to use it to open the treasure chest. > > > > Doesn't your possession of that key mean that you have > > authorization to open the treasure chest? > > It is not my identity the chest is verifying. It it the indentity of the > key. If the identity of the key is correct (Authenticated) such that its > pattern matches the lock, the lock will allow (Authorize) the chest to open. [Cedric] once again, it is not the identity of the key or the bank. The authentication is just that the user (key holder) belongs to the authorized group (those who have the correct keys). > > > > Surely, the > > treasure chest isn't going to care about your identity. > > To me, this means that authorization does not require > > authentication. > [Cedric] The chest does not require strong authentication. Does require weak authentication. > Further you verified my identity before giving me the key. You > authenticated me as really being me and not some imposter posing as me. > After you were certain it was me you authorized my access to the chest by > giving me the key. [Cedric] how you get access to the key is none of the chest problem. Maybe you whacked Charlie on the head, the chest don't care. In a context transfer framework, it means that there MUST be a weak authentication process to perform CT. CT does only care about Step 2 below. Cedric. > There are two seperate Authentication/Authorization processes invovled. > > 1. You authenticate my identity and authorize me to hold the key. > 2. The lock authenticates the key and authorizes the chest to open. > > This is possible because a key holder (you) can delate trust by passing the > key after completing step 1. Most people do not consider step 1. as a > 'real' step becuase it is usually implicit. > > But, consider that the shared secret (credential) is not a key/lock > combination, but instead is a username/password combination. > > Software has no way of performing implicit 'delagation of trust' operations > on the username/password combination. > > For Context Transfer to work, software MUST have a method of delagating > trust between an MN and ARs so that a MN can move from oldAR to newAR > without a breach in security. > > - Kulwinder. > > > > > It should be clear how to map this example into the [seamoby] > > realm of authorizing access to transferable context information, > > and very relevant to the eventual discussion we should be > > having. > > > > Regards, > > Charlie P. > > > > > > > > > > > > Kulwinder Atwal wrote: > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Friday, June 08, 2001 3:54 PM > > > > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > > > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; > > 'seamoby' > > > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > Sent: Thursday, June 07, 2001 3:41 PM > > > > To: Nakhjiri Madjid-MNAKHJI1 > > > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; > > 'seamoby' > > > > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > > > > > > > > > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri > > > > Madjid-MNAKHJI1 wrote: > > > > > Hi Charlie, > > > > > > > > > > Correct me if I am wrong, > > > > > I have not been very successful in finding specs that > > > > > discriminate between authentication and authorization. > > > > > So far I have only seen it in AAA Arch. > > > > > Otherwise people use authentication credentials > > > > > and authorization credentials interchangably. > > > > > > > > > > So we created a requirement that the CT peers should > > > > > mutual authenticate each other prior to CT. Do you think > > > > > a separate requirement for authorization is needed? > > > > > > > > > > > > Authentication > > > > The act of verifying the identity of an entity (subject). > > > > > > > > Authorization > > > > The act of determining whether a requesting entity > > > > (subject) will > > > > be allowed access to a resource (object). > > > > > > > > > > Hello Kulwinder > > > > > > Thanks for the answer. It conforms exactly with my > > previous understanding. > > > > > > If you want to quote this message and answer to the mailing > > list, that > > > would be fine with me, but I didn't see a reason to send my request > > > for clarification to the mailing list. > > > > > > Regards, > > > Charlie P. > > > > > > > MN>> Sure. I get it, but my question is: > > > > do we have different credential for authentication and > > > > authorization today? > > > > > > I believe the confusion was started by this statement. > > > > > > Some definitions: > > > > > > 1. Credential: A certificate (Indentification Card, Digital > > Signature) > > > issued by a trusted third party. > > > > > > 2. Authentication: The act of verifying the indentity of an > > entity by > > > checking for a valid credential. > > > > > > 3. Authorization: The act of determining whether a > > requesting entity will be > > > allowed access to a resource which may depend on several > > inputs of which > > > authentication one such input. (others: job > > function/service aggreement) > > > > > > Consider the following process: > > > > > > 1. Present Credential to Security Authority. > > > 2. Authenticated? Yes. > > > 3. Authorized? Yes. > > > 4. Grant Access. > > > > > > Or, > > > > > > 1. Present Credential to Security Authority. > > > 2. Authenticated? No. > > > 3. Deny Access. > > > > > > The Authorization step is moot after failing the > > Authentication step. > > > Therefore, the term "Authorization Credential" has no > > value, since the > > > credential is never presented to the authorization process, > > but to the > > > authentication process. Without Authentication there can be no > > > Authorization. > > > > > > Present Credential -> Authenticate -> Authorize -> Grant Access. > > > > > > Read the first few lines of: > > > http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 > > > > > > Infact, the term "credential" stands on its own to convey > > the correct > > > meaning. It does not need adjectives like authentication, > > security, or > > > authorization. > > > > > > - Kulwinder. > > > > > > > > > > > Madjid > > > > > > From owner-seamoby@diameter.org Mon Jun 11 09:47: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 JAA10609 for ; Mon, 11 Jun 2001 09:47:42 -0400 (EDT) Received: (qmail 6159 invoked by alias); 11 Jun 2001 13:36:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6153 invoked by uid 200); 11 Jun 2001 13:36:41 -0000 Received: (qmail 6143 invoked by uid 500); 11 Jun 2001 13:36:38 -0000 Date: Mon, 11 Jun 2001 06:36:38 -0700 From: Pat Calhoun To: Jukka Manner Cc: "Charles E. Perkins" , Pat Calhoun , Seamless Mobility Working Group Subject: Re: [seamoby] Wireless Terminology Draft Message-ID: <20010611063638.M17928@charizard.diameter.org> Mail-Followup-To: Jukka Manner , "Charles E. Perkins" , Pat Calhoun , Seamless Mobility Working Group References: <3B20E2FF.32F29794@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jmanner@cs.Helsinki.FI on Mon, Jun 11, 2001 at 08:03:05AM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 11, 2001 at 08:03:05AM +0300, Jukka Manner wrote: > Sounds like a good plan. I will now try to join the current terminology > draft with the old MANET-terminology. I will send you, Charlie, the new version > for comments this week. Good. When a draft is ready for review, please let me know. Thanks, PatC From owner-seamoby@diameter.org Mon Jun 11 11:17: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 LAA12567 for ; Mon, 11 Jun 2001 11:17:51 -0400 (EDT) Received: (qmail 7284 invoked by alias); 11 Jun 2001 15:06:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7278 invoked by uid 200); 11 Jun 2001 15:06:38 -0000 Received: (qmail 7273 invoked from network); 11 Jun 2001 15:06:36 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 15:06:36 -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 f5BFGaU21179; Mon, 11 Jun 2001 08:16:37 -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 AHV29544; Mon, 11 Jun 2001 08:16:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11487; Mon, 11 Jun 2001 08:16:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15140.57548.568089.747658@thomasm-u1.cisco.com> Date: Mon, 11 Jun 2001 08:16:28 -0700 (PDT) To: john.loughney@nokia.com Cc: seamoby@diameter.org Subject: [seamoby] Authentication vs Authorization In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680B0BC@eseis04nok> References: <01D91AFB08B6D211BFD00008C7EABAE10680B0BC@eseis04nok> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi all, > > I started to read the thread having to do with Authentication > vs Authorization, but gave up - I get enough of playing with > mud when I play with my 4 year old ... so for give me if I > missed a pearl of wisdom in the mails I skipped. > > What I wonder is, if the issue of authentication vs authorization > has more to do with: > > when you are authenticated, > when you are authorized, > who authenticates you, > who authorizes you > > I'd suggest that you the two do not always need to go together. > For example, if one is authenticated when attaching to the > network, it might not be necessary to re-authenticate the > user at each handover - especially if one is moving within > an AD. One might want to re-authenticate a user when moving > across AD boundaries. Of course, this is assume that the > underlying protocols are secured, so that we can rely on the > fact that once someone is authenticated, we can assume that > we 'know' the user. John, This is somewhat dependent on how you define "authenticate". If part of your definition is that you run a keyed hash over a message using a shared secret, then I believe that you must always authenticate to the newAR. Effectively, the messagewise authentication lies in a different realm as the original authentication (eg, using AAA), but messages still need authentication. For CT, I believe that the requirement is that we be able to cut out any long round trips which may be involved with, say, AAA so that the reauthentication can be performed locally where possible. This clearly is going to come into conflict across AD's as you mention, but it is important to note that within the AD you still need to authenticate (and re-authorize) each time you attach to the new AR. Mike From owner-seamoby@diameter.org Mon Jun 11 11:45: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 LAA13014 for ; Mon, 11 Jun 2001 11:45:43 -0400 (EDT) Received: (qmail 9310 invoked by alias); 11 Jun 2001 15:34:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9303 invoked by uid 200); 11 Jun 2001 15:34:12 -0000 Received: (qmail 9298 invoked from network); 11 Jun 2001 15:34:10 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 15:34:10 -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 f5BFi4912640; Mon, 11 Jun 2001 08:44: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 AHV29983; Mon, 11 Jun 2001 08:44:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11516; Mon, 11 Jun 2001 08:44:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15140.59201.876699.983045@thomasm-u1.cisco.com> Date: Mon, 11 Jun 2001 08:44:01 -0700 (PDT) To: Hannes Tschofenig Cc: "'Michael Thomas '" , "''Mark Smith ' '" , "'''seamoby' ' '" Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement In-Reply-To: <71C667A91D79D41197910050DA46B3C902FC17@chello213047128084.15.vie.surfer.at> References: <71C667A91D79D41197910050DA46B3C902FC17@chello213047128084.15.vie.surfer.at> 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 Hannes Tschofenig writes: > % hi thomas! > I really don't think that mipv6 address ownership > problem is the best example. > % it may not be the best example related to CT > % but it shows authorization without authentication. Again, let's not confuse authentication with strong crypto based authentication. In fact, many thing use the source IP address for authentication; whether that's a good idea, of course, is a different question. With the BU problem, many (including myself) are making the claim that authentication based on return routability -- possibly with some other checks thrown in -- is a sufficient test to authorize the BU. > > In fact, the > proposals that have been submitted all assert > identity, namely the IP address from whence they > came. > % they show two things: > % - the mobile node is at the current location (CoA) and > % is therefore able to reply to a response from a CN. Right. This is an authentication challenge. > % - and some proposals make use of the home agent to > % actively participate in the protocol. Correct. This is an authentication challenge where the MN and HA are considered to be part of a group where it doesn't matter who answers the query. It's still a challenge though. > % the first proposal "purpose built keys" does not provide > % address ownership - the home address is never used in the > % protocol itself > % the protocol however tries to introduce an interesting property: > % if the mobile node was once able to send the EID to the CN > % then the CN can be sure that a BU is from the same sender. PBK still uses a return routability test as the basis of the authentication. The draft is somewhat elusive about that, but it's implied by saying that the MN and CN must exchange a few messages before doing the PBK exchange. > Note that this is a weak form of both > authentication and authorization (ie no strong > crypto binding), but it does try to accomplish > both goals. > > % i am not quite sure if i would call this authentication because: > % if you look at a traditional authentication protocol then > % you have either a shared secret between those two parties or > % you rely on a trusted third party (with a trust relationship > % between both entities to the TTP). > % here we have neither a shared secret nor a infrastructure behind > % those entities. there is no trust relationship between the CN and the > % HA (or mn's home network). Again, authentication != strong authentication. There is a transitive trust relationship existent on the net right now. That is, if I forward a message, I trust that the next hop router will do it's job correctly, it trusts its next hop router will do it's job, and so forth. Therefore, the final router manifestly "owns" the subnet by virtue of the transitive trust relationships between the various IGP's and EGP's. All of the various BU security drafts try to take advantage of that already existing transitive trust arrangement. Mike From owner-seamoby@diameter.org Mon Jun 11 13:16:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15203 for ; Mon, 11 Jun 2001 13:16:53 -0400 (EDT) Received: (qmail 10344 invoked by alias); 11 Jun 2001 17:06:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10338 invoked by uid 200); 11 Jun 2001 17:06:11 -0000 Received: (qmail 10332 invoked by uid 500); 11 Jun 2001 17:06:08 -0000 Date: Mon, 11 Jun 2001 10:06:08 -0700 From: Pat Calhoun To: "'seamoby'" Subject: [seamoby] Seamoby Mud Slinging Contests Message-ID: <20010611100608.Y17928@charizard.diameter.org> Mail-Followup-To: 'seamoby' References: <35DBB8B7AC89D4118E98009027B1009B1B7C8F@IL27EXM10.cig.mot.com> <3B212FC1.D96C2DC4@iprg.nokia.com> <15137.28676.72102.282920@thomasm-u1.cisco.com> <3B2173A4.67963BD6@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2173A4.67963BD6@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 08, 2001 at 05:53:56PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk All, Could I please ask the participants on this list to please try to communicate in a gentler way? I understand that at times some people may not necessary see things the way you do, but educating them leads to cooperation much faster than simply telling them they are stupid. Let's stop this, folks! PatC (sorry he wasn't around earlier to kill this) From owner-seamoby@diameter.org Mon Jun 11 13:31: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 NAA15425 for ; Mon, 11 Jun 2001 13:31:05 -0400 (EDT) Received: (qmail 10883 invoked by alias); 11 Jun 2001 17:19:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10878 invoked by uid 200); 11 Jun 2001 17:19:51 -0000 Received: (qmail 10870 invoked by uid 500); 11 Jun 2001 17:19:48 -0000 Date: Mon, 11 Jun 2001 10:19:48 -0700 From: Pat Calhoun To: Charlie Perkins Cc: Kulwinder Atwal , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement Message-ID: <20010611101948.Z17928@charizard.diameter.org> Mail-Followup-To: Charlie Perkins , Kulwinder Atwal , 'seamoby' References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2380F9.F2AA55E9@iprg.nokia.com>; from charliep@IPRG.nokia.com on Sun, Jun 10, 2001 at 07:15:21AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Sun, Jun 10, 2001 at 07:15:21AM -0700, Charlie Perkins wrote: > Isn't it possible to have authorization without authentication? To me, it doesn't make a whole lotta sense. If you are going to authorize something prior to authentication, then I would consider the latter step as unnecessary. I agree with some that given enough money, you'll authorize anything, but you still want to make sure that the person asking is in fact the one that provided you with the cash, right? > > In other words, isn't it possible to grant authorization based > on verification of some credential that doesn't provide any > assurance of identity? verification of credentials implies authentication. Authentication doesn't necessarily provide that you'll know the identity of the requestor. It really depends on the type of authentication involved. > > Currency comes to mind, and then electronic cash, but other > credentials are possible and relevant to the discussion. Right. But if having a bank account number is sufficient to withdraw money, then this is a form of (admittedly weak) authentication. Once you've provided your bank account number, authorization would kick in when you request the amount you want, and the bank's policy in determining whether you've been authorized is probably something like: 1. Do you have enough in your account 2. Does it blow your daily limit 3. Do they even have enough in hard cash to give you > I realize that such things begin to blur the line between a > credential and a tradable resource. As you have pointed > out, relying on credential verification itself begins to blur the > line between authentication and authorization. > > Maybe an example would help. Suppose I put something > in a treasure chest, which cannot be opened except with > a key I happen to have. Then I give you the key and tell > you how to use it to open the treasure chest. Which is similar to giving me your bank account number (above) What you've done is authorize someone to have your credentials, which is used during the authentication process. > > Doesn't your possession of that key mean that you have > authorization to open the treasure chest? Surely, the > treasure chest isn't going to care about your identity. > To me, this means that authorization does not require > authentication. No, having the key is authentication. Authorization is allowing the person to take what they do (and assumes that there is an entity checking this, persumably you). Note the fact that no one is at the vault implies that your example involves authentication, but not authorization. Hope I haven't muddied the waters worse than it already was. PatC From owner-seamoby@diameter.org Mon Jun 11 14:05: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 OAA16086 for ; Mon, 11 Jun 2001 14:04:58 -0400 (EDT) Received: (qmail 11667 invoked by alias); 11 Jun 2001 17:51:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11661 invoked by uid 200); 11 Jun 2001 17:51:57 -0000 Received: (qmail 11653 invoked from network); 11 Jun 2001 17:51:55 -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; 11 Jun 2001 17:51:55 -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 f5BI1fE00518; Mon, 11 Jun 2001 14:01:41 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 11 Jun 2001 14:01:44 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 14:01:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CD4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , Charlie Perkins Cc: Kulwinder Atwal , "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 11 Jun 2001 14:01:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F2A0.90CC2140" 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_01C0F2A0.90CC2140 Content-Type: text/plain; charset="ISO-8859-1" Well, given enough money, I'd be willing to authenticate Pat as being Bill Gates (not that it would do him much good). Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, June 11, 2001 1:20 PM > To: Charlie Perkins > Cc: Kulwinder Atwal; 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > On Sun, Jun 10, 2001 at 07:15:21AM -0700, Charlie Perkins wrote: > > Isn't it possible to have authorization without authentication? > > To me, it doesn't make a whole lotta sense. If you are going > to authorize > something prior to authentication, then I would consider the > latter step > as unnecessary. > > I agree with some that given enough money, you'll authorize anything, > but you still want to make sure that the person asking is in fact the > one that provided you with the cash, right? > > > > > In other words, isn't it possible to grant authorization based > > on verification of some credential that doesn't provide any > > assurance of identity? > > verification of credentials implies authentication. Authentication > doesn't necessarily provide that you'll know the identity of the > requestor. It really depends on the type of authentication involved. > > > > > Currency comes to mind, and then electronic cash, but other > > credentials are possible and relevant to the discussion. > > Right. But if having a bank account number is sufficient to > withdraw money, then this is a form of (admittedly weak) > authentication. > > Once you've provided your bank account number, authorization would > kick in when you request the amount you want, and the bank's policy > in determining whether you've been authorized is probably something > like: > 1. Do you have enough in your account > 2. Does it blow your daily limit > 3. Do they even have enough in hard cash to give you > > > I realize that such things begin to blur the line between a > > credential and a tradable resource. As you have pointed > > out, relying on credential verification itself begins to blur the > > line between authentication and authorization. > > > > Maybe an example would help. Suppose I put something > > in a treasure chest, which cannot be opened except with > > a key I happen to have. Then I give you the key and tell > > you how to use it to open the treasure chest. > > Which is similar to giving me your bank account number (above) > What you've done is authorize someone to have your credentials, > which is used during the authentication process. > > > > > Doesn't your possession of that key mean that you have > > authorization to open the treasure chest? Surely, the > > treasure chest isn't going to care about your identity. > > To me, this means that authorization does not require > > authentication. > > No, having the key is authentication. Authorization is allowing > the person to take what they do (and assumes that there is an > entity checking this, persumably you). > > Note the fact that no one is at the vault implies that your > example involves authentication, but not authorization. > > Hope I haven't muddied the waters worse than it already was. > > PatC > ------_=_NextPart_001_01C0F2A0.90CC2140 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement

Well, given enough money, I'd be willing to authenticate Pat as
being Bill Gates (not that it would do him much good).

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Monday, June 11, 2001 1:20 PM
> To: Charlie Perkins
> Cc: Kulwinder Atwal; 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
>
>
> On Sun, Jun 10, 2001 at 07:15:21AM -0700, Charlie Perkins wrote:
> > Isn't it possible to have authorization without authentication?
>
> To me, it doesn't make a whole lotta sense. If you are going
> to authorize
> something prior to authentication, then I would consider the
> latter step
> as unnecessary.
>
> I agree with some that given enough money, you'll authorize anything,
> but you still want to make sure that the person asking is in fact the
> one that provided you with the cash, right?
>
> >
> > In other words, isn't it possible to grant authorization based
> > on verification of some credential that doesn't provide any
> > assurance of identity?
>
> verification of credentials implies authentication. Authentication
> doesn't necessarily provide that you'll know the identity of the
> requestor. It really depends on the type of authentication involved.
>
> >
> > Currency comes to mind, and then electronic cash, but other
> > credentials are possible and relevant to the discussion.
>
> Right. But if having a bank account number is sufficient to
> withdraw money, then this is a form of (admittedly weak)
> authentication.
>
> Once you've provided your bank account number, authorization would
> kick in when you request the amount you want, and the bank's policy
> in determining whether you've been authorized is probably something
> like:
> 1. Do you have enough in your account
> 2. Does it blow your daily limit
> 3. Do they even have enough in hard cash to give you
>
> > I realize that such things begin to blur the line between a
> > credential and a tradable resource.  As you have pointed
> > out, relying on credential verification itself begins to blur the
> > line between authentication and authorization.
> >
> > Maybe an example would help.  Suppose I put something
> > in a treasure chest, which cannot be opened except with
> > a key I happen to have.  Then I give you the key and tell
> > you how to use it to open the treasure chest.
>
> Which is similar to giving me your bank account number (above)
> What you've done is authorize someone to have your credentials,
> which is used during the authentication process.
>
> >
> > Doesn't your possession of that key mean that you have
> > authorization to open the treasure chest?  Surely, the
> > treasure chest isn't going to care about your identity.
> > To me, this means that authorization does not require
> > authentication.
>
> No, having the key is authentication. Authorization is allowing
> the person to take what they do (and assumes that there is an
> entity checking this, persumably you).
>
> Note the fact that no one is at the vault implies that your
> example involves authentication, but not authorization.
>
> Hope I haven't muddied the waters worse than it already was.
>
> PatC
>

------_=_NextPart_001_01C0F2A0.90CC2140-- From owner-seamoby@diameter.org Mon Jun 11 14:31: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 OAA16415 for ; Mon, 11 Jun 2001 14:31:08 -0400 (EDT) Received: (qmail 12294 invoked by alias); 11 Jun 2001 18:20:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12288 invoked by uid 200); 11 Jun 2001 18:20:01 -0000 Received: (qmail 12278 invoked from network); 11 Jun 2001 18:19:58 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 18:19:58 -0000 Received: from [206.112.126.58] ([206.112.126.58] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9599592; Mon, 11 Jun 2001 14:29:27 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <20010611101948.Z17928@charizard.diameter.org> References: <3B2380F9.F2AA55E9@iprg.nokia.com>; from charliep@IPRG.nokia.com on Sun, Jun 10, 2001 at 07:15:21AM -0700 <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> Date: Mon, 11 Jun 2001 11:30:21 -0700 To: Pat Calhoun , Charlie Perkins From: Arthur Ross Subject: Authentication & Authorization "in-the-large" was Re: [seamoby] ct problem statement Cc: Kulwinder Atwal , "'seamoby'" , Sender: owner-seamoby@diameter.org Precedence: bulk At 10:19 -0700 06/11/2001, Pat Calhoun wrote: [snip some history] >> >> Doesn't your possession of that key mean that you have >> authorization to open the treasure chest? Surely, the >> treasure chest isn't going to care about your identity. >> To me, this means that authorization does not require >> authentication. > >No, having the key is authentication. Authorization is allowing >the person to take what they do (and assumes that there is an >entity checking this, persumably you). > >Note the fact that no one is at the vault implies that your >example involves authentication, but not authorization. > >Hope I haven't muddied the waters worse than it already was. > Au contraire, Pat - Once again you guys are, methinks, nibbling around the edges of a much larger, more profound problem/issue of what I would call the "Evolved Internet". [Yes, I know that these philosophical soapbox orations of mine belong in the new list, which I have indeed cc'd.] When all sorts of entities, from doorknobs to aircraft carriers, and everything in between, are potential nomadic communication endpoints, the question of who can see and do what becomes VERY profound, and potentially VERY complex. I keep thinking that a good illustrative, prehistoric example/philosophical model of the kind of thing I am thinking of is the ol' Unix heirarchical file system. Everything has a nonad [a word I just invented, meaning "group of nine"] of priviledge flags, corresponding to all possible combinations of {read,modify,execute} with {owner, group, world}. In this view, authentication determines which of the three categories an supplicant belongs to, and authorization says which of the three actions he can perform. Attached are the owner and group IDs. As in the Unix model, the privledge sets might be inherited from a "parent" of some kind by default, or explicity modifiable. An obvious question is the nature of that heirarchy (or hierarchies) - does it map onto administrative domains? Routing domains? Or some other independent structure? How this stuff moves & changes with changes in point of attachment of a nomadic/mobile node is a highly nontrivial question as well. In this larger view, the Unix-like model would likely have parameters too, e.g. the credit limit, or non-monetary resource limits, time windows, etc. .... just my two cents worth ... -- ahmr From owner-seamoby@diameter.org Mon Jun 11 14:56: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 OAA16871 for ; Mon, 11 Jun 2001 14:56:33 -0400 (EDT) Received: (qmail 12826 invoked by alias); 11 Jun 2001 18:44:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12820 invoked by uid 200); 11 Jun 2001 18:44:41 -0000 Received: (qmail 12815 invoked from network); 11 Jun 2001 18:44:35 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 18:44:35 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA25031 for ; Mon, 11 Jun 2001 11:48:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA06937 for ; Mon, 11 Jun 2001 11:55:02 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 13:55:01 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C9F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 11 Jun 2001 13:54:57 -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 Hello Charlie, I must appologize for not reading the rest of the thread before sending this email, here it goes anyway. Let me first clear a few points based on my understanding, so you can tell me if I am correct or not: 1-I would say that authentication is to say that the authenticating party shows evidence that he (put a /she from now on) is actually who he says he is, the credential is an ID/ password/ keys... 2-Authorization, would then be the step afterward; The network says, ok now I know, who the party that just authenticated itself is, but IS the party authorized to use the service he is requesting? for example this would be applicable when a network provides various level of service. 3-Generally,(I think) today in most of cases, the networks authenticate and authorize the user at the same time, of many reasons that you know much better than me: say either, they don't offer too many different kinds of services, QoS is not implemented in internet, so the cost of using different services is the same for the ISP (but we all know this is not true with your cable company, you want more movie channels, you pay more :) ) So in effect, when the network authenticates and authorizes at the same time, the credentials used for authentication and authorization are the same. 4-If you would need to authenticate and authorize separately, then the credentials and processes need to be different. Impact on context transfer security and its immunity against DoS: Say the two ARs are pre-authenticated, you have a secure pipe between the ARs based on their identities and authentication keys. You use this pipe for context transfer, so nobody besides the ARs can do a context transfer, unless they are able to spoof ARs ID/auth key... But this does not prevent an AR from doing a DoS against the other, say I am an AR in network provider A' network and can hand my mobile's context to you, an AR in network provider B's network. I am now angry because you did not meet our billing agreement (sorry if this is a poor scenario for DoS). Now I can do a DoS sending a lot of bogus context to you and bring you down. Is this an authentication problem? maybe not. Can this be solved by an authorization prior to each CT? I guess so, the AR is already authenticated (if not, that would add a lot of delay to CT) but one authentication (that last forever, does not solve DoS problems. And I don't know why you say authentication is not important but authorization is a central requirement for CT? I am no expert in AAA, but The only place *I* have seen different credentials for authentication and authorization discussed in AAAArch. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, June 08, 2001 6:12 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'seamoby' Subject: Re: Comments Re: [seamoby] ct problem statement Hello Madjid, I think people usually want secure authorization, and they ask for authentication because it's less abstract somehow. You and I wrote: >> Sure. I get it, but my question is: >> do we have different credential for authentication and authorization today? > > It seems to me that today we typically use authentication when > we really need authorization. I guess the theory is that if you > really know who is on the other side of the communiations fence, > you'll be able to track them down if anything goes wrong. Then you wrote: > That was exactly my point, today there is no difference between > the credential I'm not very clear on what you mean. If you mean that today people usually accept authentication credentials as good enough for authorization, then I reckon that may be true, but I am not sure why it is relevant to the discussion we were having. > The reason that I asked the question > was your following answers to Phil: > > [ > > Is authentication needed? > > Probably not. > > > Is authorization needed? > > I think this is the central requirement. > ] > > how would we separate the two? We can separate the two in a lot of ways, depending on the purpose for which authorization is needed. If you want to know that someone can pay, and the credit card company says they can pay, that is good enough. If you want assurance that someone is authorized to see your documents, you need some other sort of authorization; it still doesn't have to be done by authenticating their identity. If you have an access control list of authorized identities, then you can use authentication. It seems to me that we don't need a general authorization algorithm. We could use a general authentication algorithm, but then we have to decide whether that implicitly solves the authorization problem (whatever the latter is determined to be). I believe that we can and should separate authorization and authentication for the purpose of context transfer. All that matters is that the requester is the same node that used to own the context at the previous access router. It doesn't really matter what IP address belongs to the requester (for this purpose of authorizing a context transfer). Regards, Charlie P. From owner-seamoby@diameter.org Mon Jun 11 15:00: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 PAA16928 for ; Mon, 11 Jun 2001 15:00:29 -0400 (EDT) Received: (qmail 13078 invoked by alias); 11 Jun 2001 18:46:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13072 invoked by uid 200); 11 Jun 2001 18:46:32 -0000 Received: (qmail 13063 invoked from network); 11 Jun 2001 18:46:30 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 18:46:30 -0000 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BIuW922803; Mon, 11 Jun 2001 11:56:32 -0700 (PDT) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id AAU60877; Mon, 11 Jun 2001 11:56:26 -0700 (PDT) Message-Id: <4.1.20010611114914.017c7360@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 11 Jun 2001 12:01:12 -0700 To: Charlie Perkins , Kulwinder Atwal From: Jonathan Trostle Subject: Re: Comments Re: [seamoby] ct problem statement Cc: "'seamoby'" In-Reply-To: <3B2380F9.F2AA55E9@iprg.nokia.com> References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-seamoby@diameter.org Precedence: bulk At 07:15 AM 6/10/01 -0700, Charlie Perkins wrote: > >Hello Kulwinder, > >I'm still trying to identify the problem that prevented me from >satisfying 's "security 101" criterion. Thanks >for your comments. I have a couple of follow-on questions. > >Isn't it possible to have authorization without authentication? Sure, unless you are playing a word game where no authentication is viewed as one type of authentication - i.e. very weak authentication. > >In other words, isn't it possible to grant authorization based >on verification of some credential that doesn't provide any >assurance of identity? Yes. This is classically known as a bearer proxy. > >Currency comes to mind, and then electronic cash, but other >credentials are possible and relevant to the discussion. >I realize that such things begin to blur the line between a >credential and a tradable resource. As you have pointed >out, relying on credential verification itself begins to blur the >line between authentication and authorization. > >Maybe an example would help. Suppose I put something >in a treasure chest, which cannot be opened except with >a key I happen to have. Then I give you the key and tell >you how to use it to open the treasure chest. > >Doesn't your possession of that key mean that you have >authorization to open the treasure chest? Surely, the >treasure chest isn't going to care about your identity. >To me, this means that authorization does not require >authentication. Yes. Another example would be a VPN or multicast group with a single shared secret key. A message protected with such a key authorizes the sender as a member of the group. But it doesn't allow the receiver to determine the identity of the sender. To do that, a source authentication security service is needed. Jonathan > >It should be clear how to map this example into the [seamoby] >realm of authorizing access to transferable context information, >and very relevant to the eventual discussion we should be >having. > >Regards, >Charlie P. > > > > > >Kulwinder Atwal wrote: > >> > -----Original Message----- >> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >> > Sent: Friday, June 08, 2001 3:54 PM >> > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 >> > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' >> > Subject: RE: Comments Re: [seamoby] ct problem statement >> > >> > >> > >> > >> > -----Original Message----- >> > From: Pat Calhoun [mailto:pcalhoun@diameter.org] >> > Sent: Thursday, June 07, 2001 3:41 PM >> > To: Nakhjiri Madjid-MNAKHJI1 >> > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' >> > Subject: Re: Comments Re: [seamoby] ct problem statement >> > >> > >> > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri >> > Madjid-MNAKHJI1 wrote: >> > > Hi Charlie, >> > > >> > > Correct me if I am wrong, >> > > I have not been very successful in finding specs that >> > > discriminate between authentication and authorization. >> > > So far I have only seen it in AAA Arch. >> > > Otherwise people use authentication credentials >> > > and authorization credentials interchangably. >> > > >> > > So we created a requirement that the CT peers should >> > > mutual authenticate each other prior to CT. Do you think >> > > a separate requirement for authorization is needed? >> > >> > >> > Authentication >> > The act of verifying the identity of an entity (subject). >> > >> > Authorization >> > The act of determining whether a requesting entity >> > (subject) will >> > be allowed access to a resource (object). >> > >> >> Hello Kulwinder >> >> Thanks for the answer. It conforms exactly with my previous understanding. >> >> If you want to quote this message and answer to the mailing list, that >> would be fine with me, but I didn't see a reason to send my request >> for clarification to the mailing list. >> >> Regards, >> Charlie P. >> >> > MN>> Sure. I get it, but my question is: >> > do we have different credential for authentication and >> > authorization today? >> >> I believe the confusion was started by this statement. >> >> Some definitions: >> >> 1. Credential: A certificate (Indentification Card, Digital Signature) >> issued by a trusted third party. >> >> 2. Authentication: The act of verifying the indentity of an entity by >> checking for a valid credential. >> >> 3. Authorization: The act of determining whether a requesting entity will be >> allowed access to a resource which may depend on several inputs of which >> authentication one such input. (others: job function/service aggreement) >> >> Consider the following process: >> >> 1. Present Credential to Security Authority. >> 2. Authenticated? Yes. >> 3. Authorized? Yes. >> 4. Grant Access. >> >> Or, >> >> 1. Present Credential to Security Authority. >> 2. Authenticated? No. >> 3. Deny Access. >> >> The Authorization step is moot after failing the Authentication step. >> Therefore, the term "Authorization Credential" has no value, since the >> credential is never presented to the authorization process, but to the >> authentication process. Without Authentication there can be no >> Authorization. >> >> Present Credential -> Authenticate -> Authorize -> Grant Access. >> >> Read the first few lines of: >> http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 >> >> Infact, the term "credential" stands on its own to convey the correct >> meaning. It does not need adjectives like authentication, security, or >> authorization. >> >> - Kulwinder. >> >> > >> > Madjid >> > > From owner-seamoby@diameter.org Mon Jun 11 15:15: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 PAA17160 for ; Mon, 11 Jun 2001 15:15:32 -0400 (EDT) Received: (qmail 14051 invoked by alias); 11 Jun 2001 19:04:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14045 invoked by uid 200); 11 Jun 2001 19:04:24 -0000 Received: (qmail 14033 invoked by uid 500); 11 Jun 2001 19:04:21 -0000 Date: Mon, 11 Jun 2001 12:04:21 -0700 From: Pat Calhoun To: Arthur Ross Cc: Pat Calhoun , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: Re: Authentication & Authorization "in-the-large" was Re: [seamoby] ct problem statement Message-ID: <20010611120420.I17928@charizard.diameter.org> Mail-Followup-To: Arthur Ross , Pat Calhoun , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: <3B2380F9.F2AA55E9@iprg.nokia.com>; <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> <20010611101948.Z17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from a.ross@ieee.org on Mon, Jun 11, 2001 at 11:30:21AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 11, 2001 at 11:30:21AM -0700, Arthur Ross wrote: > Au contraire, Pat - Je ne pense pas. > I keep thinking that a good illustrative, prehistoric example/philosophical > model of the kind of thing I am thinking of is the ol' Unix heirarchical > file system. Everything has a nonad [a word I just invented, meaning "group > of nine"] of priviledge flags, corresponding to all possible combinations > of {read,modify,execute} with {owner, group, world}. In this view, > authentication determines which of the three categories an supplicant > belongs to, and authorization says which of the three actions he can > perform. Attached are the owner and group IDs. I wonder why this thread even exists, but I find myself having to correct your example above. The very fact that a set of permissions have been setup on a file is NOT authentication. Before I even get access to the said files, there is another program, Unix login, which checks my credentials, and then executes the shell with my user and group id. Requesting access to the file is an authorization decision on the part of the OS. Do I have access to the file? What is my user id? group id? Obviously, we aren't going to agree on the very fundamental difference between authorization and authentication, and we can just agree to disagree. PatC From owner-seamoby@diameter.org Mon Jun 11 15:41: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 PAA17612 for ; Mon, 11 Jun 2001 15:41:36 -0400 (EDT) Received: (qmail 14706 invoked by alias); 11 Jun 2001 19:29:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14700 invoked by uid 200); 11 Jun 2001 19:29:02 -0000 Received: (qmail 14695 invoked from network); 11 Jun 2001 19:29:01 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 19:29:01 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA29081 for ; Mon, 11 Jun 2001 12:39:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA17648 for ; Mon, 11 Jun 2001 12:39:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 14:39:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D5C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charlie Perkins'" , Kulwinder Atwal Cc: "'seamoby'" Subject: [seamoby] authorization [was CT problem statement] Date: Mon, 11 Jun 2001 14:39:19 -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 Charlie, I remember I had this question about credential for authentication or authorization when I was reading RFC 2977 " Mobile IP Authentication, Authorization, and Accounting Requirements" I felt that the word credential was used both for authorization and accouting, without specifying what they are, or whether they are different. Then I went to IETF 50 AAAArch and heard that they were mentioning the same issue as a research topic. I must admit that I have not had time to look into their work until the CT DoS issue came up. Anyway, since you are doing research on this, I would appreciate if you share your findings with us. I guess you have seen the following, since some of these documents include Mobile IP cases, but anyway I found the following on authorization, in case anybody have not seen it. [1] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, D., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000. [2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000. [3] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000. Unfortunately, I have not read them, I was just skimming through and In RFC 2905 I found the following section on PPP (I only include the important parts). 2.2. Authorization Requirements The following requirements are identified in [9] for authorizing PPP dialin service using roaming. - Authorization separate from authentication should be allowed when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization. - The protocol MUST provide the following features (per user session): 1. One Authentication, One Authorization 2. One Authentication, Multiple Authorization 3. Multiple Authentication, Multiple Authorization They do talk about an authorization separate from authentication, but I did not see anything about different credentials :( So maybe Kulwinder is right at least according to what exist in specs today. Madjid -----Original Message----- From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] Sent: Sunday, June 10, 2001 9:15 AM To: Kulwinder Atwal Cc: 'seamoby' Subject: Re: Comments Re: [seamoby] ct problem statement Hello Kulwinder, I'm still trying to identify the problem that prevented me from satisfying 's "security 101" criterion. Thanks for your comments. I have a couple of follow-on questions. Isn't it possible to have authorization without authentication? In other words, isn't it possible to grant authorization based on verification of some credential that doesn't provide any assurance of identity? Currency comes to mind, and then electronic cash, but other credentials are possible and relevant to the discussion. I realize that such things begin to blur the line between a credential and a tradable resource. As you have pointed out, relying on credential verification itself begins to blur the line between authentication and authorization. Maybe an example would help. Suppose I put something in a treasure chest, which cannot be opened except with a key I happen to have. Then I give you the key and tell you how to use it to open the treasure chest. Doesn't your possession of that key mean that you have authorization to open the treasure chest? Surely, the treasure chest isn't going to care about your identity. To me, this means that authorization does not require authentication. It should be clear how to map this example into the [seamoby] realm of authorizing access to transferable context information, and very relevant to the eventual discussion we should be having. Regards, Charlie P. Kulwinder Atwal wrote: > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Friday, June 08, 2001 3:54 PM > > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > > Subject: RE: Comments Re: [seamoby] ct problem statement > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 07, 2001 3:41 PM > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: 'Charles E. Perkins'; Gary Kenward; 'mankin@isi.edu'; 'seamoby' > > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > > > On Thu, Jun 07, 2001 at 03:43:29PM -0500, Nakhjiri > > Madjid-MNAKHJI1 wrote: > > > Hi Charlie, > > > > > > Correct me if I am wrong, > > > I have not been very successful in finding specs that > > > discriminate between authentication and authorization. > > > So far I have only seen it in AAA Arch. > > > Otherwise people use authentication credentials > > > and authorization credentials interchangably. > > > > > > So we created a requirement that the CT peers should > > > mutual authenticate each other prior to CT. Do you think > > > a separate requirement for authorization is needed? > > > > > > Authentication > > The act of verifying the identity of an entity (subject). > > > > Authorization > > The act of determining whether a requesting entity > > (subject) will > > be allowed access to a resource (object). > > > > Hello Kulwinder > > Thanks for the answer. It conforms exactly with my previous understanding. > > If you want to quote this message and answer to the mailing list, that > would be fine with me, but I didn't see a reason to send my request > for clarification to the mailing list. > > Regards, > Charlie P. > > > MN>> Sure. I get it, but my question is: > > do we have different credential for authentication and > > authorization today? > > I believe the confusion was started by this statement. > > Some definitions: > > 1. Credential: A certificate (Indentification Card, Digital Signature) > issued by a trusted third party. > > 2. Authentication: The act of verifying the indentity of an entity by > checking for a valid credential. > > 3. Authorization: The act of determining whether a requesting entity will be > allowed access to a resource which may depend on several inputs of which > authentication one such input. (others: job function/service aggreement) > > Consider the following process: > > 1. Present Credential to Security Authority. > 2. Authenticated? Yes. > 3. Authorized? Yes. > 4. Grant Access. > > Or, > > 1. Present Credential to Security Authority. > 2. Authenticated? No. > 3. Deny Access. > > The Authorization step is moot after failing the Authentication step. > Therefore, the term "Authorization Credential" has no value, since the > credential is never presented to the authorization process, but to the > authentication process. Without Authentication there can be no > Authorization. > > Present Credential -> Authenticate -> Authorize -> Grant Access. > > Read the first few lines of: > http://www.vsm.com.au:8000/ht_root/doc/htd/htd_1200.html#159 > > Infact, the term "credential" stands on its own to convey the correct > meaning. It does not need adjectives like authentication, security, or > authorization. > > - Kulwinder. > > > > > Madjid > > From owner-seamoby@diameter.org Mon Jun 11 15:47: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 PAA17638 for ; Mon, 11 Jun 2001 15:47:42 -0400 (EDT) Received: (qmail 15210 invoked by alias); 11 Jun 2001 19:36:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15204 invoked by uid 200); 11 Jun 2001 19:36:42 -0000 Received: (qmail 15193 invoked from network); 11 Jun 2001 19:36:40 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 19:36:40 -0000 Received: from [206.112.124.107] ([206.112.124.107] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9604559; Mon, 11 Jun 2001 15:46:08 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <20010611120420.I17928@charizard.diameter.org> References: ; from a.ross@ieee.org on Mon, Jun 11, 2001 at 11:30:21AM -0700 <3B2380F9.F2AA55E9@iprg.nokia.com>; <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> <20010611101948.Z17928@charizard.diameter.org> Date: Mon, 11 Jun 2001 12:47:07 -0700 To: Pat Calhoun From: Arthur Ross Subject: [seamoby] Re: Authentication & Authorization "in-the-large" was Re: [seamoby] ct problem statement Cc: Pat Calhoun , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Sender: owner-seamoby@diameter.org Precedence: bulk At 12:04 -0700 06/11/2001, Pat Calhoun wrote: >I wonder why this thread even exists, but I find myself having to correct >your example above. The very fact that a set of permissions have been setup >on a file is NOT authentication. Before I even get access to the said files, >there is another program, Unix login, which checks my credentials, and then >executes the shell with my user and group id. Requesting access to the file >is an authorization decision on the part of the OS. Do I have access to >the file? >What is my user id? group id? > >Obviously, we aren't going to agree on the very fundamental difference between >authorization and authentication, and we can just agree to disagree. > Pat - You missed my point completely - I am AGREEING with you 100%. Indeed, the login, which includes authentication, attaches the formal identity to the session. The formal identity is then used as an index to the privledges, a.k.a. authorization. We are in 100% agreement. My point is that this is a microcosm of a MUCH LARGER ISSUE, which, of course, is not currently being addressed. -- ahmr Dr. Arthur H. M. Ross 1004 Cottage Way Encinitas, CA 92024-5857 Tel: 760-634-8173 (Res.) 602-677-1021 (Portable) From owner-seamoby@diameter.org Mon Jun 11 15:52: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 PAA17724 for ; Mon, 11 Jun 2001 15:52:56 -0400 (EDT) Received: (qmail 15704 invoked by alias); 11 Jun 2001 19:41:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15698 invoked by uid 200); 11 Jun 2001 19:41:49 -0000 Received: (qmail 15686 invoked by uid 500); 11 Jun 2001 19:41:47 -0000 Date: Mon, 11 Jun 2001 12:41:47 -0700 From: Pat Calhoun To: Arthur Ross Cc: Pat Calhoun , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: Re: Authentication & Authorization "in-the-large" was Re: [seamoby] ct problem statement Message-ID: <20010611124147.K17928@charizard.diameter.org> Mail-Followup-To: Arthur Ross , Pat Calhoun , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: ; <3B2380F9.F2AA55E9@iprg.nokia.com>; <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD1@NEPTUNE.zucotto.com> <3B2380F9.F2AA55E9@iprg.nokia.com> <20010611101948.Z17928@charizard.diameter.org> <20010611120420.I17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from a.ross@ieee.org on Mon, Jun 11, 2001 at 12:47:07PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 11, 2001 at 12:47:07PM -0700, Arthur Ross wrote: > At 12:04 -0700 06/11/2001, Pat Calhoun wrote: > >I wonder why this thread even exists, but I find myself having to correct > >your example above. The very fact that a set of permissions have been setup > >on a file is NOT authentication. Before I even get access to the said files, > >there is another program, Unix login, which checks my credentials, and then > >executes the shell with my user and group id. Requesting access to the file > >is an authorization decision on the part of the OS. Do I have access to > >the file? > >What is my user id? group id? > > > >Obviously, we aren't going to agree on the very fundamental difference between > >authorization and authentication, and we can just agree to disagree. > > > Pat - > > You missed my point completely - I am AGREEING with you 100%. Indeed, the > login, which includes authentication, attaches the formal identity to the > session. The formal identity is then used as an index to the privledges, > a.k.a. authorization. We are in 100% agreement. > > My point is that this is a microcosm of a MUCH LARGER ISSUE, which, of > course, is not currently being addressed. Ooops. When you stated "Au Contraire", to me it implied that you disagreed with me. Sorry I didn't notice that the rest of the text was agreeing with my previous statement :( PatC From owner-seamoby@diameter.org Mon Jun 11 15:57: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 PAA17790 for ; Mon, 11 Jun 2001 15:57:50 -0400 (EDT) Received: (qmail 16187 invoked by alias); 11 Jun 2001 19:46:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16181 invoked by uid 200); 11 Jun 2001 19:46:30 -0000 Received: (qmail 16173 invoked from network); 11 Jun 2001 19:46:28 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 19:46:28 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA15291; Mon, 11 Jun 2001 12:56:55 -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 MAA29964; Mon, 11 Jun 2001 12:56:55 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 14:56:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D5D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Arthur Ross Cc: Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Date: Mon, 11 Jun 2001 14:56:53 -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 Pat, Before you kill this thread :) Since I started this, I want to clearify why we started the thread. This originally was not about weak or strong authentication, as much as it gets people excited. This was about 2 things. 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS. 2- Why some people think authentication is not important, while authorization is central for CT. If people cannot contribute to the CT DoS discussion, I suggest they do cryptography discussion to a security mailing list, before Pat kills this thread. We are just trying to get CT PS ready for shipping. Thank you, Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, June 11, 2001 2:04 PM To: Arthur Ross Cc: Pat Calhoun; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: Re: Authentication & Authorization "in-the-large" was Re: [seamoby] ct problem statement On Mon, Jun 11, 2001 at 11:30:21AM -0700, Arthur Ross wrote: > Au contraire, Pat - Je ne pense pas. > I keep thinking that a good illustrative, prehistoric example/philosophical > model of the kind of thing I am thinking of is the ol' Unix heirarchical > file system. Everything has a nonad [a word I just invented, meaning "group > of nine"] of priviledge flags, corresponding to all possible combinations > of {read,modify,execute} with {owner, group, world}. In this view, > authentication determines which of the three categories an supplicant > belongs to, and authorization says which of the three actions he can > perform. Attached are the owner and group IDs. I wonder why this thread even exists, but I find myself having to correct your example above. The very fact that a set of permissions have been setup on a file is NOT authentication. Before I even get access to the said files, there is another program, Unix login, which checks my credentials, and then executes the shell with my user and group id. Requesting access to the file is an authorization decision on the part of the OS. Do I have access to the file? What is my user id? group id? Obviously, we aren't going to agree on the very fundamental difference between authorization and authentication, and we can just agree to disagree. PatC From owner-seamoby@diameter.org Mon Jun 11 16:07: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 QAA17978 for ; Mon, 11 Jun 2001 16:07:30 -0400 (EDT) Received: (qmail 16693 invoked by alias); 11 Jun 2001 19:56:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16687 invoked by uid 200); 11 Jun 2001 19:56:19 -0000 Received: (qmail 16674 invoked by uid 500); 11 Jun 2001 19:56:17 -0000 Date: Mon, 11 Jun 2001 12:56:17 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: [seamoby] Re: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Message-ID: <20010611125617.L17928@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Pat Calhoun' , Arthur Ross , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: <35DBB8B7AC89D4118E98009027B1009B017A9D5D@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: <35DBB8B7AC89D4118E98009027B1009B017A9D5D@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jun 11, 2001 at 02:56:53PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 11, 2001 at 02:56:53PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Before you kill this thread :) Since I started this, I want to clearify > why we started the thread. of course. My intention was not to kill the whole thread, just the definition wars that are going on :) > > This originally was not about weak or strong authentication, as much > as it gets people excited. This was about 2 things. right > > 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS. I would claim that such events are unlikely to happen. When a user wants to move from one service area to another, the spectrum will be overlapping. The operators of these networks will allow/disallow CT between the routers handling these service areas. If they permit it, then will ensure that secure communication is available between them. > > 2- Why some people think authentication is not important, while > authorization > is central for CT. In this particular case, they MAY be one and the same. For example, while setting up the security association between the routers, additional configuration MAY be possible to limit the types of CT blobs that will be accepted. [note I used blob to imply the application blob being transferred] > > If people cannot contribute to the CT DoS discussion, I suggest they > do cryptography discussion to a security mailing list, before Pat kills > this thread. Sorry, please see above :( > > We are just trying to get CT PS ready for shipping. Of course :) PatC From owner-seamoby@diameter.org Mon Jun 11 16:15:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18147 for ; Mon, 11 Jun 2001 16:15:39 -0400 (EDT) Received: (qmail 16867 invoked by alias); 11 Jun 2001 19:57:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16861 invoked by uid 200); 11 Jun 2001 19:57:04 -0000 Received: (qmail 16851 invoked from network); 11 Jun 2001 19:57:02 -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; 11 Jun 2001 19:57:02 -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 f5BK6iE21018 for ; Mon, 11 Jun 2001 16:06:44 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 11 Jun 2001 16:06:27 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 16:06:30 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Mon, 11 Jun 2001 16:06:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F2B1.FB267A70" 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_01C0F2B1.FB267A70 Content-Type: text/plain; charset="ISO-8859-1" Madjid, Charlie, et al: Madjid, I think you have captured the essence of the real issue. Authentication and authorization are different, but for the most part, authorization has never really been needed for the internet, mainly for the reasons you describe. The real interesting issue (besides how to authorize every doorknob and aircraft carrier on the planet), is whether, in a mobile environment, how often one needs to authenticate. Consider that a mobile node travelling through the network will, with each handover, open up opportunities for an interloper to steal a service, if that service is only authorized and the service user is not authenticated. The opposite is also true: if the mobile node is not re-authorized with each handover, does this not open up the opportunity for the authenticated node to steal service it has not been authorized to use? I do not believe that there are any easy answers to these questions. Certainly, tight security imposes greater complexity on the network and sometimes, introduces performance degradation. And the cost of security is inevitably passed on to the consumer. I haven't followed the "authorization" discussion in AAA, but from the postings to this list is does sound that there is no solution on the horizon (please correct me if I am mistaken). It would seem that for a mobile solution, the preferred approach would incorporate some sort of "authorization" tokens that would could be passed between ARs as part of the mobile node's context (in a secure fashion of course). There would have to be a tight association maintained between the authentication information and these authorization tokens. If this is the best approach, then once again, it would be difficult to distinguish authentication from authorization. Just some thoughts. Cheers, Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 11, 2001 2:55 PM > To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Hello Charlie, > > I must appologize for not reading the rest of the thread > before sending this email, here it goes anyway. > Let me first clear a few points based on my understanding, > so you can tell me if I am correct or not: > > 1-I would say that authentication is to say that the authenticating > party shows evidence that he (put a /she from now on) > is actually who he says he is, the credential is an ID/ > password/ keys... > > 2-Authorization, would then be the step afterward; > The network says, ok now I know, who the party that > just authenticated itself is, but > IS the party authorized to use the service he is requesting? > for example this would be applicable when > a network provides various level of service. > > 3-Generally,(I think) today in most of cases, the networks > authenticate > and authorize the user at the same time, of many reasons that you > know much better than me: say either, they don't offer too many > different kinds of services, QoS is not implemented in internet, > so the cost of using different services is the same for the ISP > (but we all know this is not true with your cable company, you want > more movie channels, you pay more :) ) > So in effect, when the network authenticates and authorizes > at the same > time, the credentials used for authentication and > authorization are the > same. > > 4-If you would need to authenticate and authorize separately, then > the credentials and processes need to be different. > > Impact on context transfer security and its immunity against DoS: > Say the two ARs are pre-authenticated, you have a secure pipe between > the ARs based on their identities and authentication keys. > You use this pipe for context transfer, so nobody besides the ARs > can do a context transfer, unless they are able to spoof ARs > ID/auth key... > But this does not prevent an AR from doing a DoS against the other, > say I am an AR in network provider A' network and can hand my > mobile's > context to you, an AR in network provider B's network. I am now > angry because you did not meet our billing agreement (sorry if this > is a poor scenario for DoS). Now I can do a DoS sending a lot of bogus > context to you and bring you down. > > Is this an authentication problem? maybe not. > Can this be solved by an authorization prior to each CT? > > I guess so, the AR is already authenticated (if not, that would > add a lot of delay to CT) but one authentication (that last > forever, does not solve DoS problems. > > And I don't know why you say authentication is not important > but authorization is a central requirement for CT? > > I am no expert in AAA, but The only place *I* have seen > different credentials for authentication and authorization > discussed in AAAArch. > > Regards, > Madjid > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, June 08, 2001 6:12 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'seamoby' > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > Hello Madjid, > > I think people usually want secure authorization, and they > ask for authentication because it's less abstract somehow. > > You and I wrote: > > >> Sure. I get it, but my question is: > >> do we have different credential for authentication and > authorization > today? > > > > It seems to me that today we typically use authentication when > > we really need authorization. I guess the theory is that if you > > really know who is on the other side of the communiations fence, > > you'll be able to track them down if anything goes wrong. > > Then you wrote: > > > That was exactly my point, today there is no difference between > > the credential > > I'm not very clear on what you mean. If you mean that today people > usually accept authentication credentials as good enough for > authorization, > then I reckon that may be true, but I am not sure why it is relevant > to the discussion we were having. > > > The reason that I asked the question > > was your following answers to Phil: > > > > [ > > > Is authentication needed? > > > > Probably not. > > > > > Is authorization needed? > > > > I think this is the central requirement. > > ] > > > > how would we separate the two? > > We can separate the two in a lot of ways, depending on the > purpose for which authorization is needed. If you want to > know that someone can pay, and the credit card company says > they can pay, that is good enough. If you want assurance > that someone is authorized to see your documents, you need > some other sort of authorization; it still doesn't have to > be done by authenticating their identity. If you have an > access control list of authorized identities, then you can > use authentication. > > It seems to me that we don't need a general authorization > algorithm. We could use a general authentication algorithm, > but then we have to decide whether that implicitly solves > the authorization problem (whatever the latter is determined > to be). > > I believe that we can and should separate authorization and > authentication for the purpose of context transfer. All that > matters is that the requester is the same node that used to > own the context at the previous access router. It doesn't > really matter what IP address belongs to the requester (for > this purpose of authorizing a context transfer). > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F2B1.FB267A70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments Re: [seamoby] ct problem statement

Madjid, Charlie, et al:

  Madjid, I think you have captured the essence = of the real issue. Authentication
and authorization are different, but for the most = part, authorization has
never really been needed for the internet, mainly = for the reasons you describe.

  The real interesting issue (besides how to = authorize every doorknob and
aircraft carrier on the planet), is whether, in a = mobile environment, how often
one needs to authenticate.

  Consider that a mobile node travelling through = the network will, with each
handover, open up opportunities for an interloper to = steal a service, if that
service is only authorized and the service user is = not authenticated.

  The opposite is also true: if the mobile node = is not re-authorized with each
handover, does this not open up the opportunity for = the authenticated node to
steal service it has not been authorized to = use?

  I do not believe that there are any easy = answers to these questions. Certainly,
tight security imposes greater complexity on the = network and sometimes, introduces
performance degradation. And the cost of security is = inevitably passed on to the
consumer.

  I haven't followed the = "authorization" discussion in AAA, but from the = postings
to this list is does sound that there is no solution = on the horizon (please correct
me if I am mistaken). It would seem that for a = mobile solution, the preferred approach
would incorporate some sort of = "authorization" tokens that would could be passed between ARs = as part of the mobile node's context (in a secure fashion of course). = There would have to be a tight association maintained between the = authentication information and these authorization tokens. If this is = the best approach, then once again, it would be difficult to = distinguish authentication from authorization.

  Just some thoughts.

Cheers,
Gary



> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Monday, June 11, 2001 2:55 PM
> To: 'Charles E. Perkins'; Nakhjiri = Madjid-MNAKHJI1
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem = statement
>
>
> Hello Charlie,
>
> I must appologize for not reading the rest of = the thread
> before sending this email, here it goes = anyway.
> Let me first clear a few points based on my = understanding,
> so you can tell me if I am correct or = not:
>
> 1-I would say that authentication is to say = that the authenticating
> party shows evidence that he (put a /she from = now on)
>  is actually who he says he is, the = credential is an ID/
> password/ keys...
>
> 2-Authorization, would then be the step = afterward;
> The network says, ok now I know, who the party = that
>  just authenticated itself is, but  =
> IS the party authorized to use the service he = is requesting?
>  for example this would be applicable = when
> a network provides various level of = service.
>
> 3-Generally,(I think) today in most of cases, = the networks
> authenticate
> and authorize the user at the same time, of = many reasons that you
> know much better than me: say either, they = don't offer too many
> different kinds of services, QoS is not = implemented in internet,
> so the cost of using different services is the = same for the ISP
> (but we all know this is not true with your = cable company, you want
> more movie channels, you pay more :) )
> So in effect, when the network authenticates = and authorizes
> at the same
> time, the credentials used for authentication = and
> authorization are the
> same.
>
> 4-If you would need to authenticate and = authorize separately, then
> the credentials and processes need to be = different.
>
> Impact on context transfer security and its = immunity against DoS:
> Say the two ARs are pre-authenticated, you have = a secure pipe between
> the ARs based on their identities and = authentication keys.
> You use this pipe for context transfer, so = nobody besides the ARs
> can do a context transfer, unless they are able = to spoof ARs
> ID/auth key...
> But this does not prevent an AR from doing a = DoS against the other,
> say I am an AR in network provider A' network = and can hand my
> mobile's
> context to  you, an AR in network provider = B's network. I am now
> angry because you did not meet our billing = agreement (sorry if this
> is a poor scenario for DoS). Now I can do a DoS = sending a lot of bogus
> context to you and bring you down.
>
> Is this an authentication problem? maybe = not.
> Can this be solved by an authorization prior to = each CT?
>
> I guess so, the AR is already authenticated (if = not, that would
> add a lot of delay to CT) but one = authentication (that last
> forever, does not solve DoS problems.
>
> And I don't know why you say authentication is = not important
> but authorization is a central requirement for = CT?
>
> I am no expert in AAA, but The only place *I* = have seen
> different credentials for authentication and = authorization
> discussed in AAAArch.
>
> Regards,
> Madjid
>
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Friday, June 08, 2001 6:12 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem = statement
>
>
>
> Hello Madjid,
>
> I think people usually want secure = authorization, and they
> ask for authentication because it's less = abstract somehow.
>
> You and I wrote:
>
> >> Sure. I get it, but my question = is:
> >> do we have different credential for = authentication and
> authorization
> today?
> >
> > It seems to me that today we typically use = authentication when
> > we really need authorization.  I = guess the theory is that if you
> > really know who is on the other side of = the communiations fence,
> > you'll be able to track them down if = anything goes wrong.
>
> Then you wrote:
>
> > That was exactly my point, today there is = no difference between
> > the credential
>
> I'm not very clear on what you mean.  If = you mean that today people
> usually accept authentication credentials as = good enough for
> authorization,
> then I reckon that may be true, but I am not = sure why it is relevant
> to the discussion we were having.
>
> > The reason that I asked the = question
> > was your following answers to Phil:
> >
> > [
> > > Is authentication needed?
> >
> > Probably not.
> >
> > > Is authorization needed?
> >
> > I think this is the central = requirement.
> > ]
> >
> > how would we separate the two?
>
> We can separate the two in a lot of ways, = depending on the
> purpose for which authorization is = needed.  If you want to
> know that someone can pay, and the credit card = company says
> they can pay, that is good enough.  If you = want assurance
> that someone is authorized to see your = documents, you need
> some other sort of authorization; it still = doesn't have to
> be done by authenticating their identity.  = If you have an
> access control list of authorized identities, = then you can
> use authentication.
>
> It seems to me that we don't need a general = authorization
> algorithm.  We could use a general = authentication algorithm,
> but then we have to decide whether that = implicitly solves
> the authorization problem (whatever the latter = is determined
> to be).
>
> I believe that we can and should separate = authorization and
> authentication for the purpose of context = transfer.  All that
> matters is that the requester is the same node = that used to
> own the context at the previous access = router.  It doesn't
> really matter what IP address belongs to the = requester (for
> this purpose of authorizing a context = transfer).
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F2B1.FB267A70-- From owner-seamoby@diameter.org Mon Jun 11 16:50: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 QAA18745 for ; Mon, 11 Jun 2001 16:50:01 -0400 (EDT) Received: (qmail 17790 invoked by alias); 11 Jun 2001 20:35:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17784 invoked by uid 200); 11 Jun 2001 20:35:36 -0000 Received: (qmail 17776 invoked from network); 11 Jun 2001 20:35:32 -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; 11 Jun 2001 20:35:32 -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 f5BKjHE25845; Mon, 11 Jun 2001 16:45:17 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 11 Jun 2001 16:44:59 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 16:45:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CD6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" , Arthur Ross Cc: Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Mon, 11 Jun 2001 16:44:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F2B7.604D4EB0" 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_01C0F2B7.604D4EB0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 11, 2001 3:57 PM > To: 'Pat Calhoun'; Arthur Ross > Cc: Charlie Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: [seamoby] RE: Authentication & Authorization > "in-the-large" was > Re: [seamob y] ct problem statement > *snip* > > 2- Why some people think authentication is not important, while > authorization > is central for CT. Just to clarify this for myself: I didn't hear anyone say that authentication was not important. And perhaps this is where the confusion began. I thought I heard it being stated that the mobile's authentication had to be conveyed to the new AR. This could be done either by moving the mobile's authentication with the mobile's context, or by a transferrence through a trust relationship between the two ARs (the idea being that if A trusts B and B trust C then A should trust C?). The latter proposal brought out a discussion of authentication between ARs, and how the ARs within one administrative domain should have an implicit trust, and thus "authentication between ARs was not necessary". I am not sure how one would mount a DOS using CT without first gaining access to one or more of the ARs to manipulate the CT stacks. Expressed another way, to introduce a bogus CTP stream into the network, I would presumably have to inject the stream through the edge of the network, but the network edges should not be allowing CTP through interfaces that talk to other networks (or hosts), unless those networks have also established authentication/authorization on that interface. (In the case of an ad-hoc wireless network, the authentication of the ARs becomes a very tricky issue, and one I still feel is outside of the scope for CT). The question also came up of whether the receiving AR needed to authorize the MN for the services and service features that were supported by the transferred context. I happen to believe that within a single administration domain, the ARs should be assumed to be trusted entities, and the authorization and authentication information for an MN should be transferred as part of the context. I believe that authentication is necessary to prevent DOS, and authorization is necessary to prevent TOS (theft of service). Since CT happens only between AR's, in the intranet wireline case, I don't see the need for extra "CT" security, other then that which is usually provided when shipping this information around an administrative domain. I should point out that "authorization" to use a service at an AR does not imply that the AR has the capacity to provide the service to a particular mobile's traffic (it must have the capability, otherwise the authorization should have failed). I hope this makes sense. Gary > > If people cannot contribute to the CT DoS discussion, I suggest they > do cryptography discussion to a security mailing list, before > Pat kills > this thread. > > We are just trying to get CT PS ready for shipping. > > Thank you, > Madjid > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, June 11, 2001 2:04 PM > To: Arthur Ross > Cc: Pat Calhoun; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: Re: Authentication & Authorization "in-the-large" was Re: > [seamoby] ct problem statement > > > On Mon, Jun 11, 2001 at 11:30:21AM -0700, Arthur Ross wrote: > > Au contraire, Pat - > > Je ne pense pas. > > > I keep thinking that a good illustrative, prehistoric > example/philosophical > > model of the kind of thing I am thinking of is the ol' Unix > heirarchical > > file system. Everything has a nonad [a word I just invented, meaning > "group > > of nine"] of priviledge flags, corresponding to all > possible combinations > > of {read,modify,execute} with {owner, group, world}. In this view, > > authentication determines which of the three categories an > supplicant > > belongs to, and authorization says which of the three actions he can > > perform. Attached are the owner and group IDs. > > I wonder why this thread even exists, but I find myself > having to correct > your example above. The very fact that a set of permissions > have been setup > on a file is NOT authentication. Before I even get access to > the said files, > there is another program, Unix login, which checks my > credentials, and then > executes the shell with my user and group id. Requesting > access to the file > is an authorization decision on the part of the OS. Do I have > access to the > file? > What is my user id? group id? > > Obviously, we aren't going to agree on the very fundamental difference > between > authorization and authentication, and we can just agree to disagree. > > PatC > ------_=_NextPart_001_01C0F2B7.604D4EB0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] RE: Authentication & Authorization = "in-the-large" was Re: [seamob y] ct problem = statement

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Monday, June 11, 2001 3:57 PM
> To: 'Pat Calhoun'; Arthur Ross
> Cc: Charlie Perkins; Kulwinder Atwal; = 'seamoby';
> wirelessinternet@internet.motlabs.com
> Subject: [seamoby] RE: Authentication & = Authorization
> "in-the-large" was
> Re: [seamob y] ct problem statement
>
*snip*
>      
> 2- Why some people think authentication is not = important, while
> authorization
> is central for CT.

Just to clarify this for myself: I didn't hear anyone = say that authentication
was not important. And perhaps this is where the = confusion began. I thought
I heard it being stated that the mobile's = authentication had to be conveyed to
the new AR. This could be done either by moving the = mobile's authentication with the mobile's context, or by a = transferrence through a trust relationship between the two ARs (the = idea being that if A trusts B and B trust C then A should trust = C?).

The latter proposal brought out a discussion of = authentication between ARs, and how the ARs within one administrative = domain should have an implicit trust, and thus "authentication = between ARs was not necessary". 

I am not sure how one would mount a DOS using CT = without first gaining access to one or more of the ARs to manipulate = the CT stacks. Expressed another way, to introduce a bogus CTP stream = into the network, I would presumably have to inject the stream through = the edge of the network, but the network edges should not be allowing = CTP through interfaces that talk to other networks (or hosts), unless = those networks have also established authentication/authorization on = that interface.

(In the case of an ad-hoc wireless network, the = authentication of the ARs becomes a very tricky issue, and one I still = feel is outside of the scope for CT).

The question also came up of whether the receiving AR = needed to authorize the MN for the services and service features that = were supported by the transferred context. I happen to believe that = within a single administration domain, the ARs should be assumed to be = trusted entities, and the authorization and authentication information = for an MN should be transferred as part of the context. I believe that = authentication is necessary to prevent DOS, and authorization is = necessary to prevent TOS (theft of service). Since CT happens only = between AR's, in the intranet wireline case, I don't see the need for = extra "CT" security, other then that which is usually = provided when shipping this information around an administrative = domain.

I should point out that "authorization" to = use a service at an AR does not imply that the AR has the capacity to = provide the service to a particular mobile's traffic (it must have the = capability, otherwise the authorization should have failed).

I hope this makes sense.

Gary


>
> If people cannot contribute to the CT DoS = discussion, I suggest they
> do cryptography discussion to a security = mailing list, before
> Pat kills
> this thread.
>
> We are just trying to get CT PS ready for = shipping.
>
> Thank you,
> Madjid
>
>
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Monday, June 11, 2001 2:04 PM
> To: Arthur Ross
> Cc: Pat Calhoun; Charlie Perkins; Kulwinder = Atwal; 'seamoby';
> wirelessinternet@internet.motlabs.com
> Subject: Re: Authentication & Authorization = "in-the-large" was Re:
> [seamoby] ct problem statement
>
>
> On Mon, Jun 11, 2001 at 11:30:21AM -0700, = Arthur Ross wrote:
> > Au contraire, Pat -
>
> Je ne pense pas.
>
> > I keep thinking that a good illustrative, = prehistoric
> example/philosophical
> > model of the kind of thing I am thinking = of is the ol' Unix
> heirarchical
> > file system. Everything has a nonad [a = word I just invented, meaning
> "group
> > of nine"] of priviledge flags, = corresponding to all
> possible combinations
> > of {read,modify,execute} with {owner, = group, world}. In this view,
> > authentication determines which of the = three categories an
> supplicant
> > belongs to, and authorization says which = of the three actions he can
> > perform. Attached are the owner and group = IDs.
>
> I wonder why this thread even exists, but I = find myself
> having to correct
> your example above. The very fact that a set of = permissions
> have been setup
> on a file is NOT authentication. Before I even = get access to
> the said files,
> there is another program, Unix login, which = checks my
> credentials, and then
> executes the shell with my user and group id. = Requesting
> access to the file
> is an authorization decision on the part of the = OS. Do I have
> access to the
> file?
> What is my user id? group id?
>
> Obviously, we aren't going to agree on the very = fundamental difference
> between
> authorization and authentication, and we can = just agree to disagree.
>
> PatC
>

------_=_NextPart_001_01C0F2B7.604D4EB0-- From owner-seamoby@diameter.org Mon Jun 11 17:19: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 RAA19255 for ; Mon, 11 Jun 2001 17:19:22 -0400 (EDT) Received: (qmail 18439 invoked by alias); 11 Jun 2001 21:07:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18433 invoked by uid 200); 11 Jun 2001 21:07:48 -0000 Received: (qmail 18428 invoked from network); 11 Jun 2001 21:07:46 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 21:07:46 -0000 Received: from [206.112.126.100] ([206.112.126.100] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9610411; Mon, 11 Jun 2001 17:17:07 -0400 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1219828217==_ma============" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> Date: Mon, 11 Jun 2001 14:17:55 -0700 To: "Gary Kenward" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" From: Arthur Ross Subject: RE: Comments Re: [seamoby] ct problem statement Cc: "'seamoby'" Sender: owner-seamoby@diameter.org Precedence: bulk --============_-1219828217==_ma============ Content-Type: text/plain; charset="us-ascii" At 13:06 -0700 06/11/2001, Gary Kenward wrote: >It would seem that for a mobile solution, the preferred approach >would incorporate some sort of "authorization" tokens that would could be >passed between ARs as part of the mobile node's context (in a secure >fashion of course). There would have to be a tight association maintained >between the authentication information and these authorization tokens. If >this is the best approach, then once again, it would be difficult to >distinguish authentication from authorization. > Gary et al: This is very close to what I have long thought might be a good solution to this problem, i.e. the notion of a "token" that the MN might carry around from AR to AR, presenting it as a sort of "ticket for service". The token would be some sort of public-key thingy, which would be delivered to the MN upon successful initial authentication and, possibly, authorization. It, or some complementary key variable might also be pre-distributed by the network to neighbor ARs (for suitable definitions of "neighbor") in anticipation of possible movement. Successful use upon change of access point would require some sort of combination of a "secret" in the MN with the over-the-air token, perhaps some sort of challenge-response technique. ... but we digress into solution space .... What this is about is creating a formalism for "trust propagation" in ways that are cryptographically secure against the well-known threats, e.g. hijacking the channel, spoofing, man-in-the-middle, etc. There are, BTW, already some ways of coping with the "aging" of the credential, such as the cellular authentication standards, which permit out of the blue challenges at the network's whim. Similar approaches might be ok here, if one is concerned with performance (speed of handover, QoS) vs security ... Sort of a Ronnie Reagan principle of CT: "Trust but verify." :-) -- ahmr --============_-1219828217==_ma============ Content-Type: text/enriched; charset="us-ascii" At 13:06 -0700 06/11/2001, Gary Kenward wrote: It would seem that for a mobile solution, the preferred approach would incorporate some sort of "authorization" tokens that would could be passed between ARs as part of the mobile node's context (in a secure fashion of course). There would have to be a tight association maintained between the authentication information and these authorization tokens. If this is the best approach, then once again, it would be difficult to distinguish authentication from authorization. Gary et al: This is very close to what I have long thought might be a good solution to this problem, i.e. the notion of a "token" that the MN might carry around from AR to AR, presenting it as a sort of "ticket for service". The token would be some sort of public-key thingy, which would be delivered to the MN upon successful initial authentication and, possibly, authorization. It, or some complementary key variable might also be pre-distributed by the network to neighbor ARs (for suitable definitions of "neighbor") in anticipation of possible movement. Successful use upon change of access point would require some sort of combination of a "secret" in the MN with the over-the-air token, perhaps some sort of challenge-response technique. ... but we digress into solution space .... What this is about is creating a formalism for "trust propagation" in ways that are cryptographically secure against the well-known threats, e.g. hijacking the channel, spoofing, man-in-the-middle, etc. There are, BTW, already some ways of coping with the "aging" of the credential, such as the cellular authentication standards, which permit out of the blue challenges at the network's whim. Similar approaches might be ok here, if one is concerned with performance (speed of handover, QoS) vs security ... Sort of a Ronnie Reagan principle of CT: "Trust but verify." :-) -- ahmr --============_-1219828217==_ma============-- From owner-seamoby@diameter.org Mon Jun 11 17:22: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 RAA19292 for ; Mon, 11 Jun 2001 17:22:09 -0400 (EDT) Received: (qmail 18774 invoked by alias); 11 Jun 2001 21:09:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18766 invoked by uid 200); 11 Jun 2001 21:09:55 -0000 Received: (qmail 18758 invoked by uid 500); 11 Jun 2001 21:09:53 -0000 Date: Mon, 11 Jun 2001 14:09:53 -0700 From: Pat Calhoun To: Arthur Ross Cc: Gary Kenward , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby'" Subject: Re: Comments Re: [seamoby] ct problem statement Message-ID: <20010611140953.R17928@charizard.diameter.org> Mail-Followup-To: Arthur Ross , Gary Kenward , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@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: ; from a.ross@ieee.org on Mon, Jun 11, 2001 at 02:17:55PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 11, 2001 at 02:17:55PM -0700, Arthur Ross wrote: > At 13:06 -0700 06/11/2001, Gary Kenward wrote: > > > It would seem that for a mobile solution, the preferred approach > > would incorporate some sort of "authorization" tokens that would > > could be passed between ARs as part of the mobile node's context > > (in a secure fashion of course). There would have to be a tight > > association maintained between the authentication information and > > these authorization tokens. If this is the best approach, then once > > again, it would be difficult to distinguish authentication from > > authorization. > > > > > Gary et al: > > This is very close to what I have long thought might be a good solution > to this problem, i.e. the notion of a "token" that the MN might carry > around from AR to AR, presenting it as a sort of "ticket for service". > The token would be some sort of public-key thingy, which would be > delivered to the MN upon successful initial authentication and, > possibly, authorization. It, or some complementary key variable might > also be pre-distributed by the network to neighbor ARs (for suitable > definitions of "neighbor") in anticipation of possible movement. > Successful use upon change of access point would require some sort of > combination of a "secret" in the MN with the over-the-air token, > perhaps some sort of challenge-response technique. > > ... but we digress into solution space .... indeed, and it is interesting that I proposed something very similar in MIP at least 2 years ago, and it was never adopted as a WG document :( PatC From owner-seamoby@diameter.org Mon Jun 11 19:27: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 TAA20614 for ; Mon, 11 Jun 2001 19:27:40 -0400 (EDT) Received: (qmail 19888 invoked by alias); 11 Jun 2001 23:14:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19882 invoked by uid 200); 11 Jun 2001 23:14:10 -0000 Received: (qmail 19877 invoked from network); 11 Jun 2001 23:14:07 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jun 2001 23:14:07 -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 QAA01632; Mon, 11 Jun 2001 16:24:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5BNO5Z24663; Mon, 11 Jun 2001 16:24:05 -0700 X-mProtect: Mon, 11 Jun 2001 16:24:05 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsjRd6F; Mon, 11 Jun 2001 16:24:03 PDT Message-ID: <3B255313.A780A5C6@iprg.nokia.com> Date: Mon, 11 Jun 2001 16:24:03 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Kulwinder Atwal , "'Charles E. Perkins'" , "'seamoby'" Subject: Re: [seamoby] Authorization vs. authentication References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FD0@NEPTUNE.zucotto.com> <15139.32930.576097.145900@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Sometimes, authorization is implicit in the process of authentication. When the bartender okeys your id (authentication), you get authorization to consume alcohol, as much as you can handle I guess, as long as you are accountable to paying. Similarly, it is possible that if authentication succeeds, then the message type and content allow implicit authorization, weak or otherwise. Regards, -Rajeev Michael Thomas wrote: > Exactly. Something to note is that authentication > doesn't imply cryptographic authentication or even > strong authentication. It's just the process of > identifying an entity using some methodology, > including sticking a key into a lock and having > the tumblers line up (shared secret), looking > across the counter to visually cross check a > license (third party through DMV), searching a > finger print database for a match from a crime > scene (third party through cops), accepting your > mother's birth name and your social security > number to issue a credit card (very weak form of > shared secret), public key digital signatures > verified through a private database of public keys > (strong, quasi shared secret) or digital > signatures over X.509 certificates (strong, third > party). > > None of these has the least bit to do with > authorization, and in fact just because you can be > authenticated in one realm implies that you should > be _authorized_ in another realm. For example, I > have a shared secret between my key and my door > lock. Presentation of that key to a bank teller > to, oh say, get $18,000,000 is not going to be > authorized because of an authentication > failure. The reason is not because the key was > bogus or anything like that, it's because the > realm I was trying to authenticate myself in does > not have any trust relationship with the door > lock's realm. > > Note also that the ultimate authorization of my > $18,000,000 is by no means guaranteed even if I do > manage to properly authenticate in the bank's > realm: I need to have access via funds or credit > to that money. Notice that authorization checks > are necessarily a two step process: determine the > identity of the requestor within the realm, and > then determine whether the request from that > identity is allowable within the realm. Note also > that this has nothing to do with unique identites > either. In the case of my door lock, I may give > that shared secret to any number of humans I see > fit, which for the purposes of authentication > within my door lock's realm are equivalent. To > conclude this analogy, notice that mere insertion > of the key into my lock is not in and of itself > authorization; it is merely a potential. If I were > to throw a deadbolt or somehow override the > default authorization of allowing the bolt to be > retracted, the key would have authenticated itself > successfully to the lock, but it still wouldn't > have gained the necessary authorization to pass. > > Mike > > Kulwinder Atwal writes: > > I believe it has to do with the level of permission granted and the scope of > > permission granted. > > > > Just becuase your identity has been authenticated does not mean that you > > will recieve the highest level of permission and the widest scope of > > permission within the network. Your scope and level of permission will be > > appropriate with your job function/service aggreement. > > > > For example, a node belonging to a End-User will not be authorized to do the > > same things as a node belonging to the network administrator (higher > > permission level). > > > > Also, a node belonging to the network administrator will not be able to > > access and control the same financial resources as a node belonging to the > > Chief Financial Officer (Different Scope). The scope has to be related to > > the area of expertise. > > > > Consider a node that has been authenticated, but has an overdue bill. > > Should the Cellular Operator authorize the node to use wireless services > > anyway? > > > > Also, consider an employee that has been authenticated as being on the > > payroll, but is trying to access resources on the network that the employee > > is not qualified to control. For example, a production worker in a factory > > trying to change the software of a piece of machinery. > > > > A node may only be permitted to access the network at: > > > > - a certain time, > > - a certain place, > > - and use certain resources. > > > > The fact that the node has had its identity confirmed is but a single input > > into the authorization decision making process. > > > > - Kulwinder. > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > > > Sent: Saturday, June 09, 2001 9:24 PM > > > To: 'seamoby' > > > Subject: [seamoby] Authorization vs. authentication > > > > > > > > > > > > Hello folks, > > > > > > It seems to me that this issue is too important to leave unsettled. > > > I didn't find anything in the books I looked at to resolve the > > > issue, but it's true that I don't necessarily know which books > > > are best to consult. Help will be appreciated, at least by me. > > > If this mailing list is considered to be the wrong place for such > > > information, let me know and I'll not post any more requests. > > > > > > Roughly speaking, I understand a node to be "authorized" > > > if it has permission to do something. I understand the node > > > to be "authenticated" if its identify has been verified. > > > If that's wrong, then I'd like to find out why. > > > > > > If it's right, then I'd like to find out why my discussion in > > > the message below should be considered uneducated, nonsensical > > > spew. > > > > > > If the bottom line is that these concepts are too hard for > > > people like me to understand, then the relevant charter items > > > should be moved to a working group where the right kind of > > > people are able to put in the effort to carry out the work. > > > I find that very hard to believe, but I'm willing to be > > > educated. > > > > > > Thanks for your consideration of my request. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > > > Michael Thomas wrote: > > > > > > > > Charlie, > > > > > > > > There is no point in arguing with you. I gave you > > > > the benefit of the doubt which was clearly not > > > > justified; this is security 101. There is nothing > > > > here in your rebuttal that shows that you have > > > > even elementary clues. Please take some time to > > > > educate yourself so that you can stop spewing this > > > > uneducated nonsense. As for my supposed free time, > > > > I have better uses for it. Maybe Dan Harkins would > > > > be willing to help you. > > > > > > > > Mike > > > > > > > > Charlie Perkins writes: > > > >> > > > >> > > > >>> Bzzt. You need authentication to know whether somebody's > > > >>> *impersonating* somebody who has authorization to do > > > >>> what the attacker wants to do. > > > >> > > > >> This is manifestly wrong, because one can carry something > > > >> that gives authorization for some resource without having > > > >> to be identified. > > > >> > > > >>>>> That was exactly my point, today there is no difference between > > > >>>>> the credential > > > >>>> > > > >>>> I'm not very clear on what you mean. If you mean that > > > today people > > > >>>> usually accept authentication credentials as good enough > > > for authorization, > > > >>>> then I reckon that may be true, but I am not sure why it > > > is relevant > > > >>>> to the discussion we were having. > > > >>> > > > >>> False. On your typical OS, you log in first. That is > > > >>> authentication first and foremost. ... > > > >> > > > >> This is a case where authentication provides sufficient > > > authorization > > > >> (according to the system design). > > > >> > > > >>> > > > >>>> We can separate the two in a lot of ways, depending on the > > > >>>> purpose for which authorization is needed. If you want to > > > >>>> know that someone can pay, and the credit card company says > > > >>>> they can pay, that is good enough. > > > >>> > > > >>> Uh, do you *really* think that credit card > > > >>> company doesn't attempt to authenticate you > > > >>> before they issue a card? All you're saying > > > >>> here is that you trust third party authentication > > > >>> (the credit card company) to make an authorization > > > >>> decision based on that identity (give service). > > > >> > > > >> It's often enough true, however, that someone can use a > > > >> credit card to get authorization for transfer of resources, > > > >> without being the owner of the card. And this is often > > > >> enough quite legitimate. > > > >> > > > >>>> If you want assurance > > > >>>> that someone is authorized to see your documents, you need > > > >>>> some other sort of authorization; it still doesn't have to > > > >>>> be done by authenticating their identity. > > > >>> > > > >>> False. Only a fool would authorize something > > > >>> without authenticating them first. > > > >> > > > >> False. I would authorize a lot of things if you give > > > >> me enough money, and I wouldn't care who you are. > > > >> > > > >>>> It seems to me that we don't need a general authorization > > > >>>> algorithm. > > > >>> > > > >>> There is no such thing. > > > >> > > > >> You seem so sure of yourself. > > > >> > > > >>>> We could use a general authentication algorithm, > > > >>>> but then we have to decide whether that implicitly solves > > > >>>> the authorization problem (whatever the latter is determined > > > >>>> to be). > > > >>> > > > >>> Authentication can never solve authorization. They're > > > >>> apples and oranges. > > > >> > > > >> What about your OS login example? Never say never. > > > >> It depends on the system design. > > > >> > > > >>>> I believe that we can and should separate authorization and > > > >>>> authentication for the purpose of context transfer. All that > > > >>>> matters is that the requester is the same node that used to > > > >>>> own the context at the previous access router. It doesn't > > > >>>> really matter what IP address belongs to the requester (for > > > >>>> this purpose of authorizing a context transfer). > > > >>> > > > >>> Pray tell, how can you tell if they are "the same node" > > > >>> if you don't authenticate them? Just because you claim > > > >>> to be the same node? > > > >> > > > >> If the node exhibits knowledge of a particular secret, I can > > > >> believe they are authorized no matter who they are. > > > >> > > > >>> Please people, I urge people who are confused > > > >>> to do some reading. This is really basic stuff > > > >>> and we're headed off into durable nonsense > > > >>> la-la land. > > > >> > > > >> It's always good to read and study and understand more. > > > >> It's furthermore typically good to help others understand, > > > >> given that time is available. You seem to have enough time > > > >> on your hands. > > > >> > > > >> ... > > > >> Charlie P. > > > From owner-seamoby@diameter.org Tue Jun 12 08:32: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 IAA13043 for ; Tue, 12 Jun 2001 08:32:58 -0400 (EDT) Received: (qmail 22543 invoked by alias); 12 Jun 2001 12:22:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22537 invoked by uid 200); 12 Jun 2001 12:22:04 -0000 Received: (qmail 22532 invoked from network); 12 Jun 2001 12:22:03 -0000 Received: from newdev.eecs.harvard.edu (HELO newdev.harvard.edu) (140.247.60.212) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 12:22:03 -0000 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA07314; Tue, 12 Jun 2001 08:31:37 -0400 (EDT) Date: Tue, 12 Jun 2001 08:31:37 -0400 (EDT) From: Scott Bradner Message-Id: <200106121231.IAA07314@newdev.harvard.edu> To: hannes@roesti.cc, mat@cisco.com Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement Cc: mark.smith@comdev.cc, seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk PBK still uses a return routability test as the basis of the authentication. reminder - PBK's mission is to say that the node that requested the rebinding was the same node that has been using the old binding it was not (specifically not) trying to say who that is Scott From owner-seamoby@diameter.org Tue Jun 12 09:35:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14678 for ; Tue, 12 Jun 2001 09:35:09 -0400 (EDT) Received: (qmail 23093 invoked by alias); 12 Jun 2001 13:23:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23087 invoked by uid 200); 12 Jun 2001 13:23:46 -0000 Received: (qmail 23082 invoked from network); 12 Jun 2001 13:23:44 -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; 12 Jun 2001 13:23:44 -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 f5CDXUE09615 for ; Tue, 12 Jun 2001 09:33:31 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 12 Jun 2001 09:32:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 09:32:59 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CDA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" , "'seamoby-context'" Subject: [seamoby] DOS in wireless Date: Tue, 12 Jun 2001 09:32:52 -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 We all got wrapped up in this discussion of DOS and, in particular, CT related DOS. It put a smile on my face last night to recall that with wireless, it is almost trivial to mount a DOS attack without referring to any protocol nor invading the access network. The traditional term is "jamming". With the trend to lower power devices, it would not be difficult nor expensive to mount a fairly widespread, difficult to stop attack (and I'll stop there). Perhaps too much attention is being given to putting bars on the windows when the front door is missing. Gary From owner-seamoby@diameter.org Tue Jun 12 09:43: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 JAA14845 for ; Tue, 12 Jun 2001 09:42:59 -0400 (EDT) Received: (qmail 23674 invoked by alias); 12 Jun 2001 13:31:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23662 invoked by uid 200); 12 Jun 2001 13:31:58 -0000 Received: (qmail 23652 invoked by uid 500); 12 Jun 2001 13:31:55 -0000 Date: Tue, 12 Jun 2001 06:31:55 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'seamoby'" , "'seamoby-context'" Subject: Re: [seamoby] DOS in wireless Message-ID: <20010612063154.E17928@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'seamoby' , 'seamoby-context' References: <9FBD322B7824D511B36900508BF93C9C9F5CDA@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: <9FBD322B7824D511B36900508BF93C9C9F5CDA@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jun 12, 2001 at 09:32:52AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary Kenward wrote: > We all got wrapped up in this discussion of DOS and, in particular, CT > related DOS. It put a smile on my face last night to recall that with > wireless, it is almost trivial to mount a DOS attack without referring > to any protocol nor invading the access network. The traditional term is > "jamming". With the trend to lower power devices, it would not be difficult > nor expensive to mount a fairly widespread, difficult to stop attack (and > I'll stop there). > > Perhaps too much attention is being given to putting bars on the windows > when the front door is missing. I see your point, but the IESG's concern is that no new protocol introduce new DoS attacks. We cannot do anything about existing ones, much less physical ones, but we do have to make sure that we don't open up new holes. Having said that, given that we expect all data to be protected (and presumably replay protected), we will be quite safe. PatC From owner-seamoby@diameter.org Tue Jun 12 10:07: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 KAA15562 for ; Tue, 12 Jun 2001 10:07:21 -0400 (EDT) Received: (qmail 24343 invoked by alias); 12 Jun 2001 13:54:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24336 invoked by uid 200); 12 Jun 2001 13:54:35 -0000 Received: (qmail 24326 invoked from network); 12 Jun 2001 13:54:32 -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; 12 Jun 2001 13:54:32 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CE4DE15830; Tue, 12 Jun 2001 10:04:13 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 12 Jun 2001 10:03:50 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 10:03:51 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CDC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby] DOS in wireless Date: Tue, 12 Jun 2001 10:03:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F348.80911300" 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_01C0F348.80911300 Content-Type: text/plain; charset="ISO-8859-1" Well, if I may be so bold, (in the hope that the ads are watching): I would say for wireless, this strategy should be considered in light of the reality of the situation. There is definitely a need for security to prevent theft of service, provide privacy, etc. But perhaps the intensity of concern over DOS in the wireless access network needs to be mitigated somewhat. Putting additional watertight bulk-heads in the Titanic would not have saved it from sinking ;^}. Naturally, the situation is even more dramatic in all-wireless networks. Anyway, enough. Just wanted to make the observation. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 12, 2001 9:32 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby'; 'seamoby-context' > Subject: Re: [seamoby] DOS in wireless > > > On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary Kenward wrote: > > We all got wrapped up in this discussion of DOS and, in > particular, CT > > related DOS. It put a smile on my face last night to recall > that with > > wireless, it is almost trivial to mount a DOS attack > without referring > > to any protocol nor invading the access network. The > traditional term is > > "jamming". With the trend to lower power devices, it would > not be difficult > > nor expensive to mount a fairly widespread, difficult to > stop attack (and > > I'll stop there). > > > > Perhaps too much attention is being given to putting bars > on the windows > > when the front door is missing. > > I see your point, but the IESG's concern is that no new > protocol introduce > new DoS attacks. We cannot do anything about existing ones, > much less physical > ones, but we do have to make sure that we don't open up new holes. > > Having said that, given that we expect all data to be > protected (and presumably > replay protected), we will be quite safe. > > PatC > ------_=_NextPart_001_01C0F348.80911300 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] DOS in wireless

Well, if I may be so bold, (in the hope that the ads = are watching): I would say for wireless, this strategy should be = considered in light of the reality of the situation.

There is definitely a need for security to prevent = theft of service, provide privacy, etc. But perhaps the intensity of = concern over DOS in the wireless access network needs to be mitigated = somewhat. Putting additional watertight bulk-heads in the Titanic would = not have saved it from sinking ;^}.

Naturally, the situation is even more dramatic in = all-wireless networks.

Anyway, enough. Just wanted to make the = observation.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Tuesday, June 12, 2001 9:32 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'; 'seamoby-context'
> Subject: Re: [seamoby] DOS in wireless
>
>
> On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary = Kenward wrote:
> > We all got wrapped up in this discussion = of DOS and, in
> particular, CT
> > related DOS. It put a smile on my face = last night to recall
> that with
> > wireless, it is almost trivial to mount a = DOS attack
> without referring
> > to any protocol nor invading the access = network. The
> traditional term is
> > "jamming". With the trend to = lower power devices, it would
> not be difficult
> > nor expensive to mount a fairly = widespread, difficult to
> stop attack (and
> > I'll stop there).
> >
> > Perhaps too much attention is being given = to putting bars
> on the windows
> > when the front door is missing.
>
> I see your point, but the IESG's concern is = that no new
> protocol introduce
> new DoS attacks. We cannot do anything about = existing ones,
> much less physical
> ones, but we do have to make sure that we don't = open up new holes.
>
> Having said that, given that we expect all data = to be
> protected (and presumably
> replay protected), we will be quite = safe.
>
> PatC
>

------_=_NextPart_001_01C0F348.80911300-- From owner-seamoby@diameter.org Tue Jun 12 10:11: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 KAA15697 for ; Tue, 12 Jun 2001 10:11:16 -0400 (EDT) Received: (qmail 24880 invoked by alias); 12 Jun 2001 14:00:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24869 invoked by uid 200); 12 Jun 2001 14:00:12 -0000 Received: (qmail 24857 invoked by uid 500); 12 Jun 2001 14:00:09 -0000 Date: Tue, 12 Jun 2001 07:00:09 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , "'seamoby'" , "'seamoby-context'" Subject: Re: [seamoby-context] RE: [seamoby] DOS in wireless Message-ID: <20010612070009.J17928@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , 'seamoby' , 'seamoby-context' References: <9FBD322B7824D511B36900508BF93C9C9F5CDC@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: <9FBD322B7824D511B36900508BF93C9C9F5CDC@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jun 12, 2001 at 10:03:48AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 12, 2001 at 10:03:48AM -0400, Gary Kenward wrote: > Well, if I may be so bold, (in the hope that the ads are watching): I would > say for wireless, this strategy should be considered in light of the reality > of the situation. > There is definitely a need for security to prevent theft of service, provide > privacy, etc. But perhaps the intensity of concern over DOS in the wireless > access network needs to be mitigated somewhat. Putting additional watertight > bulk-heads in the Titanic would not have saved it from sinking ;^}. > > Naturally, the situation is even more dramatic in all-wireless networks. > > Anyway, enough. Just wanted to make the observation. and I actually go appreciate the observation. However, our work here is not to ensure against theft of service, etc. What we need to do is guard against someone mounting a specific attack on CT. So, don't view this as a wireless attack, but rather one on the IP network. Of course, if a wireless attack can be mounted that will cause CT to behave REALLY badly (e.g. take down service), then we already need to identify those. As far as other DoS, they can simply flood ping us, and there's nothing much we could do :( PatC From owner-seamoby@diameter.org Tue Jun 12 10:50: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 KAA16942 for ; Tue, 12 Jun 2001 10:49:54 -0400 (EDT) Received: (qmail 25568 invoked by alias); 12 Jun 2001 14:30:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25560 invoked by uid 200); 12 Jun 2001 14:30:09 -0000 Received: (qmail 25551 invoked from network); 12 Jun 2001 14:30:06 -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; 12 Jun 2001 14:30:06 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CEdsE21764 for ; Tue, 12 Jun 2001 10:39:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 12 Jun 2001 10:39:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 10:39:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CDE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: "'seamoby-context'" , "'Allison Mankin'" Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Date: Tue, 12 Jun 2001 10:39:37 -0400 Importance: high X-Priority: 1 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 Below is a revision of the second version of the problem statement draft. I have tried to accommodate Allisons' wishes, as well as John's concern over explicitly referring to DOS (I hope what I have provided is sufficient John). Bash away. Gary ============================================================================ Context and Micro-mobility Routing Working Group O. H. Levkowetz Internet Draft ABNW draft-ietf-seamoby-context-transfer-problem- P. R. Calhoun 02.txt Sun MicroSystems, Inc Expires: December 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 June 2001 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Levkowetz et al. [Page 1] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Abstract 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. Table of Contents 1 Introduction...................................................2 2 Reference Definitions..........................................3 3 The Need for Context Transfer..................................4 3.1 Scope of the Context Transfer Solution .....................5 3.2 Reference Architectures ....................................6 4 A Description of Context.......................................6 4.1 Feature ....................................................6 4.2 Feature Context ............................................7 4.3 Microflow Context ..........................................7 4.4 Common Context .............................................7 4.5 Examples of Feature Context ................................8 5 Context Transfer and Mobility..................................8 6 Forwarding Node Capabilities...................................8 7 Inter-technology Context Transfers.............................8 8 Applicability..................................................9 9 Performance Considerations.....................................9 10 Security Considerations.......................................9 11 Recommendations..............................................10 1 Introduction There are a large number of IP access networks that support hosts that are mobile. 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 a host may change frequently and rapidly. In networks where the hosts are mobile, the forwarding path through the access network must often be redirected in order to deliver the host's IP traffic to the new point of access. The success of a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. Levkowetz et al. [Page 2] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt The information required in support of a specific forwarding treatment provided to IP traffic is part of the context for that traffic. This context is comprised of configuration and state information. To minimize the impact of a path change on an IP flow, the context used at the forwarding nodes along the original path, must be replicated at the forwarding nodes along the new path. The transfer of context information may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, Policy, and possibly sub-IP protocols and services such as PPP. Context transfer at a minimum will be used to replicate the configuration information needed to establish the respective protocols and services. In addition, it may also provide the capability to replicate state information, allowing stateful protocols and services at the new node to be activated along the new path with less delay and less signalling overhead. 2 Reference Definitions Mobile Node An IP node capable of changing its point of attachment to the network. The mobile node is usually an end user host, but may be a forwarding node for a network that is itself mobile. Forwarding Node A node that supports IP forwarding within the access network. This includes all routers, gateways, servers and other nodes within the network that have IP protocol stacks and forward IP traffic to and from a mobile node. A forwarding node will be connected to one or more other forwarding nodes. Some forwarding nodes will be connected to zero or more mobile nodes. The forwarding nodes that connect to mobile nodes will do so through a layer two entity that supports wireless communications. Microflow One useful definition for the fundamental unit of IP service is the microflow. RFC 2475 [1] defines a microflow as: A single instance of an application-to application flow of packets destined to or originated from a mobile device (MN or MH), which is identified by source address, source port, destination address, destination port and protocol id. Levkowetz et al. [Page 3] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt RFC 2207 [2] provides a definition of a microflow that applies to IPSec packets. It is based on the IPSec SPI found in the AH or ESP headers. Other methods for identifying for IP microflows may be defined in the future, e.g. the Ipv6 flow label. 3 The Need for Context Transfer In networks where the hosts are mobile, the forwarding path through the access network must often be redirected in order to deliver the host's IP traffic to the new point of access. The success of a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. Figure 1 and 2 below illustrate an example of a handover scenario. A mobile node, MN7, is shown attached to the Internet via an access network. The forwarding nodes, FN1 through to FN7 comprise a portion of this access network. FN1 and FN7 are the last forwarding nodes before the untethered link to MN7. This last link allows the nodes to move while maintaining connectivity to the edge of the access network - e.g. the last link is wireless. For simplicity, many details of a real access network topology have been left out of the diagrams. Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. It is presumable that FN1 and FN2 have been configured to provide specific forwarding services for MN7's traffic, and that some of these services may require state information to be maintained. MN7's traffic <------------------> ------- ------- [ MN7 ]<= = = =>| FN1 |=================| FN2 |======== ------- /------- / -------/ | FN4 | /-------\ / \ / \ -------/ \------- - - -| FN7 | | FN6 |---- ------- ------- Figure 1: Path Prior to Handover Levkowetz et al. [Page 4] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt When MN7's movement results in the link to FN1 to be replaced by a link to FN7, MN7's traffic must be re-directed along a new forwarding path, illustrated in Figure 2 as the path through FN7, FN4 and FN2. In many mobile networks, this handover can occur frequently, and sometimes with little or no warning. ------- ------- - - -| FN1 |----------------| FN2 |======== ------- //------- // MN7's traffic -------/ <-----------> | FN4 | //------\ MN7's traffic // \ <-----------> // \ -------/ \------- [ MN7 ]<= = = =>| FN7 | | FN6 |---- ------- ------- Figure 2: Path Re-Directed After Handover If the forwarding treatment provided to MN7's traffic is to be sustained, the support conditions at FN1 and FN2 must be reproduced at FN7 and FN4. At the very least, this requires that FN7 and FN4 be configured to provide the appropriate support to the traffic flow. However, establishing forwarding support along the new path through the use of IP signalling protocols would be relatively time consuming. In addition, given that some forwarding services may maintain state information, simply configuring FN7 and FN4 would not circumvent disruption of the services. Given that FN7 and FN4 support the same functionality as FN1, it should be possible to reproduce the needed support along the new forwarding path by capturing the salient information at FN1 as it exists just prior to the handover, and then use that information to replicate the state of FN1 at FN7 and FN4. 3.1 Scope of the Context Transfer Solution The information required to produce the necessary forwarding treatments at a node is referred to as the support "context". In order to replicate the context of one forwarding node at another forwarding node, an open, standard solution for context transfer must be developed. Levkowetz et al. [Page 5] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In addition, for a forwarding node to be able to interpret the transferred context, both the syntax and the semantics of the context information must be defined. Definition of the actual context information will be specific to the support feature being replicated, however, a generic container format of the payload of context transfer messages is required for inter-operability. 3.2 Reference Architectures The concept of the "forwarding node" is used here to describe the general context transfer problem. In different networks, the actual context transfer may take place between different entities within the network. In some cases the preferred context transfer peers might be the routers at the edge of the access network. In other situations, it may be more appropriate to transfer context between wireless access points that also support forwarding of IP packets. The context transfer solution will be applicable to any nodes that support forwarding of a mobile nodes IP traffic. 4 A Description of Context The term ` `context' ' pertains to all information required by a forwarding node specific to supporting the IP traffic for a particular mobile node. The context for a mobile node can be partitioned into three categories: - information required to provide generally support to the mobile node; - information required to provide common support to the mobile node's traffic; - information required to support specific features of the forwarding treatment for an IP microflow. 4.1 Feature A feature is an aspect of the IP forwarding treatment that is instantiated for each mobile node, and which may support one or more of the mobile nodes microflows. A feature must include associated configuration information: at the very least, some identification information for the mobile node, such as the mobile node's IP address. A feature may have associated state information. Levkowetz et al. [Page 6] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In other words, for the purpose of supporting mobility the features of interest all have context pertinent to the forwarding of a specific mobile nodes IP packets. Examples of features include: header compression, security, subscriber policy, and quality of service. Each feature is, in general, supported by an amalgamation of one or more protocols and associated local support mechanisms. As an example, header compression is a feature that consists of various "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP header compression, operating according to well-defined "protocols". Thus, an instance of a feature reflects the state associated with protocols and the corresponding mechanisms. 4.2 Feature Context Feature context is the condition or state of an instance of a particular feature. It represents the current evolution of the behaviour of that feature instance. At a given instant in time, feature context is represented by the values of the associated data elements. Some of the data elements associated with a feature are time invariant and, thus, represent the configuration of the feature instance. Other data elements, which are often referred to as the "state variables" for the feature instance, change value over time as a consequence of the various operations performed in support of the feature instance. A feature context is believed to be the smallest indivisible unit of context that can be transferred between forwarding nodes. 4.3 Microflow Context A microflow context is the collection of the various feature contexts associated with a single IP microflow. It is the smallest unit of context that must be transferred in order to re-establish support for the microflow at a forwarding node. 4.4 Common Context Some of the associated feature contexts may be applicable to more then one of the IP microflows comprising the mobile node's traffic. An example of this might be the authentication state for the mobile. This type of feature context is also required to support each microflow, but because of the multiplicity of the relationship to the mobile node's microflows, it would seem prudent to transfer one instance of the context, independent of the microflow context. Levkowetz et al. [Page 7] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt 4.5 Examples of Feature Context Some examples of feature contexts that are candidates for context transfer are given below. This list is provided solely to illustrate the nature of the context transfer problem domain. - encryption context; - authentication context; - authorization context; - accounting context; - header compression context; - quality of service context; - policy enforcement context; - multicast group membership; - buffer state; - sub-network layer context (e.g. PPP context). 5 Context Transfer and Mobility Context transfer is an enhancement to a mobility solution that is clearly most effective when used on a local scale between forwarding nodes within a subnetwork. However, with due consideration to the nature of the context and the requirements for transfer of that context, context transfer should be applicable between any two similar forwarding nodes. 6 Forwarding Node Capabilities Context transfer between two forwarding nodes is worthwhile only if the receiving node's capabilities are similar enough to those of the sending node that the received context can be utilized. This does not mean that the two nodes are identical in their implementation, nor does it even imply that they must have identical capabilities. A forwarding node that cannot make use of received context could, and should, refuse the transfer. This would result in a situation no different then mobile handover without context transfer. 7 Inter-technology Context Transfers The context transfer described here operates at the IP layer, and should be applicable to situations where the forwarding nodes are supporting different wireless link technologies. Levkowetz et al. [Page 8] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt An exception to this would be where sub-IP layer context is an intrinsic part of the forwarding treatment. In this situation, an interworking solution must be developed for sub-IP context transfer between the two technologies. This issue is outside the scope of the Seamoby working group. 8 Applicability The primary motivation for developing an IP context transfer assumes that service sustainment during handover is desirable. And yet, there may be situations where either the user or the access network would prefer to re-establish or re-negotiate a service or a service feature. For example, if the mobile node crosses administration domains where the operational policies change, negotiation of a different level of service may be required by the respective operators. More important, the concept of context transfer also assumes that the service is worth sustaining through a variety of handover scenarios, and that context transfer is the best approach. The former may not be true for certain types of service - for example, multicast, "push" information services. In addition, even if service level sustainment is desirable, context transfer may not be the most cost efficient solution. Alternatives to context transfer for sustaining services during handover are out of scope for the Seamoby working group. The possibility of other solutions is only noted here to emphasize that context transfer is but one of possibly many approaches. Finally, context transfer is an enhancement at the IP level to improve upon the performance of a handover between IP forwarding nodes. Many networks provide support for handover at the link layer, within and between subnetworks, and context transfer may not provide a significant improvement over the these link layer solutions. 9 Performance Considerations The purpose of context transfer is to sustain the services being provided to a mobile node's traffic during handover. It is essentially an enhancement to a mobility solution that ultimately must result in an improvement in handover performance. The various aspects of performance must be a prime consideration in the development of the context transfer solution. 10 Security Considerations Some of the considerations for context transfer security include: Levkowetz et al. [Page 9] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt - information privacy: the context may contain information which the end user would prefer to keep hidden from unauthorized viewers. - transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving forwarding node, and therefore could potentially affect the operation of the access network itself; the potential threats include denial of service and theft of service attacks; context transfer must only occur between forwarding nodes that have an established trust relationship. - security preservation: part of the context transfer may include information pertinent to a security association established between the mobile node and another entity on the network; for this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures. It is expected that the measures used to secure the transport of information between peers in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions. The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions. 11 Recommendations The Seamoby context transfer design team recommends the following: - investigation into candidates for context transfer - in particular, feature context transfer, and an analysis of the transfer requirements for each candidate; - the development of a framework and protocol(s) that will support the transfer of configuration and state context between the forwarding nodes of an IP network. The context transfer solution must interwork with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network. References Levkowetz et al. [Page 10] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt [1] Blake, et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. Authors' Addresses O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN Phone: +46 8 477 9942 EMail: henrik@levkowetz.com Pat R. Calhoun Network and Security Research Center, Sun Labs 15 Network Circle Menlo Park CA 94025 USA Phone: +1 650-786-7733 EMail: pcalhoun@eng.sun.com Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA Phone: +1 613-765-1437 EMail: gkenward@nortelnetworks.com Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA Phone: +1 613 763-6553 EMail: hmsyed@nortelnetworks.com Jukka Manner Department of Computer Science, University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND Levkowetz et al. [Page 11] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Phone: +358-9-191-44210 EMail: jmanner@cs.helsinki.fi Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA Phone: +1 847-632-5030 EMail: madjid.nakhjiri@motorola.com Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA Phone: +1 781 993 3627 EMail: govind.krishnamurthi@nokia.com Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA Phone: +1 650 625 2359 EMail: rajeev.koodli@nokia.com Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA Phone: +1 613 789 0090 EMail: kulwinder.atwal@zucotto.com Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA Phone: +1 408 525 5386 Levkowetz et al. [Page 12] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt EMail: mat@cisco.com Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA Phone: +1 805 544 1089 EMail: mat.horan@comdev.cc Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA EMail: phil_neumiller@3com.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Levkowetz et al. [Page 13] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Funding for the RFC editor function is currently provided by the Internet Society. Levkowetz et al. [Page 14] From owner-seamoby@diameter.org Tue Jun 12 11:07: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 LAA17289 for ; Tue, 12 Jun 2001 11:07:50 -0400 (EDT) Received: (qmail 26143 invoked by alias); 12 Jun 2001 14:56:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26137 invoked by uid 200); 12 Jun 2001 14:56:57 -0000 Received: (qmail 26129 invoked from network); 12 Jun 2001 14:56:56 -0000 Received: from mercury.sun.com (192.9.25.1) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 14:56:56 -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 IAA11720; Tue, 12 Jun 2001 08:07:23 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA04017; Tue, 12 Jun 2001 08:07:23 -0700 (PDT) Message-Id: <200106121507.IAA04017@heliopolis.eng.sun.com> Date: Tue, 12 Jun 2001 08:07:22 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: Comments Re: [seamoby] ct problem statement To: a.ross@ieee.org, pcalhoun@diameter.org Cc: gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: a6lI6LTvesKD/q65xviSlg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk >> This is very close to what I have long thought might be a good solution >> to this problem, i.e. the notion of a "token" that the MN might carry >> around from AR to AR, presenting it as a sort of "ticket for service". >> The token would be some sort of public-key thingy, which would be >> delivered to the MN upon successful initial authentication and, >> possibly, authorization. It, or some complementary key variable might >> also be pre-distributed by the network to neighbor ARs (for suitable >> definitions of "neighbor") in anticipation of possible movement. >> Successful use upon change of access point would require some sort of >> combination of a "secret" in the MN with the over-the-air token, >> perhaps some sort of challenge-response technique. >> >> ... but we digress into solution space .... > >indeed, and it is interesting that I proposed something very similar >in MIP at least 2 years ago, and it was never adopted as a WG document :( > I've also felt for about a year that such a token would go a long way to solving problems with authentication and authorization. I've proposed something like this on the BURP list. jak From owner-seamoby@diameter.org Tue Jun 12 11:22: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 LAA17606 for ; Tue, 12 Jun 2001 11:22:49 -0400 (EDT) Received: (qmail 26685 invoked by alias); 12 Jun 2001 15:11:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26679 invoked by uid 200); 12 Jun 2001 15:11:55 -0000 Received: (qmail 26671 invoked from network); 12 Jun 2001 15:11:53 -0000 Received: from thumper.research.telcordia.com (128.96.41.1) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 15:11:53 -0000 Received: from marvel.research.telcordia.com (marvel [192.4.16.140]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f5CFLlu10554; Tue, 12 Jun 2001 11:21:48 -0400 (EDT) Received: (from subir@localhost) by marvel.research.telcordia.com (8.8.8/8.8.8) id LAA29354; Tue, 12 Jun 2001 11:21:47 -0400 (EDT) Date: Tue, 12 Jun 2001 11:21:47 -0400 (EDT) From: Subir Das Message-Id: <1010612112147.ZM29352@marvel> In-Reply-To: James Kempf "Re: Comments Re: [seamoby] ct problem statement" (Jun 12, 8:07am) References: <200106121507.IAA04017@heliopolis.eng.sun.com> X-Mailer: Z-Mail (5.0.0 30July97) To: James Kempf , a.ross@ieee.org, pcalhoun@diameter.org Subject: Re: Comments Re: [seamoby] ct problem statement Cc: gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-seamoby@diameter.org Precedence: bulk James, On Jun 12, 8:07am, James Kempf wrote: > Subject: Re: Comments Re: [seamoby] ct problem statement > > >> This is very close to what I have long thought might be a good solution > >> to this problem, i.e. the notion of a "token" that the MN might carry > >> around from AR to AR, presenting it as a sort of "ticket for service". > >> The token would be some sort of public-key thingy, which would be > >> delivered to the MN upon successful initial authentication and, > >> possibly, authorization. It, or some complementary key variable might > >> also be pre-distributed by the network to neighbor ARs (for suitable > >> definitions of "neighbor") in anticipation of possible movement. > >> Successful use upon change of access point would require some sort of > >> combination of a "secret" in the MN with the over-the-air token, > >> perhaps some sort of challenge-response technique. > >> > >> ... but we digress into solution space .... > > > >indeed, and it is interesting that I proposed something very similar > >in MIP at least 2 years ago, and it was never adopted as a WG document :( > > > > I've also felt for about a year that such a token > would go a long way to solving problems with authentication and > authorization. I've proposed something like this on the BURP list. > > jak I agree. BURP will be able to provide this type of security association. Subir -- From owner-seamoby@diameter.org Tue Jun 12 11:28: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 LAA17643 for ; Tue, 12 Jun 2001 11:28:19 -0400 (EDT) Received: (qmail 27153 invoked by alias); 12 Jun 2001 15:16:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27147 invoked by uid 200); 12 Jun 2001 15:16:24 -0000 Received: (qmail 27139 invoked from network); 12 Jun 2001 15:16:22 -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; 12 Jun 2001 15:16:22 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CFQBE29328; Tue, 12 Jun 2001 11:26:11 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 12 Jun 2001 11:25:59 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 11:25:59 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CE2@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , a.ross@ieee.org, pcalhoun@diameter.org Cc: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, seamoby@diameter.org Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 12 Jun 2001 11:25:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F353.F6E74280" 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_01C0F353.F6E74280 Content-Type: text/plain; charset="ISO-8859-1" Great minds think alike. Too bad this isn't the AAA group ;^} Gary > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, June 12, 2001 11:07 AM > To: a.ross@ieee.org; pcalhoun@diameter.org > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Madjid.Nakhjiri@motorola.com; > charliep@iprg.nokia.com; seamoby@diameter.org > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > >> This is very close to what I have long thought might be a > good solution > >> to this problem, i.e. the notion of a "token" that the MN > might carry > >> around from AR to AR, presenting it as a sort of "ticket > for service". > >> The token would be some sort of public-key thingy, which would be > >> delivered to the MN upon successful initial authentication and, > >> possibly, authorization. It, or some complementary key > variable might > >> also be pre-distributed by the network to neighbor ARs > (for suitable > >> definitions of "neighbor") in anticipation of possible movement. > >> Successful use upon change of access point would require > some sort of > >> combination of a "secret" in the MN with the over-the-air token, > >> perhaps some sort of challenge-response technique. > >> > >> ... but we digress into solution space .... > > > >indeed, and it is interesting that I proposed something very similar > >in MIP at least 2 years ago, and it was never adopted as a > WG document :( > > > > I've also felt for about a year that such a token > would go a long way to solving problems with authentication and > authorization. I've proposed something like this on the BURP list. > > jak > > ------_=_NextPart_001_01C0F353.F6E74280 Content-Type: text/html; charset="ISO-8859-1" RE: Comments Re: [seamoby] ct problem statement

Great minds think alike.

Too bad this isn't the AAA group ;^}

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, June 12, 2001 11:07 AM
> To: a.ross@ieee.org; pcalhoun@diameter.org
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Madjid.Nakhjiri@motorola.com;
> charliep@iprg.nokia.com; seamoby@diameter.org
> Subject: Re: Comments Re: [seamoby] ct problem statement
>
>
>
> >> This is very close to what I have long thought might be a
> good solution
> >> to this problem, i.e. the notion of a "token" that the MN
> might carry
> >> around from AR to AR, presenting it as a sort of "ticket
> for service".
> >> The token would be some sort of public-key thingy, which would be
> >> delivered to the MN upon successful initial authentication and,
> >> possibly, authorization. It, or some complementary key
> variable might
> >> also be pre-distributed by the network to neighbor ARs
> (for suitable
> >> definitions of "neighbor") in anticipation of possible movement.
> >> Successful use upon change of access point would require
> some sort of
> >> combination of a "secret" in the MN with the over-the-air token,
> >> perhaps some sort of challenge-response technique.  
> >>
> >> ... but we digress into solution space ....
> >
> >indeed, and it is interesting that I proposed something very similar
> >in MIP at least 2 years ago, and it was never adopted as a
> WG document :(
> >
>
> I've also felt for about a year that such a token
> would go a long way to solving problems with authentication and
> authorization. I've proposed something like this on the BURP list.
>
>               jak
>
>

------_=_NextPart_001_01C0F353.F6E74280-- From owner-seamoby@diameter.org Tue Jun 12 11:31: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 LAA17699 for ; Tue, 12 Jun 2001 11:31:20 -0400 (EDT) Received: (qmail 27432 invoked by alias); 12 Jun 2001 15:18:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27427 invoked by uid 200); 12 Jun 2001 15:18:31 -0000 Received: (qmail 27412 invoked from network); 12 Jun 2001 15:18:28 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 15:18:28 -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 JAA26180; Tue, 12 Jun 2001 09:28:54 -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 IAA04605; Tue, 12 Jun 2001 08:28:54 -0700 (PDT) Message-Id: <200106121528.IAA04605@heliopolis.eng.sun.com> Date: Tue, 12 Jun 2001 08:28:53 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: Comments Re: [seamoby] ct problem statement To: James.Kempf@sun.com, a.ross@ieee.org, pcalhoun@diameter.org, gkenward@nortelnetworks.com Cc: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1+rp+ZbkvTkdz1hHCU4LJQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Well, if we all think it's a good idea, maybe we ought to do a draft for BURP (presuming it becomes a workng group). jak >From: "Gary Kenward" >To: "'James Kempf'" , a.ross@ieee.org, pcalhoun@diameter.org >Cc: Madjid.Nakhjiri@motorola.com, charliep@iprg.nokia.com, seamoby@diameter.org >Subject: RE: Comments Re: [seamoby] ct problem statement >Date: Tue, 12 Jun 2001 11:25:51 -0400 > >Great minds think alike. > >Too bad this isn't the AAA group ;^} > >Gary > >> -----Original Message----- >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> Sent: Tuesday, June 12, 2001 11:07 AM >> To: a.ross@ieee.org; pcalhoun@diameter.org >> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Madjid.Nakhjiri@motorola.com; >> charliep@iprg.nokia.com; seamoby@diameter.org >> Subject: Re: Comments Re: [seamoby] ct problem statement >> >> >> >> >> This is very close to what I have long thought might be a >> good solution >> >> to this problem, i.e. the notion of a "token" that the MN >> might carry >> >> around from AR to AR, presenting it as a sort of "ticket >> for service". >> >> The token would be some sort of public-key thingy, which would be >> >> delivered to the MN upon successful initial authentication and, >> >> possibly, authorization. It, or some complementary key >> variable might >> >> also be pre-distributed by the network to neighbor ARs >> (for suitable >> >> definitions of "neighbor") in anticipation of possible movement. >> >> Successful use upon change of access point would require >> some sort of >> >> combination of a "secret" in the MN with the over-the-air token, >> >> perhaps some sort of challenge-response technique. >> >> >> >> ... but we digress into solution space .... >> > >> >indeed, and it is interesting that I proposed something very similar >> >in MIP at least 2 years ago, and it was never adopted as a >> WG document :( >> > >> >> I've also felt for about a year that such a token >> would go a long way to solving problems with authentication and >> authorization. I've proposed something like this on the BURP list. >> >> jak >> >> From owner-seamoby@diameter.org Tue Jun 12 13:10: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 NAA19784 for ; Tue, 12 Jun 2001 13:10:27 -0400 (EDT) Received: (qmail 29156 invoked by alias); 12 Jun 2001 16:59:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29150 invoked by uid 200); 12 Jun 2001 16:59:24 -0000 Received: (qmail 29145 invoked from network); 12 Jun 2001 16:59:22 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 16:59:22 -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 f5CH6GU19060; Tue, 12 Jun 2001 10:08:39 -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 AHX13181; Tue, 12 Jun 2001 10:06:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11806; Tue, 12 Jun 2001 10:06:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15142.19451.589296.814586@thomasm-u1.cisco.com> Date: Tue, 12 Jun 2001 10:06:03 -0700 (PDT) To: Scott Bradner Cc: hannes@roesti.cc, mat@cisco.com, mark.smith@comdev.cc, seamoby@diameter.org Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement In-Reply-To: <200106121231.IAA07314@newdev.harvard.edu> References: <200106121231.IAA07314@newdev.harvard.edu> 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 Scott Bradner writes: > PBK still uses a return routability test as the > basis of the authentication. > > reminder - PBK's mission is to say that the node that requested the > rebinding was the same node that has been using the old binding > > it was not (specifically not) trying to say who that is Sure it does. The identity it's authenticating is just the previous identity. That it doesn't know more than that is not relevant for the task at hand any more than your authentication of this mail requires any knowledge beyond seeing the from: line being mat@cisco.com. Mike From owner-seamoby@diameter.org Tue Jun 12 13:20: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 NAA20014 for ; Tue, 12 Jun 2001 13:20:23 -0400 (EDT) Received: (qmail 29696 invoked by alias); 12 Jun 2001 17:08:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29682 invoked by uid 200); 12 Jun 2001 17:08:57 -0000 Received: (qmail 29666 invoked from network); 12 Jun 2001 17:08:54 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 17:08:54 -0000 Received: from [206.112.104.58] ([206.112.104.58] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9653552; Tue, 12 Jun 2001 13:18:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <20010612063154.E17928@charizard.diameter.org> References: <9FBD322B7824D511B36900508BF93C9C9F5CDA@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jun 12, 2001 at 09:32:52AM -0400 <9FBD322B7824D511B36900508BF93C9C9F5CDA@zcard031.ca.nortel.com> Date: Tue, 12 Jun 2001 10:19:00 -0700 To: Pat Calhoun , Gary Kenward From: Arthur Ross Subject: Re: [seamoby] DOS in wireless Cc: "'seamoby'" , "'seamoby-context'" Sender: owner-seamoby@diameter.org Precedence: bulk At 6:31 -0700 06/12/2001, Pat Calhoun wrote: >On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary Kenward wrote: >> We all got wrapped up in this discussion of DOS and, in particular, CT >> related DOS. It put a smile on my face last night to recall that with >> wireless, it is almost trivial to mount a DOS attack without referring >> to any protocol nor invading the access network. The traditional term is >> "jamming". With the trend to lower power devices, it would not be difficult >> nor expensive to mount a fairly widespread, difficult to stop attack (and >> I'll stop there). >> >> Perhaps too much attention is being given to putting bars on the windows >> when the front door is missing. > There was quite a debate on this point in the original CDMA wireless standarization activities about 10 years ago. The concern was, not only the malicious prankster/crook, but also the so-called "rogue mobile", meaning one whose power control has lost it's mind and is no longer properly controlling its TX power. The debate has run out of steam, and doesn't seem to be a serious problem in practice. This may, in part, be due to the fact that a phone that has lost its power control mind is likely to be seriously broken somehow, or may run down its battery rapidly, thus leading its owner to turn it off, take it for repair, or whatever. The possibility of malicious DoS via plain ol' jamming is always there. The capacity of a SSMA link is a function of the require received Eb/N0 and the so-called processing gain (the ratio of the spreading BW to the bit rate). The effect of a jammer, intentional or inadvertent, is to consume some of the available capacity, depending on its power, bandwidth, etc. If anyone wants the long form of this, I can do maybe two hours impromputu presentation ... anytime, anyplace, anybody's slides! :-) Then there's always the proverbial Big-Brother-esque spectrum pollution police .... :-) -- ahmr From owner-seamoby@diameter.org Tue Jun 12 14: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 OAA22100 for ; Tue, 12 Jun 2001 14:38:57 -0400 (EDT) Received: (qmail 32095 invoked by alias); 12 Jun 2001 18:26:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32088 invoked by uid 200); 12 Jun 2001 18:26:24 -0000 Received: (qmail 32077 invoked from network); 12 Jun 2001 18:26:21 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 18:26:21 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25319; Tue, 12 Jun 2001 12:36:51 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA14522; Tue, 12 Jun 2001 11:37:57 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5CIajQ504181; Tue, 12 Jun 2001 11:36:45 -0700 (PDT) Message-Id: <200106121836.f5CIajQ504181@jurassic.eng.sun.com> Date: Tue, 12 Jun 2001 11:36:50 -0700 (PDT) From: Alper Yegin Reply-To: Alper Yegin Subject: Re: [seamoby] DOS in wireless To: seamoby@diameter.org, seamoby-context@cdma-2000.org, gkenward@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 78sPnN37WuRnoOVOgOc63w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk > > We all got wrapped up in this discussion of DOS and, in particular, CT > related DOS. It put a smile on my face last night to recall that with > wireless, it is almost trivial to mount a DOS attack without referring > to any protocol nor invading the access network. The traditional term is > "jamming". With the trend to lower power devices, it would not be difficult > nor expensive to mount a fairly widespread, difficult to stop attack (and > I'll stop there). > > Perhaps too much attention is being given to putting bars on the windows > when the front door is missing. > > Gary I'd like to add to that... You don't even need to use access technology specific jamming. Now that bandwidth is very limited with wireless networks, a malicious node on the Internet can pump IP packets towards wireless link (to an existing IP address on this link), which would eat up bandwidth. Depending on access technology, this may or may not affect other devices on the wireless network. Or, malicious node can send packets to random addresses in the wireless network. The access router would need to send neighbor solicitations for each different address... that eats up bandwidth.. [one solution to this problem is to have a large enough neighbor cache on the access router that holds all the attached nodes. And as soon as a device attaches to this network, this devices should send an unsolicited neighbor advertisement.. Now any node that doesn't exist in the neighbor cache doesn't exist on the link. And access router never solicits for random addresses.] alper From owner-seamoby@diameter.org Tue Jun 12 14:48: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 OAA22298 for ; Tue, 12 Jun 2001 14:48:26 -0400 (EDT) Received: (qmail 32724 invoked by alias); 12 Jun 2001 18:37:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32711 invoked by uid 200); 12 Jun 2001 18:37:12 -0000 Received: (qmail 32693 invoked by uid 500); 12 Jun 2001 18:37:09 -0000 Date: Tue, 12 Jun 2001 11:37:09 -0700 From: Pat Calhoun To: Alper Yegin Cc: seamoby@diameter.org, seamoby-context@cdma-2000.org, gkenward@nortelnetworks.com Subject: Re: [seamoby] DOS in wireless Message-ID: <20010612113709.Z17928@charizard.diameter.org> Mail-Followup-To: Alper Yegin , seamoby@diameter.org, seamoby-context@cdma-2000.org, gkenward@nortelnetworks.com References: <200106121836.f5CIajQ504181@jurassic.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: <200106121836.f5CIajQ504181@jurassic.eng.sun.com>; from Alper.Yegin@eng.sun.com on Tue, Jun 12, 2001 at 11:36:50AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 12, 2001 at 11:36:50AM -0700, Alper Yegin wrote: > I'd like to add to that... > > You don't even need to use access technology specific jamming. Now that > bandwidth is very limited with wireless networks, a malicious node on the > Internet can pump IP packets towards wireless link (to an existing IP address on > this link), which would eat up bandwidth. Depending on access technology, this > may or may not affect other devices on the wireless network. Of course, this is very wireless technology specific. There are certain technologies that require that a channel be established with the "access point", and the "access point" must authorize any requests for channel establishment. > > Or, malicious node can send packets to random addresses in the wireless network. > The access router would need to send neighbor solicitations for each different > address... that eats up bandwidth.. [one solution to this problem is to have a > large enough neighbor cache on the access router that holds all the attached > nodes. And as soon as a device attaches to this network, this devices should > send an unsolicited neighbor advertisement.. Now any node that doesn't exist in > the neighbor cache doesn't exist on the link. And access router never solicits > for random addresses.] Again, this assumes that the wireless technology allows each node to communicate directly, which is not an assumption that you can make that easily, given differing technologies out there. Furthermore, sending random packets is always something one can do, but only given its allowable bandwidth. If one is on a wireless link that does not impose any bandwidth limitations, then I agree that would be a possible DoS. Of course, keep in mind that these are not CT specific DoS, and don't need to be addressed in the CT protocol. Again, we are concerned with CT-specific attacks. Thanks, PatC From owner-seamoby@diameter.org Tue Jun 12 14:59: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 OAA22558 for ; Tue, 12 Jun 2001 14:59:49 -0400 (EDT) Received: (qmail 1176 invoked by alias); 12 Jun 2001 18:48:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1170 invoked by uid 200); 12 Jun 2001 18:48:35 -0000 Received: (qmail 1157 invoked from network); 12 Jun 2001 18:48:31 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 18:48:31 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15233; Tue, 12 Jun 2001 12:59:01 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA22446; Tue, 12 Jun 2001 12:00:07 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5CIwtQ509082; Tue, 12 Jun 2001 11:58:55 -0700 (PDT) Message-Id: <200106121858.f5CIwtQ509082@jurassic.eng.sun.com> Date: Tue, 12 Jun 2001 11:59:00 -0700 (PDT) From: Alper Yegin Reply-To: Alper Yegin Subject: Re: [seamoby] DOS in wireless To: pcalhoun@diameter.org Cc: seamoby@diameter.org, seamoby-context@cdma-2000.org, gkenward@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fPIKwXN6zjwZttR0DoCIgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk > > I'd like to add to that... > > > > You don't even need to use access technology specific jamming. Now that > > bandwidth is very limited with wireless networks, a malicious node on the > > Internet can pump IP packets towards wireless link (to an existing IP address on > > this link), which would eat up bandwidth. Depending on access technology, this > > may or may not affect other devices on the wireless network. > > Of course, this is very wireless technology specific. There are certain technologies > that require that a channel be established with the "access point", and the "access > point" must authorize any requests for channel establishment. > > > > > Or, malicious node can send packets to random addresses in the wireless network. > > The access router would need to send neighbor solicitations for each different > > address... that eats up bandwidth.. [one solution to this problem is to have a > > large enough neighbor cache on the access router that holds all the attached > > nodes. And as soon as a device attaches to this network, this devices should > > send an unsolicited neighbor advertisement.. Now any node that doesn't exist in > > the neighbor cache doesn't exist on the link. And access router never solicits > > for random addresses.] > > Again, this assumes that the wireless technology allows each node to communicate > directly, which is not an assumption that you can make that easily, given differing > technologies out there. Furthermore, sending random packets is always something > one can do, but only given its allowable bandwidth. If one is on a wireless link > that does not impose any bandwidth limitations, then I agree that would be a possible > DoS. Actually the malicious node I mentioned above is any host on the Internet. Not necessarily a node on the wireless network. It makes the access router send neighbor solicitations... > > Of course, keep in mind that these are not CT specific DoS, and don't need to be > addressed in the CT protocol. Again, we are concerned with CT-specific attacks. Sorry, seeing the subject line, I couldn't help... These have nothing to do with CT. > > Thanks, > > PatC alper From owner-seamoby@diameter.org Tue Jun 12 15:44: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 PAA23300 for ; Tue, 12 Jun 2001 15:44:01 -0400 (EDT) Received: (qmail 2183 invoked by alias); 12 Jun 2001 19:31:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2177 invoked by uid 200); 12 Jun 2001 19:31:55 -0000 Received: (qmail 2167 invoked from network); 12 Jun 2001 19:31:52 -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; 12 Jun 2001 19:31:52 -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 f5CJfgE07181 for ; Tue, 12 Jun 2001 15:41:42 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 12 Jun 2001 15:41:25 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 15:41:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CEA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby'" , "'seamoby-context'" Subject: [seamoby] RE: [seamoby-context] DOS in wireless Date: Tue, 12 Jun 2001 15:41:18 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F377.A643C190" 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_01C0F377.A643C190 Content-Type: text/plain; charset="ISO-8859-1" Madjid: This is absolutely wrong. I guarantee you that it is possible to jam a CDMA channel with CAN$50 of hardware from radio shack. Indeed, as other posters have indicated, it has happened already by accident. Why hasn't it happened? Well, probably for the same reason why people don't go around cutting telephone wires. It does have the sex appeal of being an Internet hacker. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 12, 2001 1:19 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 'seamoby-context' > Subject: RE: [seamoby-context] DOS in wireless > Sensitivity: Confidential > > > Gary, > > CDMA took care of jamming long time ago. > I consider this more as humor than as serious DoS discussion. > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, June 12, 2001 8:33 AM > To: 'seamoby'; 'seamoby-context' > Subject: [seamoby-context] DOS in wireless > Sensitivity: Confidential > > > We all got wrapped up in this discussion of DOS and, in particular, CT > related DOS. It put a smile on my face last night to recall that with > wireless, it is almost trivial to mount a DOS attack without referring > to any protocol nor invading the access network. The > traditional term is > "jamming". With the trend to lower power devices, it would > not be difficult > nor expensive to mount a fairly widespread, difficult to stop > attack (and > I'll stop there). > > Perhaps too much attention is being given to putting bars on > the windows > when the front door is missing. > > Gary > ------_=_NextPart_001_01C0F377.A643C190 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby-context] DOS in wireless

Madjid:

  This is absolutely wrong. I guarantee you that = it is possible to
jam a CDMA channel with CAN$50 of hardware from = radio shack. Indeed,
as other posters have indicated, it has happened = already by accident.

  Why hasn't it happened? Well, probably for the = same reason why people don't
go around cutting telephone wires. It does have the = sex appeal of being an
Internet hacker.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Tuesday, June 12, 2001 1:19 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; = 'seamoby-context'
> Subject: RE: [seamoby-context] DOS in = wireless
> Sensitivity: Confidential
>
>
> Gary,
>
> CDMA took  care of jamming long time ago. =
> I consider this more as humor than as serious = DoS discussion.
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Tuesday, June 12, 2001 8:33 AM
> To: 'seamoby'; 'seamoby-context'
> Subject: [seamoby-context] DOS in = wireless
> Sensitivity: Confidential
>
>
> We all got wrapped up in this discussion of DOS = and, in particular, CT
> related DOS. It put a smile on my face last = night to recall that with
> wireless, it is almost trivial to mount a DOS = attack without referring
> to any protocol nor invading the access = network. The
> traditional term is
> "jamming". With the trend to lower = power devices, it would
> not be difficult
> nor expensive to mount a fairly widespread, = difficult to stop
> attack (and
> I'll stop there).
>
> Perhaps too much attention is being given to = putting bars on
> the windows
> when the front door is missing.
>
> Gary
>

------_=_NextPart_001_01C0F377.A643C190-- From owner-seamoby@diameter.org Tue Jun 12 15:48:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23384 for ; Tue, 12 Jun 2001 15:48:36 -0400 (EDT) Received: (qmail 2513 invoked by alias); 12 Jun 2001 19:34:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2507 invoked by uid 200); 12 Jun 2001 19:34:21 -0000 Received: (qmail 2495 invoked from network); 12 Jun 2001 19:34:17 -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; 12 Jun 2001 19:34:17 -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 f5CJi4E07500; Tue, 12 Jun 2001 15:44:04 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 12 Jun 2001 15:43:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 15:43:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CEB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby-context] RE: [seamoby] DOS in wireless Date: Tue, 12 Jun 2001 15:43:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F377.FF1F6800" 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_01C0F377.FF1F6800 Content-Type: text/plain; charset="ISO-8859-1" So hopefully, this means that there is some measure of reasonable prevention that can be applied to CT related DOS that will keep us from making it thermo-nuclear explosion proof (NB: rhetorical question). Anyway, enough is enough. Onwards and downwards. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 12, 2001 10:00 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Pat Calhoun'; 'seamoby'; 'seamoby-context' > Subject: Re: [seamoby-context] RE: [seamoby] DOS in wireless > > > On Tue, Jun 12, 2001 at 10:03:48AM -0400, Gary Kenward wrote: > > Well, if I may be so bold, (in the hope that the ads are > watching): I would > > say for wireless, this strategy should be considered in > light of the reality > > of the situation. > > There is definitely a need for security to prevent theft of > service, provide > > privacy, etc. But perhaps the intensity of concern over DOS > in the wireless > > access network needs to be mitigated somewhat. Putting > additional watertight > > bulk-heads in the Titanic would not have saved it from sinking ;^}. > > > > Naturally, the situation is even more dramatic in > all-wireless networks. > > > > Anyway, enough. Just wanted to make the observation. > > and I actually go appreciate the observation. However, our > work here is not to > ensure against theft of service, etc. What we need to do is > guard against someone > mounting a specific attack on CT. So, don't view this as a > wireless attack, but rather > one on the IP network. Of course, if a wireless attack can be > mounted that will > cause CT to behave REALLY badly (e.g. take down service), > then we already need > to identify those. > > As far as other DoS, they can simply flood ping us, and > there's nothing much we could > do :( > > PatC > ------_=_NextPart_001_01C0F377.FF1F6800 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby-context] RE: [seamoby] DOS in wireless

So hopefully, this means that there is some measure of reasonable prevention
that can be applied to CT related DOS that will keep us from making it
thermo-nuclear explosion proof (NB: rhetorical question).

Anyway, enough is enough.
Onwards and downwards.
Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, June 12, 2001 10:00 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; 'seamoby'; 'seamoby-context'
> Subject: Re: [seamoby-context] RE: [seamoby] DOS in wireless
>
>
> On Tue, Jun 12, 2001 at 10:03:48AM -0400, Gary Kenward wrote:
> > Well, if I may be so bold, (in the hope that the ads are
> watching): I would
> > say for wireless, this strategy should be considered in
> light of the reality
> > of the situation.
> > There is definitely a need for security to prevent theft of
> service, provide
> > privacy, etc. But perhaps the intensity of concern over DOS
> in the wireless
> > access network needs to be mitigated somewhat. Putting
> additional watertight
> > bulk-heads in the Titanic would not have saved it from sinking ;^}.
> >
> > Naturally, the situation is even more dramatic in
> all-wireless networks.
> >
> > Anyway, enough. Just wanted to make the observation.
>
> and I actually go appreciate the observation. However, our
> work here is not to
> ensure against theft of service, etc. What we need to do is
> guard against someone
> mounting a specific attack on CT. So, don't view this as a
> wireless attack, but rather
> one on the IP network. Of course, if a wireless attack can be
> mounted that will
> cause CT to behave REALLY badly (e.g. take down service),
> then we already need
> to identify those.
>
> As far as other DoS, they can simply flood ping us, and
> there's nothing much we could
> do :(
>
> PatC
>

------_=_NextPart_001_01C0F377.FF1F6800-- From owner-seamoby@diameter.org Tue Jun 12 15:52: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 PAA23459 for ; Tue, 12 Jun 2001 15:52:07 -0400 (EDT) Received: (qmail 3132 invoked by alias); 12 Jun 2001 19:39:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3120 invoked by uid 200); 12 Jun 2001 19:39:24 -0000 Received: (qmail 3101 invoked by uid 500); 12 Jun 2001 19:39:20 -0000 Date: Tue, 12 Jun 2001 12:39:20 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , "'seamoby'" , "'seamoby-context'" Subject: Re: [seamoby-context] RE: [seamoby] DOS in wireless Message-ID: <20010612123920.F17928@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , 'seamoby' , 'seamoby-context' References: <9FBD322B7824D511B36900508BF93C9C9F5CEB@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: <9FBD322B7824D511B36900508BF93C9C9F5CEB@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jun 12, 2001 at 03:43:47PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 12, 2001 at 03:43:47PM -0400, Gary Kenward wrote: > So hopefully, this means that there is some measure of reasonable prevention > that can be applied to CT related DOS that will keep us from making it > thermo-nuclear explosion proof (NB: rhetorical question). I unfortunately do not know whether this was intended to be humorous or not, so I find myself replying. Again, we are not concerned with outside DoS attacks. There are plenty out there that we cannot do anything about. However, we do not want to be responsible for yet another DoS attack, via the CT protocol. So, let's stop these descriptions of attacks that are not related to CT, and rather concentrate on CT itself, and ensuring that we don't open new security holes. PatC From owner-seamoby@diameter.org Tue Jun 12 15:55: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 PAA23509 for ; Tue, 12 Jun 2001 15:55:03 -0400 (EDT) Received: (qmail 3980 invoked by alias); 12 Jun 2001 19:44:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3969 invoked by uid 200); 12 Jun 2001 19:44:20 -0000 Received: (qmail 3960 invoked from network); 12 Jun 2001 19:44:17 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 19:44:17 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 15:54:48 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445512@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Gary Kenward'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby] RE: [seamoby-context] DOS in wireless Date: Tue, 12 Jun 2001 15:54:47 -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" Sender: owner-seamoby@diameter.org Precedence: bulk Bzzzt. Let's be specific here. IS-95, cdma2000, umts all have slightly different anti-jam characteristics. For IS-95 Jamming Margin = W/R (dB) - (Eb/No)req(dB) So W/R is just the processing gain (varies in IS-95 with coding rate), and Eb/No is the channel's signal to noise ratio. I can guarantee you that I can build a different CDMA system that you can not Jam with your ham shack or radio shack parts. >Madjid: > This is absolutely wrong. I guarantee you that it is possible to >jam a CDMA channel with CAN$50 of hardware from radio shack. Indeed, >as other posters have indicated, it has happened already by accident. From owner-seamoby@diameter.org Tue Jun 12 16:25: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 QAA23994 for ; Tue, 12 Jun 2001 16:25:27 -0400 (EDT) Received: (qmail 4785 invoked by alias); 12 Jun 2001 20:14:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4769 invoked by uid 200); 12 Jun 2001 20:14:26 -0000 Received: (qmail 4759 invoked from network); 12 Jun 2001 20:14:23 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 20:14:23 -0000 Received: from [206.112.110.10] ([206.112.110.10] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9666195; Tue, 12 Jun 2001 16:23:55 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E048445512@meshpdc.meshnetworks.com> Date: Tue, 12 Jun 2001 13:24:02 -0700 To: Phillip Neumiller , "'Gary Kenward'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby'" , "'seamoby-context'" From: Arthur Ross Subject: RE: [seamoby] RE: [seamoby-context] DOS in wireless Sender: owner-seamoby@diameter.org Precedence: bulk At 12:54 -0700 06/12/2001, Phillip Neumiller wrote: >Bzzzt. Let's be specific here. IS-95, cdma2000, umts all have >slightly different anti-jam characteristics. For IS-95 > >Jamming Margin = W/R (dB) - (Eb/No)req(dB) > >So W/R is just the processing gain (varies in IS-95 with coding >rate), and Eb/No is the channel's signal to noise ratio. > Close - "Jamming margin" isn't really the whole story - it's a question of fraction of available Shannon capacity, which is mutual interference-limited in the multiple access case for asymptotically high powers from everybody. A jammer eats into that capacity to an extent that depends on how the normal users do power control and their max Tx powers. - ask me for that 2 hour version sometime .... :-) -- ahmr From owner-seamoby@diameter.org Tue Jun 12 16:34: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 QAA24192 for ; Tue, 12 Jun 2001 16:34:47 -0400 (EDT) Received: (qmail 5404 invoked by alias); 12 Jun 2001 20:22:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5396 invoked by uid 200); 12 Jun 2001 20:22:55 -0000 Received: (qmail 5387 invoked from network); 12 Jun 2001 20:22:53 -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; 12 Jun 2001 20:22:53 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CKWgE14078 for ; Tue, 12 Jun 2001 16:32:42 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 12 Jun 2001 16:32:28 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:32:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby] RE: [seamoby-context] DOS in wireless Date: Tue, 12 Jun 2001 16:32:23 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F37E.C9614D80" 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_01C0F37E.C9614D80 Content-Type: text/plain; charset="ISO-8859-1" I'm sure you could. It's been done already for the various military organizations. It's not clear you could do it and build a commercially viable network. So? > -----Original Message----- > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > Sent: Tuesday, June 12, 2001 3:55 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; > 'seamoby'; 'seamoby-context' > Subject: RE: [seamoby] RE: [seamoby-context] DOS in wireless > Sensitivity: Confidential > > > Bzzzt. Let's be specific here. IS-95, cdma2000, umts all have > slightly different anti-jam characteristics. For IS-95 > > Jamming Margin = W/R (dB) - (Eb/No)req(dB) > > So W/R is just the processing gain (varies in IS-95 with coding > rate), and Eb/No is the channel's signal to noise ratio. > > I can guarantee you that I can build a different CDMA system > that you can not Jam with your ham shack or radio shack parts. > > > >Madjid: > > This is absolutely wrong. I guarantee you that it is possible to > >jam a CDMA channel with CAN$50 of hardware from radio shack. Indeed, > >as other posters have indicated, it has happened already by > accident. > > ------_=_NextPart_001_01C0F37E.C9614D80 Content-Type: text/html; charset="ISO-8859-1" RE: [seamoby] RE: [seamoby-context] DOS in wireless

I'm sure you could. It's been done already for the various military
organizations. It's not clear you could do it and build a commercially
viable network.

So?

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Tuesday, June 12, 2001 3:55 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1';
> 'seamoby'; 'seamoby-context'
> Subject: RE: [seamoby] RE: [seamoby-context] DOS in wireless
> Sensitivity: Confidential
>
>
> Bzzzt.  Let's be specific here.  IS-95, cdma2000, umts all have
> slightly different anti-jam characteristics. For IS-95
>
> Jamming Margin = W/R (dB) - (Eb/No)req(dB)
>
> So W/R is just the processing gain (varies in IS-95 with coding
> rate), and Eb/No is the channel's signal to noise ratio. 
>
> I can guarantee you that I can build a different CDMA system
> that you can not Jam with your ham shack or radio shack parts. 
> 
>
> >Madjid:
> >  This is absolutely wrong. I guarantee you that it is possible to
> >jam a CDMA channel with CAN$50 of hardware from radio shack. Indeed,
> >as other posters have indicated, it has happened already by
> accident.
> 
>

------_=_NextPart_001_01C0F37E.C9614D80-- From owner-seamoby@diameter.org Tue Jun 12 18:09:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25612 for ; Tue, 12 Jun 2001 18:09:21 -0400 (EDT) Received: (qmail 7444 invoked by alias); 12 Jun 2001 21:58:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7438 invoked by uid 200); 12 Jun 2001 21:58:22 -0000 Received: (qmail 7426 invoked from network); 12 Jun 2001 21:58:20 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 21:58:20 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA21949; Tue, 12 Jun 2001 15:08:51 -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 PAA18035; Tue, 12 Jun 2001 15:08:51 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:08:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D75@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Date: Tue, 12 Jun 2001 17:08:48 -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 of course. My intention was not to kill the whole thread, just the definition wars that are going on :) MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot of text for readability. > > 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS. I would claim that such events are unlikely to happen. When a user wants to move from one service area to another, the spectrum will be overlapping. The operators of these networks will allow/disallow CT between the routers handling these service areas. If they permit it, then will ensure that secure communication is available between them. MN>> I am not quite sure I understand your point. I am not sure how spectrum overlap comes in? Anyway, seems like you are asuuming one and the same operator handling both oldAR and newAR. What if they belong to two different operators. And then one operator decides to mess with the other one, by having its ARs that are already authenticated to its neighbor ARs (from the other operator) do DoS, i.e. OP1 (AR1) does a DoS on OP2(AR2) although AR1-AR2 had a pre-authentication. Isn't that possible? From owner-seamoby@diameter.org Tue Jun 12 18:17: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 SAA25769 for ; Tue, 12 Jun 2001 18:17:27 -0400 (EDT) Received: (qmail 7949 invoked by alias); 12 Jun 2001 22:06:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7943 invoked by uid 200); 12 Jun 2001 22:06:23 -0000 Received: (qmail 7938 invoked from network); 12 Jun 2001 22:06:21 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 22:06:21 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA10584 for ; Tue, 12 Jun 2001 15:16:52 -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 PAA22495 for ; Tue, 12 Jun 2001 15:16:52 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:16:52 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D76@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 12 Jun 2001 17:16:51 -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 Gary, See below: -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Monday, June 11, 2001 3:06 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: Comments Re: [seamoby] ct problem statement Madjid, Charlie, et al: Madjid, I think you have captured the essence of the real issue. Authentication and authorization are different, but for the most part, authorization has never really been needed for the internet, mainly for the reasons you describe. The real interesting issue (besides how to authorize every doorknob and aircraft carrier on the planet), is whether, in a mobile environment, how often one needs to authenticate. Consider that a mobile node travelling through the network will, with each handover, open up opportunities for an interloper to steal a service, if that service is only authorized and the service user is not authenticated. MN>> I think the point of DoS is missed here. Note, we are not discussing service theft here (that is the operators problem). Stealing service by an un-authorized user is not the issue. The issue is launching a DENIAL of service attack by a node that can do CT (you can translate it as authorized to do CT), so we are talking about authorizing oldAR to send CT or authorizing newAR to request CT. It seems that a lot of folks are confusing service theft with DoS attack. With service theft, you are just not paying for usage. With DoS attack, you are making the network so busy, it can not give service to anybody, *DENIAL* of service. Madjid From owner-seamoby@diameter.org Tue Jun 12 18:23: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 SAA25913 for ; Tue, 12 Jun 2001 18:23:20 -0400 (EDT) Received: (qmail 8446 invoked by alias); 12 Jun 2001 22:11:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8440 invoked by uid 200); 12 Jun 2001 22:11:02 -0000 Received: (qmail 8435 invoked from network); 12 Jun 2001 22:11:00 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 22:11:00 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA13582 for ; Tue, 12 Jun 2001 15:21:31 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA21453 for ; Tue, 12 Jun 2001 15:21:30 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:21:30 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D77@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Arthur Ross'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 12 Jun 2001 17:21:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F38E.049A71B0" 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_01C0F38E.049A71B0 Content-Type: text/plain Again, this is not a AAA discussion. it is not about usage authorization and theft of service, it is about Denial of service attack. THe notion of token can be interesting to prevent an AR doing DoS on the other, but if the mobile is supposed to carry these token, that kind of defeats the purpose of CT, specially when we are doing proactive CT to several neighboring ARs. Madjid -----Original Message----- From: Arthur Ross [mailto:a.ross@ieee.org] Sent: Monday, June 11, 2001 4:18 PM To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: Comments Re: [seamoby] ct problem statement At 13:06 -0700 06/11/2001, Gary Kenward wrote: It would seem that for a mobile solution, the preferred approach would incorporate some sort of "authorization" tokens that would could be passed between ARs as part of the mobile node's context (in a secure fashion of course). There would have to be a tight association maintained between the authentication information and these authorization tokens. If this is the best approach, then once again, it would be difficult to distinguish authentication from authorization. Gary et al: This is very close to what I have long thought might be a good solution to this problem, i.e. the notion of a "token" that the MN might carry around from AR to AR, presenting it as a sort of "ticket for service". The token would be some sort of public-key thingy, which would be delivered to the MN upon successful initial authentication and, possibly, authorization. It, or some complementary key variable might also be pre-distributed by the network to neighbor ARs (for suitable definitions of "neighbor") in anticipation of possible movement. Successful use upon change of access point would require some sort of combination of a "secret" in the MN with the over-the-air token, perhaps some sort of challenge-response technique. ... but we digress into solution space .... What this is about is creating a formalism for "trust propagation" in ways that are cryptographically secure against the well-known threats, e.g. hijacking the channel, spoofing, man-in-the-middle, etc. There are, BTW, already some ways of coping with the "aging" of the credential, such as the cellular authentication standards, which permit out of the blue challenges at the network's whim. Similar approaches might be ok here, if one is concerned with performance (speed of handover, QoS) vs security ... Sort of a Ronnie Reagan principle of CT: "Trust but verify." :-) -- ahmr ------_=_NextPart_001_01C0F38E.049A71B0 Content-Type: text/html
Again, this is not a AAA discussion. it is not about usage authorization and
theft of service, it is about Denial of service attack.
THe notion of token can be interesting to prevent an AR doing DoS on the other, but
if the mobile is supposed to carry these token, that kind of defeats the purpose
of CT, specially when we are doing proactive CT to several neighboring ARs.
 
Madjid
-----Original Message-----
From: Arthur Ross [mailto:a.ross@ieee.org]
Sent: Monday, June 11, 2001 4:18 PM
To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: Comments Re: [seamoby] ct problem statement

At 13:06 -0700 06/11/2001, Gary Kenward wrote:

It would seem that for a mobile solution, the preferred approach

would incorporate some sort of "authorization" tokens that would could be passed between ARs as part of the mobile node's context (in a secure fashion of course). There would have to be a tight association maintained between the authentication information and these authorization tokens. If this is the best approach, then once again, it would be difficult to distinguish authentication from authorization.


Gary et al:


This is very close to what I have long thought might be a good solution to this problem, i.e. the notion of a "token" that the MN might carry around from AR to AR, presenting it as a sort of "ticket for service". The token would be some sort of public-key thingy, which would be delivered to the MN upon successful initial authentication and, possibly, authorization. It, or some complementary key variable might also be pre-distributed by the network to neighbor ARs (for suitable definitions of "neighbor") in anticipation of possible movement. Successful use upon change of access point would require some sort of combination of a "secret" in the MN with the over-the-air token, perhaps some sort of challenge-response technique.


... but we digress into solution space ....


What this is about is creating a formalism for "trust propagation" in ways that are cryptographically secure against the well-known threats, e.g. hijacking the channel, spoofing, man-in-the-middle, etc.


There are, BTW, already some ways of coping with the "aging" of the credential, such as the cellular authentication standards, which permit out of the blue challenges at the network's whim. Similar approaches might be ok here, if one is concerned with performance (speed of handover, QoS) vs security ... Sort of a Ronnie Reagan principle of CT: "Trust but verify." :-)


-- ahmr

------_=_NextPart_001_01C0F38E.049A71B0-- From owner-seamoby@diameter.org Tue Jun 12 18:29: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 SAA26002 for ; Tue, 12 Jun 2001 18:29:04 -0400 (EDT) Received: (qmail 8707 invoked by alias); 12 Jun 2001 22:13:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8701 invoked by uid 200); 12 Jun 2001 22:13:24 -0000 Received: (qmail 8684 invoked from network); 12 Jun 2001 22:13:21 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 22:13:21 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA24745; Tue, 12 Jun 2001 15:23:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA26995; Tue, 12 Jun 2001 15:23:41 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:23:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D78@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'James Kempf'" , a.ross@ieee.org, pcalhoun@diameter.org Cc: Nakhjiri Madjid-MNAKHJI1 , charliep@iprg.nokia.com, seamoby@diameter.org Subject: RE: Comments Re: [seamoby] ct problem statement Date: Tue, 12 Jun 2001 17:23:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F38E.503A0860" 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_01C0F38E.503A0860 Content-Type: text/plain; charset="iso-8859-1" It sure feels like a AAA discussion!! -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, June 12, 2001 10:26 AM To: 'James Kempf'; a.ross@ieee.org; pcalhoun@diameter.org Cc: Madjid.Nakhjiri; charliep@iprg.nokia.com; seamoby@diameter.org Subject: RE: Comments Re: [seamoby] ct problem statement Great minds think alike. Too bad this isn't the AAA group ;^} Gary > -----Original Message----- > From: James Kempf [ mailto:James.Kempf@Sun.COM ] > Sent: Tuesday, June 12, 2001 11:07 AM > To: a.ross@ieee.org; pcalhoun@diameter.org > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Madjid.Nakhjiri@motorola.com; > charliep@iprg.nokia.com; seamoby@diameter.org > Subject: Re: Comments Re: [seamoby] ct problem statement > > > > >> This is very close to what I have long thought might be a > good solution > >> to this problem, i.e. the notion of a "token" that the MN > might carry > >> around from AR to AR, presenting it as a sort of "ticket > for service". > >> The token would be some sort of public-key thingy, which would be > >> delivered to the MN upon successful initial authentication and, > >> possibly, authorization. It, or some complementary key > variable might > >> also be pre-distributed by the network to neighbor ARs > (for suitable > >> definitions of "neighbor") in anticipation of possible movement. > >> Successful use upon change of access point would require > some sort of > >> combination of a "secret" in the MN with the over-the-air token, > >> perhaps some sort of challenge-response technique. > >> > >> ... but we digress into solution space .... > > > >indeed, and it is interesting that I proposed something very similar > >in MIP at least 2 years ago, and it was never adopted as a > WG document :( > > > > I've also felt for about a year that such a token > would go a long way to solving problems with authentication and > authorization. I've proposed something like this on the BURP list. > > jak > > ------_=_NextPart_001_01C0F38E.503A0860 Content-Type: text/html; charset="iso-8859-1" RE: Comments Re: [seamoby] ct problem statement
It sure feels like a AAA discussion!!
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, June 12, 2001 10:26 AM
To: 'James Kempf'; a.ross@ieee.org; pcalhoun@diameter.org
Cc: Madjid.Nakhjiri; charliep@iprg.nokia.com; seamoby@diameter.org
Subject: RE: Comments Re: [seamoby] ct problem statement

Great minds think alike.

Too bad this isn't the AAA group ;^}

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, June 12, 2001 11:07 AM
> To: a.ross@ieee.org; pcalhoun@diameter.org
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Madjid.Nakhjiri@motorola.com;
> charliep@iprg.nokia.com; seamoby@diameter.org
> Subject: Re: Comments Re: [seamoby] ct problem statement
>
>
>
> >> This is very close to what I have long thought might be a
> good solution
> >> to this problem, i.e. the notion of a "token" that the MN
> might carry
> >> around from AR to AR, presenting it as a sort of "ticket
> for service".
> >> The token would be some sort of public-key thingy, which would be
> >> delivered to the MN upon successful initial authentication and,
> >> possibly, authorization. It, or some complementary key
> variable might
> >> also be pre-distributed by the network to neighbor ARs
> (for suitable
> >> definitions of "neighbor") in anticipation of possible movement.
> >> Successful use upon change of access point would require
> some sort of
> >> combination of a "secret" in the MN with the over-the-air token,
> >> perhaps some sort of challenge-response technique.  
> >>
> >> ... but we digress into solution space ....
> >
> >indeed, and it is interesting that I proposed something very similar
> >in MIP at least 2 years ago, and it was never adopted as a
> WG document :(
> >
>
> I've also felt for about a year that such a token
> would go a long way to solving problems with authentication and
> authorization. I've proposed something like this on the BURP list.
>
>               jak
>
>

------_=_NextPart_001_01C0F38E.503A0860-- From owner-seamoby@diameter.org Tue Jun 12 18:32:55 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 SAA26108 for ; Tue, 12 Jun 2001 18:32:55 -0400 (EDT) Received: (qmail 8731 invoked by alias); 12 Jun 2001 22:13:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8725 invoked by uid 200); 12 Jun 2001 22:13:28 -0000 Received: (qmail 8715 invoked from network); 12 Jun 2001 22:13:26 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 22:13:26 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 18:23:53 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445516@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Tue, 12 Jun 2001 18:23:49 -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 Some comments.... > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 12, 2001 6:09 PM > > of course. My intention was not to kill the whole thread, just the > definition wars that are going on :) > > MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot > of text for readability. > > > > > 1-How to prevent a pre-authenticated AR from doing > unauthorized CT DoS. > > I would claim that such events are unlikely to happen. When a > user wants to > move > from one service area to another, the spectrum will be > overlapping. The > operators > of these networks will allow/disallow CT between the routers > handling these > service areas. If they permit it, then will ensure that > secure communication > is available between them. > > MN>> I am not quite sure I understand your point. I am not sure > how spectrum overlap comes in? > Anyway, seems like you are asuuming one and the same operator handling > both oldAR and newAR. What if they belong to two different operators. > And then one operator decides to mess with the other one, by having > its ARs that are already authenticated to its neighbor ARs (from the > other operator) do DoS, i.e. A better question is what if they belong to YOU as an individual. I am really hoping that we can drive the stake into the heart of the large telecommunications monopolies and put the control of wireless back where it belongs, in the hands of the people. Think about how the world would be where everyone everywhere is laying down wireless routers and doing so because its cheap. Using simple calculations with the Shannon capacity equation the future clearly lies in super wide bandwidth radios all inter-connected over short distances over the surface of the Earth in a Mesh. This of course will have the tendency to light up a lot of that fiber that is now dark.... Don't let the 3G propaganda drag you down. THIS IS BOUND TO HAPPEN. I hope folks on this list will be some of the folks that help realize this potential future. Thanks, Phil (Pat, sorry for cross-posting to SeaMoby and WirelessInternet but I did not start it). From owner-seamoby@diameter.org Tue Jun 12 18:42: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 SAA26269 for ; Tue, 12 Jun 2001 18:42:50 -0400 (EDT) Received: (qmail 10191 invoked by alias); 12 Jun 2001 22:27:47 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10182 invoked by uid 200); 12 Jun 2001 22:27:46 -0000 Received: (qmail 10163 invoked from network); 12 Jun 2001 22:27:43 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 22:27:43 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA12960; Tue, 12 Jun 2001 15:38:13 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA13831; Tue, 12 Jun 2001 15:38:12 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:38:11 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D7B@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Phillip Neumiller'" , Nakhjiri Madjid-MNAKHJI1 , "'Pat Calhoun'" Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Tue, 12 Jun 2001 17:38:11 -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: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Tuesday, June 12, 2001 5:24 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun' Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Some comments.... > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 12, 2001 6:09 PM > > of course. My intention was not to kill the whole thread, just the > definition wars that are going on :) > > MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot > of text for readability. > > > > > 1-How to prevent a pre-authenticated AR from doing > unauthorized CT DoS. > > I would claim that such events are unlikely to happen. When a > user wants to > move > from one service area to another, the spectrum will be > overlapping. The > operators > of these networks will allow/disallow CT between the routers > handling these > service areas. If they permit it, then will ensure that > secure communication > is available between them. > > MN>> I am not quite sure I understand your point. I am not sure > how spectrum overlap comes in? > Anyway, seems like you are asuuming one and the same operator handling > both oldAR and newAR. What if they belong to two different operators. > And then one operator decides to mess with the other one, by having > its ARs that are already authenticated to its neighbor ARs (from the > other operator) do DoS, i.e. A better question is what if they belong to YOU as an individual. I am really hoping that we can drive the stake into the heart of the large telecommunications monopolies and put the control of wireless back where it belongs, in the hands of the people. Think about how the world would be where everyone everywhere is laying down wireless routers and doing so because its cheap. Using simple calculations with the Shannon capacity equation the future clearly lies in super wide bandwidth radios all inter-connected over short distances over the surface of the Earth in a Mesh. This of course will have the tendency to light up a lot of that fiber that is now dark.... Don't let the 3G propaganda drag you down. THIS IS BOUND TO HAPPEN. I hope folks on this list will be some of the folks that help realize this potential future. Thanks, Phil (Pat, sorry for cross-posting to SeaMoby and WirelessInternet but I did not start it). MN>>Hey, I didn't look at the email list, I just replied all, I hope I don't get the blame for this. I am out of here :) I just want to see whether the DoS scenario I was explaining is a real one, or not. From owner-seamoby@diameter.org Tue Jun 12 19:13: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 TAA26659 for ; Tue, 12 Jun 2001 19:13:39 -0400 (EDT) Received: (qmail 11839 invoked by alias); 12 Jun 2001 23:02:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11832 invoked by uid 200); 12 Jun 2001 23:02:21 -0000 Received: (qmail 11820 invoked from network); 12 Jun 2001 23:02:18 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jun 2001 23:02:18 -0000 Received: from [206.112.126.175] ([206.112.126.175] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9676936; Tue, 12 Jun 2001 19:11:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E048445516@meshpdc.meshnetworks.com> Date: Tue, 12 Jun 2001 16:12:45 -0700 To: Phillip Neumiller , "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" From: Arthur Ross Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Cc: Charlie Perkins , Kulwinder Atwal , "'seamoby'" Sender: owner-seamoby@diameter.org Precedence: bulk At 15:23 -0700 06/12/2001, Phillip Neumiller wrote: > >A better question is what if they belong to YOU as an individual. I >am really hoping that we can drive the stake into the heart of the >large telecommunications monopolies and put the control of wireless >back where it belongs, in the hands of the people. Think about how >the world would be where everyone everywhere is laying down wireless >routers and doing so because its cheap. Using simple calculations >with the Shannon capacity equation the future clearly lies in super >wide bandwidth radios all inter-connected over short distances over >the surface of the Earth in a Mesh. This of course will have the >tendency to light up a lot of that fiber that is now dark.... Don't >let the 3G propaganda drag you down. THIS IS BOUND TO HAPPEN. I >hope folks on this list will be some of the folks that help realize >this potential future. > [Spectrum] Power to the people, eh? ... AMEN! It may be time to drag out & distribute my little white paper [a.k.a. diatribe] to the FCC from 3 years ago, which was basically this same theme: * Low cost, proliferated, minimal-regulation services * Minimum rules of mutual cooperation in Tx power control - the "Minimalist Air Interface" * Husbandry of the Shannon-esque aetherial capacity, rather than horrendous wastage and artificially-created shortages so "big wireless" can keep the prices up. * Remind people that, as you say, and Bell Labs told us 25 years ago, cell subdivision STILL WORKS as a way of increasing capacity - smaller cells, more of them, lower Tx powers, largest possible bandwidth to aggregate interference. [Sorry just couldn't resist ... I feel all kinds of vampire/Che Guevara/biblical creation jokes coming on ... ;-) ] -- ahmr PS: The Wall Street journal reported about 2 weeks ago that 97% of the fiber in the US is dark. It's a drug on the market - all but impossible to make money as a bearer-only service provider. From owner-seamoby@diameter.org Tue Jun 12 19:48: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 TAA26977 for ; Tue, 12 Jun 2001 19:48:02 -0400 (EDT) Received: (qmail 13837 invoked by alias); 12 Jun 2001 23:32:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13827 invoked by uid 200); 12 Jun 2001 23:32:27 -0000 Received: (qmail 13813 invoked by uid 500); 12 Jun 2001 23:32:23 -0000 Date: Tue, 12 Jun 2001 16:32:23 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Message-ID: <20010612163223.I17928@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Pat Calhoun' , Arthur Ross , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: <35DBB8B7AC89D4118E98009027B1009B017A9D75@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: <35DBB8B7AC89D4118E98009027B1009B017A9D75@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Tue, Jun 12, 2001 at 05:08:48PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 12, 2001 at 05:08:48PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > > of course. My intention was not to kill the whole thread, just the > definition wars that are going on :) > > MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot > of text for readability. > > > > > 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS. > > I would claim that such events are unlikely to happen. When a user wants to > move > from one service area to another, the spectrum will be overlapping. The > operators > of these networks will allow/disallow CT between the routers handling these > service areas. If they permit it, then will ensure that secure communication > is available between them. > > MN>> I am not quite sure I understand your point. I am not sure > how spectrum overlap comes in? Sorry, what I meant was that the service areas are close enough that it makes sense to CT. If there is a long no-service time between both service areas, then CT doesn't really make that much sense, right? > Anyway, seems like you are asuuming one and the same operator handling > both oldAR and newAR. I didn't mean to assume this. > What if they belong to two different operators. > And then one operator decides to mess with the other one, by having > its ARs that are already authenticated to its neighbor ARs (from the > other operator) do DoS, i.e. Right, so my point is that if CT is to occur between two ARs, they MUST know about each other to begin with, right? If so, then a pre-existing SA exists between the ARs, and security will ensure that no DoS attack can exist. Actually, there is one way to do a DoS attack that has just come to mind, and involves a rogue mobile sending bogus L2 messages faking handoffs, but this doesn't just affect CT, as it would also affect the handoff procedures, and this only exists on wireless links that are not authenticated. > > OP1 (AR1) does a DoS on OP2(AR2) although AR1-AR2 had a pre-authentication. That is not really an attack that we need to consider. Once you trust one side of a conversation, there isn't a whole lot that you can do to protect yourself against bad behavior (well, a good implementation can protect itself properly). PatC From owner-seamoby@diameter.org Wed Jun 13 02:38: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 CAA14860 for ; Wed, 13 Jun 2001 02:38:04 -0400 (EDT) Received: (qmail 19328 invoked by alias); 13 Jun 2001 06:27:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19322 invoked by uid 200); 13 Jun 2001 06:27:03 -0000 Received: (qmail 19315 invoked from network); 13 Jun 2001 06:27:01 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 06:27:01 -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 f5D6bib17131 for ; Wed, 13 Jun 2001 09:37:44 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 13 Jun 2001 09:37:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 13 Jun 2001 09:37:27 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B0D5@eseis04nok> From: john.loughney@nokia.com To: gkenward@nortelnetworks.com, seamoby@diameter.org, seamoby-context@cdma-2000.org Subject: RE: [seamoby] DOS in wireless Date: Wed, 13 Jun 2001 09:37:25 +0300 Sensitivity: Company-Confidential 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 Gary, > We all got wrapped up in this discussion of DOS and, in particular, CT > related DOS. It put a smile on my face last night to recall that with > wireless, it is almost trivial to mount a DOS attack without referring > to any protocol nor invading the access network. The > traditional term is "jamming". With the trend to lower power devices, it > would not be difficult nor expensive to mount a fairly widespread, > difficult to stop attack (and I'll stop there). > > Perhaps too much attention is being given to putting bars on > the windows when the front door is missing. If CT is done correctly, it may have widespread uses which we aren't currently thinking of - and that is a sign of success. Therefore, in designing new protocols, we should make some effort not to create new problems, irrespective of existing problems. best regards, John From owner-seamoby@diameter.org Wed Jun 13 09:14: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 JAA22143 for ; Wed, 13 Jun 2001 09:14:30 -0400 (EDT) Received: (qmail 22023 invoked by alias); 13 Jun 2001 13:02:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22017 invoked by uid 200); 13 Jun 2001 13:02:39 -0000 Received: (qmail 22009 invoked from network); 13 Jun 2001 13:02:38 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 13:02:38 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 09:13:11 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844551B@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Wed, 13 Jun 2001 09:13:09 -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 Hi, > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > MN>> I am not quite sure I understand your point. I am not sure > > how spectrum overlap comes in? > > Sorry, what I meant was that the service areas are close > enough that it > makes sense to CT. If there is a long no-service time between > both service > areas, then CT doesn't really make that much sense, right? Pat, There are companies that build products (WRQ's reflection comes to mind) that freeze the state of the IP stack (gracefully in the application sense), until the flow of IP traffic can resume. This is sort of an ultra-slow handover. I see no reason why THIS can not be made seamless with CT. Why should CT not be capable of accomodating this Pat? Thanks, Phil From owner-seamoby@diameter.org Wed Jun 13 09:42:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22948 for ; Wed, 13 Jun 2001 09:42:53 -0400 (EDT) Received: (qmail 24254 invoked by alias); 13 Jun 2001 13:29:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24246 invoked by uid 200); 13 Jun 2001 13:29:33 -0000 Received: (qmail 24233 invoked by uid 500); 13 Jun 2001 13:29:30 -0000 Date: Wed, 13 Jun 2001 06:29:30 -0700 From: Pat Calhoun To: Phillip Neumiller Cc: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 , Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Message-ID: <20010613062930.T17928@charizard.diameter.org> Mail-Followup-To: Phillip Neumiller , 'Pat Calhoun' , Nakhjiri Madjid-MNAKHJI1 , Arthur Ross , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: <0DF9FBC42474A24CA50F7A27FB08E04844551B@meshpdc.meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E04844551B@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Wed, Jun 13, 2001 at 09:13:09AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > There are companies that build products (WRQ's reflection comes > to mind) that freeze the state of the IP stack (gracefully in > the application sense), until the flow of IP traffic can resume. > This is sort of an ultra-slow handover. I see no reason why THIS > can not be made seamless with CT. Why should CT not be capable > of accomodating this Pat? Sure, they could, but what is seamless in this sense? The user has no service for some time, so what is an extra couple of seconds while signalling occurs over the air to update the local ARs state?? The user would probably not even notice. Actually, you seem to imply something that I am not sure that I've been thinking about that much, which is the mobile updating the AR's state. This, btw, can be problematic, since the mobile doesn't necessarily share an SA with the AR (hence DoS attacks), and a malicious mobile could send bogus (mal-formed) CT packets in an attempt to crash (or cause mis-behaving) ARs. Something to think about in the DoS space. PatC From owner-seamoby@diameter.org Wed Jun 13 10:19: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 KAA23665 for ; Wed, 13 Jun 2001 10:19:07 -0400 (EDT) Received: (qmail 25398 invoked by alias); 13 Jun 2001 14:05:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25392 invoked by uid 200); 13 Jun 2001 14:05:49 -0000 Received: (qmail 25387 invoked from network); 13 Jun 2001 14:05:47 -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; 13 Jun 2001 14:05:47 -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 f5DEFdE09130 for ; Wed, 13 Jun 2001 10:15:39 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 10:15:36 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 10:15:38 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CF2@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Wed, 13 Jun 2001 10:15:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F413.514B28D0" 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_01C0F413.514B28D0 Content-Type: text/plain; charset="iso-8859-1" Well, Madjid. I agree with what you say, but would add two points: 1. I think Pat said it, but if the intradomain ARs cannot be trusted then it's game over; no amount of rules and procedures will save you if your police force is corrupt ;^}. I believe this also holds true for interdomain ARs, once the trust relationship is established between the operators. Note that I am referring to explicit DOS attacks here. Faulty ARs are a different problem, and I don't believe that you provide fault tolerance through security procedures. 2. When you get down to it, the *only* security problem the wireless operators have ever really been concerned with is theft of service. Back in the early 90s, AT&T claimed they lost $1M / day in stolen service. This was because AMP had a very simple security scheme. I am sure that operators are somewhat concerned about eavesdropping, particularly given all the high profile cases that occurred in the '90s. However, I believe that the general consensus is that the channel coding is sufficient with 2G networks. Does anyone have a real industry analysis, from the operators p.o.v? This is somewhat off track. My only observation is that I do not recall any similar conversation on DOS being reported out of 3GPP, 3GPP2, 3GIP, or MWIF. But maybe I missed it. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 12, 2001 6:17 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri > Madjid-MNAKHJI1; 'Charles > E. Perkins' > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Thanks Gary, > > See below: > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Monday, June 11, 2001 3:06 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Madjid, Charlie, et al: > Madjid, I think you have captured the essence of the real issue. > Authentication > and authorization are different, but for the most part, > authorization has > never really been needed for the internet, mainly for the reasons you > describe. > The real interesting issue (besides how to authorize every > doorknob and > aircraft carrier on the planet), is whether, in a mobile > environment, how > often > one needs to authenticate. > Consider that a mobile node travelling through the network > will, with each > > handover, open up opportunities for an interloper to steal a > service, if > that > service is only authorized and the service user is not authenticated. > > > MN>> I think the point of DoS is missed here. > Note, we are not discussing service theft here (that > is the operators problem). Stealing service by an un-authorized > user is not the issue. The issue is launching a DENIAL of service > attack by a node that can do CT (you can translate it as authorized > to do CT), so we are talking about authorizing oldAR to send CT > or authorizing newAR to request CT. > > It seems that a lot of folks are confusing service theft with > DoS attack. With service theft, you are just not paying for usage. > With DoS attack, you are making the network so busy, it can not > give service to anybody, *DENIAL* of service. > > Madjid > > ------_=_NextPart_001_01C0F413.514B28D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments Re: [seamoby] ct problem statement

Well, Madjid. I agree with what you say, but would = add two points:

        1. I think = Pat said it, but if the intradomain ARs cannot be
         = trusted then it's game over; no amount of rules and procedures
         = will save you if your police force is corrupt ;^}. I believe
         = this also holds true for interdomain ARs, once the trust = relationship
         is = established between the operators.

         Note = that I am referring to explicit DOS attacks here. Faulty
         ARs = are a different problem, and I don't believe that you
         = provide fault tolerance through security procedures.

      2. When you get down = to it, the *only* security problem the wireless
         = operators have ever really been concerned with is theft of = service.
         = Back in the early 90s, AT&T claimed they lost $1M / day in = stolen
         = service. This was because AMP had a very simple security scheme.

         I am = sure that operators are somewhat concerned about eavesdropping,
         = particularly given all the high profile cases that occurred in the = '90s.
         = However, I believe that the general consensus is that the channel =
         = coding is sufficient with 2G networks. Does anyone have a real = industry
         = analysis, from the operators p.o.v?

This is somewhat off track. My only observation is = that I do not recall any similar
conversation on DOS being reported out of 3GPP, = 3GPP2, 3GIP, or MWIF. But maybe I
missed it.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Tuesday, June 12, 2001 6:17 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri =
> Madjid-MNAKHJI1; 'Charles
> E. Perkins'
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem = statement
>
>
> Thanks Gary,
>
> See below:
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Monday, June 11, 2001 3:06 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. = Perkins'
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem = statement
>
>
> Madjid, Charlie, et al:
>   Madjid, I think you have captured = the essence of the real issue.
> Authentication
> and authorization are different, but for the = most part,
> authorization has
> never really been needed for the internet, = mainly for the reasons you
> describe.
>   The real interesting issue (besides = how to authorize every
> doorknob and
> aircraft carrier on the planet), is whether, in = a mobile
> environment, how
> often
> one needs to authenticate.
>   Consider that a mobile node = travelling through the network
> will, with each
>
> handover, open up opportunities for an = interloper to steal a
> service, if
> that
> service is only authorized and the service user = is not authenticated.
>
>
> MN>> I think the point of DoS is missed = here.
> Note, we are not discussing service theft here = (that
> is the operators problem). Stealing service by = an un-authorized
> user is not the issue. The issue is launching a = DENIAL of service
> attack by a node that can do CT (you can = translate it as authorized
> to do CT), so we are talking about authorizing = oldAR to send CT
> or authorizing newAR to request CT.
>
> It seems that a lot of folks are confusing = service theft with
> DoS attack. With service theft, you are just = not paying for usage.
> With DoS attack, you are making the network so = busy, it can not
> give service to anybody, *DENIAL* of = service.
>
> Madjid
>
>

------_=_NextPart_001_01C0F413.514B28D0-- From owner-seamoby@diameter.org Wed Jun 13 10:24: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 KAA23797 for ; Wed, 13 Jun 2001 10:24:40 -0400 (EDT) Received: (qmail 25734 invoked by alias); 13 Jun 2001 14:09:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25727 invoked by uid 200); 13 Jun 2001 14:09:55 -0000 Received: (qmail 25719 invoked from network); 13 Jun 2001 14:09:52 -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; 13 Jun 2001 14:09:52 -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 f5DEJZE10016 for ; Wed, 13 Jun 2001 10:19:35 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 10:19:23 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 10:19:24 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CF3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" Cc: "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Wed, 13 Jun 2001 10:19:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F413.D2DE64C0" 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_01C0F413.D2DE64C0 Content-Type: text/plain; charset="iso-8859-1" Phil: Kewl idea Phil, but how does this work with anything but best effort? For voice traffic, as an example, it would be better if the IP stack continued to run, and the packets were lost (up to a point). CT really has little use for good ol' vanilla BE IP. It's all the other state dependent features that were put in place for *cough* real time services. Or have I mis-read your message? Gary > -----Original Message----- > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > Sent: Wednesday, June 13, 2001 9:13 AM > To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > Hi, > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > MN>> I am not quite sure I understand your point. I am not sure > > > how spectrum overlap comes in? > > > > Sorry, what I meant was that the service areas are close > > enough that it > > makes sense to CT. If there is a long no-service time between > > both service > > areas, then CT doesn't really make that much sense, right? > > Pat, > > There are companies that build products (WRQ's reflection comes > to mind) that freeze the state of the IP stack (gracefully in > the application sense), until the flow of IP traffic can resume. > This is sort of an ultra-slow handover. I see no reason why THIS > can not be made seamless with CT. Why should CT not be capable > of accomodating this Pat? > > Thanks, > > Phil > ------_=_NextPart_001_01C0F413.D2DE64C0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement

Phil:

  Kewl idea Phil, but how does this work with anything but best effort?

  For voice traffic, as an example, it would be better if the IP stack
continued to run, and the packets were lost (up to a point).

  CT really has little use for good ol' vanilla BE IP. It's all the other
state dependent features that were put in place for *cough* real time services.

  Or have I mis-read your message?

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, June 13, 2001 9:13 AM
> To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1
> Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> wirelessinternet@internet.motlabs.com
> Subject: RE: [seamoby] RE: Authentication & Authorization
> "in-the-large"
> w as Re: [seamob y] ct problem statement
>
>
>
> Hi,
> > -----Original Message-----
> > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> 
> > > MN>> I am not quite sure I understand your point. I am not sure
> > > how spectrum overlap comes in?
> >
> > Sorry, what I meant was that the service areas are close
> > enough that it
> > makes sense to CT. If there is a long no-service time between
> > both service
> > areas, then CT doesn't really make that much sense, right?
>
> Pat,
>
> There are companies that build products (WRQ's reflection comes
> to mind) that freeze the state of the IP stack (gracefully in
> the application sense), until the flow of IP traffic can resume.
> This is sort of an ultra-slow handover.  I see no reason why THIS
> can not be made seamless with CT.  Why should CT not be capable
> of accomodating this Pat?
>
> Thanks,
>
> Phil
>

------_=_NextPart_001_01C0F413.D2DE64C0-- From owner-seamoby@diameter.org Wed Jun 13 10:30: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 KAA23907 for ; Wed, 13 Jun 2001 10:30:02 -0400 (EDT) Received: (qmail 26187 invoked by alias); 13 Jun 2001 14:14:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26175 invoked by uid 200); 13 Jun 2001 14:14:20 -0000 Received: (qmail 26146 invoked from network); 13 Jun 2001 14:14:14 -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; 13 Jun 2001 14:14:14 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5DEO3E10720; Wed, 13 Jun 2001 10:24:03 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 13 Jun 2001 10:23:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 10:23:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CF4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Arthur Ross'" , Pat Calhoun Cc: "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby-context] Re: [seamoby] DOS in wireless Date: Wed, 13 Jun 2001 10:23:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F414.763DD1A0" 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_01C0F414.763DD1A0 Content-Type: text/plain; charset="iso-8859-1" Actually, Ross, there were many "teething" problems with subscriber devices that were "inadequately tested"; not just with power control, but with many of the protocol state machines. This is of course, normal with any new technology deployment, but the effect was to jam the channel at some layer. (Far be it for me to imply that a vendor would want to build in a competitive advantage in their product by having it use slightly higher power ;^} ). Gary > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: Tuesday, June 12, 2001 1:19 PM > To: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby'; 'seamoby-context' > Subject: [seamoby-context] Re: [seamoby] DOS in wireless > > > At 6:31 -0700 06/12/2001, Pat Calhoun wrote: > >On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary Kenward wrote: > >> We all got wrapped up in this discussion of DOS and, in > particular, CT > >> related DOS. It put a smile on my face last night to > recall that with > >> wireless, it is almost trivial to mount a DOS attack > without referring > >> to any protocol nor invading the access network. The > traditional term is > >> "jamming". With the trend to lower power devices, it would > not be difficult > >> nor expensive to mount a fairly widespread, difficult to > stop attack (and > >> I'll stop there). > >> > >> Perhaps too much attention is being given to putting bars > on the windows > >> when the front door is missing. > > > There was quite a debate on this point in the original CDMA wireless > standarization activities about 10 years ago. The concern > was, not only the > malicious prankster/crook, but also the so-called "rogue > mobile", meaning > one whose power control has lost it's mind and is no longer properly > controlling its TX power. > > The debate has run out of steam, and doesn't seem to be a > serious problem > in practice. This may, in part, be due to the fact that a > phone that has > lost its power control mind is likely to be seriously broken > somehow, or > may run down its battery rapidly, thus leading its owner to > turn it off, > take it for repair, or whatever. > > The possibility of malicious DoS via plain ol' jamming is > always there. The > capacity of a SSMA link is a function of the require received > Eb/N0 and the > so-called processing gain (the ratio of the spreading BW to > the bit rate). > The effect of a jammer, intentional or inadvertent, is to > consume some of > the available capacity, depending on its power, bandwidth, etc. > > If anyone wants the long form of this, I can do maybe two > hours impromputu > presentation ... anytime, anyplace, anybody's slides! :-) > > Then there's always the proverbial Big-Brother-esque spectrum > pollution > police .... :-) > > -- ahmr > ------_=_NextPart_001_01C0F414.763DD1A0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby-context] Re: [seamoby] DOS in wireless

Actually, Ross, there were many "teething" problems with subscriber devices
that were "inadequately tested"; not just with power control, but with many of
the protocol state machines. This is of course, normal with any new technology
deployment, but the effect was to jam the channel at some layer.

(Far be it for me to imply that a vendor would want to build in a competitive
advantage in their product by having it use slightly higher power ;^} ).

Gary

> -----Original Message-----
> From: Arthur Ross [mailto:a.ross@ieee.org]
> Sent: Tuesday, June 12, 2001 1:19 PM
> To: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'; 'seamoby-context'
> Subject: [seamoby-context] Re: [seamoby] DOS in wireless
>
>
> At 6:31 -0700 06/12/2001, Pat Calhoun wrote:
> >On Tue, Jun 12, 2001 at 09:32:52AM -0400, Gary Kenward wrote:
> >> We all got wrapped up in this discussion of DOS and, in
> particular, CT
> >> related DOS. It put a smile on my face last night to
> recall that with
> >> wireless, it is almost trivial to mount a DOS attack
> without referring
> >> to any protocol nor invading the access network. The
> traditional term is
> >> "jamming". With the trend to lower power devices, it would
> not be difficult
> >> nor expensive to mount a fairly widespread, difficult to
> stop attack (and
> >> I'll stop there).
> >>
> >> Perhaps too much attention is being given to putting bars
> on the windows
> >> when the front door is missing.
> >
> There was quite a debate on this point in the original CDMA wireless
> standarization activities about 10 years ago. The concern
> was, not only the
> malicious prankster/crook, but also the so-called "rogue
> mobile", meaning
> one whose power control has lost it's mind and is no longer properly
> controlling its TX power.
>
> The debate has run out of steam, and doesn't seem to be a
> serious problem
> in practice. This may, in part, be due to the fact that a
> phone that has
> lost its power control mind is likely to be seriously broken
> somehow, or
> may run down its battery rapidly, thus leading its owner to
> turn it off,
> take it for repair, or whatever.
>
> The possibility of malicious DoS via plain ol' jamming is
> always there. The
> capacity of a SSMA link is a function of the require received
> Eb/N0 and the
> so-called processing gain (the ratio of the spreading BW to
> the bit rate).
> The effect of a jammer, intentional or inadvertent, is to
> consume some of
> the available capacity, depending on its power, bandwidth, etc.
>
> If anyone wants the long form of this, I can do maybe two
> hours impromputu
> presentation ... anytime, anyplace, anybody's slides! :-)
>
> Then there's always the proverbial Big-Brother-esque spectrum
> pollution
> police .... :-)
>
>    -- ahmr
>

------_=_NextPart_001_01C0F414.763DD1A0-- From owner-seamoby@diameter.org Wed Jun 13 12:57: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 MAA27306 for ; Wed, 13 Jun 2001 12:57:16 -0400 (EDT) Received: (qmail 29309 invoked by alias); 13 Jun 2001 16:45:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29303 invoked by uid 200); 13 Jun 2001 16:45:46 -0000 Received: (qmail 29298 invoked from network); 13 Jun 2001 16:45:44 -0000 Received: from hume.neobright.net (root@209.143.19.251) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 16:45:44 -0000 Received: from WRQ1-NorthCoast.bright.net (wrq1-northcoast.bright.net [209.143.22.124]) by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id MAA12764 for ; Wed, 13 Jun 2001 12:56:19 -0400 Received: from WRQNC7 [10.1.1.172] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for ; Wed, 13 Jun 2001 12:55:11 -0400 From: "Emil Sturniolo" To: "Phillip Neumiller" Cc: "'seamoby'" , Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Date: Wed, 13 Jun 2001 12:53:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E04844551B@meshpdc.meshnetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-MDaemon-Deliver-To: seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Phil, et al, One minor correction. As of 3/30 of this year WRQ spun us out as a separate company - NetMotion Wireless Inc. (www.NetMotionWireless.com). Sorry I've been in stealth mode on this list but trying to get a startup off the ground can be quite challenging. As for your comment Phil, CT should be compatible as well as beneficial to our technology by enhancing roam times. Not having to reestablish the state of the SA, compression, etc. each time a transition occurs would allow for much smoother handoffs. From our experience, depending on the OS, handoffs today can take a significantly long time (many, many seconds). Be glad to privately answer any questions I can on how our product works. I have one other comment on DoS attacks. It seems that much of this thread was focused on looking at this from a wireless perspective. I like to reinforce that even though wireless maybe the worst case, we must also consider transferring state between wireless and wired infrastructures. From conversations we have had with our customers, all indications point to the fact that some of their mobile devices will be tethered to a network at least part of the time. As Pat said, we need to insure that we do not create any new avenues for denial of service attacks, no matter how the mobile device is connected to the network. Cordially, Emil Sturniolo EmilS@NetMotionWireless.com 330-723-9099 Office 330-461-0326 Mobile/Vmail www.NetMotionWireless.com = = = = = = = = = = = = = = = This message contains information that may be confidential and privileged. Unless you are the addressee or are authorized by the addressee, you may not use, copy or disclose the information contained in this message. If you have received this message in error, please delete it and advise the sender. -----Original Message----- From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On Behalf Of Phillip Neumiller Sent: Wednesday, June 13, 2001 9:13 AM To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1 Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Hi, > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > MN>> I am not quite sure I understand your point. I am not sure > > how spectrum overlap comes in? > > Sorry, what I meant was that the service areas are close > enough that it > makes sense to CT. If there is a long no-service time between > both service > areas, then CT doesn't really make that much sense, right? Pat, There are companies that build products (WRQ's reflection comes to mind) that freeze the state of the IP stack (gracefully in the application sense), until the flow of IP traffic can resume. This is sort of an ultra-slow handover. I see no reason why THIS can not be made seamless with CT. Why should CT not be capable of accomodating this Pat? Thanks, Phil From owner-seamoby@diameter.org Wed Jun 13 13:13: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 NAA27695 for ; Wed, 13 Jun 2001 13:12:59 -0400 (EDT) Received: (qmail 29847 invoked by alias); 13 Jun 2001 17:01:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29841 invoked by uid 200); 13 Jun 2001 17:01:52 -0000 Received: (qmail 29836 invoked from network); 13 Jun 2001 17:01:49 -0000 Received: from antares.intnet.net (HELO mailsys01.intnet.net) (198.252.32.143) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 17:01:49 -0000 Received: from [206.112.126.222] ([206.112.126.222] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9715637; Wed, 13 Jun 2001 13:11:23 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: References: <0DF9FBC42474A24CA50F7A27FB08E04844551B@meshpdc.meshnetworks.com> Date: Wed, 13 Jun 2001 10:12:21 -0700 To: "Emil Sturniolo" , "Phillip Neumiller" From: Arthur Ross Subject: Re: [WirelessInternet] RE: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement Cc: "'seamoby'" , Sender: owner-seamoby@diameter.org Precedence: bulk At 9:53 -0700 06/13/2001, Emil Sturniolo wrote: >I have one other comment on DoS attacks. It seems that much of this thread >was focused on looking at this from a wireless perspective. I like to >reinforce that even though wireless maybe the worst case, we must also >consider transferring state between wireless and wired infrastructures. From >conversations we have had with our customers, all indications point to the >fact that some of their mobile devices will be tethered to a network at >least part of the time. As Pat said, we need to insure that we do not >create any new avenues for denial of service attacks, no matter how the >mobile device is connected to the network. > I VERY STRONGLY support this view. "Mobility" should be viewed in the broadest possible sense. Changes in point of attachment may entail changes of technology, e.g. one flavor of air interface to another, wireless to wired, one LAN to another, etc. At least we should not PRECLUDE such transitions, even though in the short term they may not be too common. Also, in this vein, the question of what IS the data source/sink entity executing the motion may eventually rise to the fore. The current view ("host"), as I have said before, may be too narrow, rooted in the historical model and insufficiently forward-looking. -- ahmr From owner-seamoby@diameter.org Wed Jun 13 14:40: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 OAA29110 for ; Wed, 13 Jun 2001 14:39:57 -0400 (EDT) Received: (qmail 32292 invoked by alias); 13 Jun 2001 18:20:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32284 invoked by uid 200); 13 Jun 2001 18:20:26 -0000 Received: (qmail 32275 invoked from network); 13 Jun 2001 18:20:23 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 18:20:23 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA26550 for ; Wed, 13 Jun 2001 11:30:57 -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 LAA04346 for ; Wed, 13 Jun 2001 11:30:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 13:30:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D83@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'seamoby'" Cc: "'seamoby-context'" , "'Allison Mankin'" Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Date: Wed, 13 Jun 2001 13:30:49 -0500 Sensitivity: Company-Confidential 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, Thanks for the new revision. I had two questions: 1- Does this mean we are ending DoS analysis? 2-Why are we concerned about Theft of service in a CT draft? Thanks, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, June 12, 2001 9:40 AM To: 'seamoby' Cc: 'seamoby-context'; 'Allison Mankin' Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Importance: High Sensitivity: Confidential Below is a revision of the second version of the problem statement draft. I have tried to accommodate Allisons' wishes, as well as John's concern over explicitly referring to DOS (I hope what I have provided is sufficient John). Bash away. Gary ============================================================================ Context and Micro-mobility Routing Working Group O. H. Levkowetz Internet Draft ABNW draft-ietf-seamoby-context-transfer-problem- P. R. Calhoun 02.txt Sun MicroSystems, Inc Expires: December 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 June 2001 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Levkowetz et al. [Page 1] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Abstract 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. Table of Contents 1 Introduction...................................................2 2 Reference Definitions..........................................3 3 The Need for Context Transfer..................................4 3.1 Scope of the Context Transfer Solution .....................5 3.2 Reference Architectures ....................................6 4 A Description of Context.......................................6 4.1 Feature ....................................................6 4.2 Feature Context ............................................7 4.3 Microflow Context ..........................................7 4.4 Common Context .............................................7 4.5 Examples of Feature Context ................................8 5 Context Transfer and Mobility..................................8 6 Forwarding Node Capabilities...................................8 7 Inter-technology Context Transfers.............................8 8 Applicability..................................................9 9 Performance Considerations.....................................9 10 Security Considerations.......................................9 11 Recommendations..............................................10 1 Introduction There are a large number of IP access networks that support hosts that are mobile. 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 a host may change frequently and rapidly. In networks where the hosts are mobile, the forwarding path through the access network must often be redirected in order to deliver the host's IP traffic to the new point of access. The success of a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. Levkowetz et al. [Page 2] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt The information required in support of a specific forwarding treatment provided to IP traffic is part of the context for that traffic. This context is comprised of configuration and state information. To minimize the impact of a path change on an IP flow, the context used at the forwarding nodes along the original path, must be replicated at the forwarding nodes along the new path. The transfer of context information may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, Policy, and possibly sub-IP protocols and services such as PPP. Context transfer at a minimum will be used to replicate the configuration information needed to establish the respective protocols and services. In addition, it may also provide the capability to replicate state information, allowing stateful protocols and services at the new node to be activated along the new path with less delay and less signalling overhead. 2 Reference Definitions Mobile Node An IP node capable of changing its point of attachment to the network. The mobile node is usually an end user host, but may be a forwarding node for a network that is itself mobile. Forwarding Node A node that supports IP forwarding within the access network. This includes all routers, gateways, servers and other nodes within the network that have IP protocol stacks and forward IP traffic to and from a mobile node. A forwarding node will be connected to one or more other forwarding nodes. Some forwarding nodes will be connected to zero or more mobile nodes. The forwarding nodes that connect to mobile nodes will do so through a layer two entity that supports wireless communications. Microflow One useful definition for the fundamental unit of IP service is the microflow. RFC 2475 [1] defines a microflow as: A single instance of an application-to application flow of packets destined to or originated from a mobile device (MN or MH), which is identified by source address, source port, destination address, destination port and protocol id. Levkowetz et al. [Page 3] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt RFC 2207 [2] provides a definition of a microflow that applies to IPSec packets. It is based on the IPSec SPI found in the AH or ESP headers. Other methods for identifying for IP microflows may be defined in the future, e.g. the Ipv6 flow label. 3 The Need for Context Transfer In networks where the hosts are mobile, the forwarding path through the access network must often be redirected in order to deliver the host's IP traffic to the new point of access. The success of a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of the impact of this traffic redirection. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. Figure 1 and 2 below illustrate an example of a handover scenario. A mobile node, MN7, is shown attached to the Internet via an access network. The forwarding nodes, FN1 through to FN7 comprise a portion of this access network. FN1 and FN7 are the last forwarding nodes before the untethered link to MN7. This last link allows the nodes to move while maintaining connectivity to the edge of the access network - e.g. the last link is wireless. For simplicity, many details of a real access network topology have been left out of the diagrams. Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. It is presumable that FN1 and FN2 have been configured to provide specific forwarding services for MN7's traffic, and that some of these services may require state information to be maintained. MN7's traffic <------------------> ------- ------- [ MN7 ]<= = = =>| FN1 |=================| FN2 |======== ------- /------- / -------/ | FN4 | /-------\ / \ / \ -------/ \------- - - -| FN7 | | FN6 |---- ------- ------- Figure 1: Path Prior to Handover Levkowetz et al. [Page 4] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt When MN7's movement results in the link to FN1 to be replaced by a link to FN7, MN7's traffic must be re-directed along a new forwarding path, illustrated in Figure 2 as the path through FN7, FN4 and FN2. In many mobile networks, this handover can occur frequently, and sometimes with little or no warning. ------- ------- - - -| FN1 |----------------| FN2 |======== ------- //------- // MN7's traffic -------/ <-----------> | FN4 | //------\ MN7's traffic // \ <-----------> // \ -------/ \------- [ MN7 ]<= = = =>| FN7 | | FN6 |---- ------- ------- Figure 2: Path Re-Directed After Handover If the forwarding treatment provided to MN7's traffic is to be sustained, the support conditions at FN1 and FN2 must be reproduced at FN7 and FN4. At the very least, this requires that FN7 and FN4 be configured to provide the appropriate support to the traffic flow. However, establishing forwarding support along the new path through the use of IP signalling protocols would be relatively time consuming. In addition, given that some forwarding services may maintain state information, simply configuring FN7 and FN4 would not circumvent disruption of the services. Given that FN7 and FN4 support the same functionality as FN1, it should be possible to reproduce the needed support along the new forwarding path by capturing the salient information at FN1 as it exists just prior to the handover, and then use that information to replicate the state of FN1 at FN7 and FN4. 3.1 Scope of the Context Transfer Solution The information required to produce the necessary forwarding treatments at a node is referred to as the support "context". In order to replicate the context of one forwarding node at another forwarding node, an open, standard solution for context transfer must be developed. Levkowetz et al. [Page 5] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In addition, for a forwarding node to be able to interpret the transferred context, both the syntax and the semantics of the context information must be defined. Definition of the actual context information will be specific to the support feature being replicated, however, a generic container format of the payload of context transfer messages is required for inter-operability. 3.2 Reference Architectures The concept of the "forwarding node" is used here to describe the general context transfer problem. In different networks, the actual context transfer may take place between different entities within the network. In some cases the preferred context transfer peers might be the routers at the edge of the access network. In other situations, it may be more appropriate to transfer context between wireless access points that also support forwarding of IP packets. The context transfer solution will be applicable to any nodes that support forwarding of a mobile nodes IP traffic. 4 A Description of Context The term ` `context' ' pertains to all information required by a forwarding node specific to supporting the IP traffic for a particular mobile node. The context for a mobile node can be partitioned into three categories: - information required to provide generally support to the mobile node; - information required to provide common support to the mobile node's traffic; - information required to support specific features of the forwarding treatment for an IP microflow. 4.1 Feature A feature is an aspect of the IP forwarding treatment that is instantiated for each mobile node, and which may support one or more of the mobile nodes microflows. A feature must include associated configuration information: at the very least, some identification information for the mobile node, such as the mobile node's IP address. A feature may have associated state information. Levkowetz et al. [Page 6] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In other words, for the purpose of supporting mobility the features of interest all have context pertinent to the forwarding of a specific mobile nodes IP packets. Examples of features include: header compression, security, subscriber policy, and quality of service. Each feature is, in general, supported by an amalgamation of one or more protocols and associated local support mechanisms. As an example, header compression is a feature that consists of various "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP header compression, operating according to well-defined "protocols". Thus, an instance of a feature reflects the state associated with protocols and the corresponding mechanisms. 4.2 Feature Context Feature context is the condition or state of an instance of a particular feature. It represents the current evolution of the behaviour of that feature instance. At a given instant in time, feature context is represented by the values of the associated data elements. Some of the data elements associated with a feature are time invariant and, thus, represent the configuration of the feature instance. Other data elements, which are often referred to as the "state variables" for the feature instance, change value over time as a consequence of the various operations performed in support of the feature instance. A feature context is believed to be the smallest indivisible unit of context that can be transferred between forwarding nodes. 4.3 Microflow Context A microflow context is the collection of the various feature contexts associated with a single IP microflow. It is the smallest unit of context that must be transferred in order to re-establish support for the microflow at a forwarding node. 4.4 Common Context Some of the associated feature contexts may be applicable to more then one of the IP microflows comprising the mobile node's traffic. An example of this might be the authentication state for the mobile. This type of feature context is also required to support each microflow, but because of the multiplicity of the relationship to the mobile node's microflows, it would seem prudent to transfer one instance of the context, independent of the microflow context. Levkowetz et al. [Page 7] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt 4.5 Examples of Feature Context Some examples of feature contexts that are candidates for context transfer are given below. This list is provided solely to illustrate the nature of the context transfer problem domain. - encryption context; - authentication context; - authorization context; - accounting context; - header compression context; - quality of service context; - policy enforcement context; - multicast group membership; - buffer state; - sub-network layer context (e.g. PPP context). 5 Context Transfer and Mobility Context transfer is an enhancement to a mobility solution that is clearly most effective when used on a local scale between forwarding nodes within a subnetwork. However, with due consideration to the nature of the context and the requirements for transfer of that context, context transfer should be applicable between any two similar forwarding nodes. 6 Forwarding Node Capabilities Context transfer between two forwarding nodes is worthwhile only if the receiving node's capabilities are similar enough to those of the sending node that the received context can be utilized. This does not mean that the two nodes are identical in their implementation, nor does it even imply that they must have identical capabilities. A forwarding node that cannot make use of received context could, and should, refuse the transfer. This would result in a situation no different then mobile handover without context transfer. 7 Inter-technology Context Transfers The context transfer described here operates at the IP layer, and should be applicable to situations where the forwarding nodes are supporting different wireless link technologies. Levkowetz et al. [Page 8] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt An exception to this would be where sub-IP layer context is an intrinsic part of the forwarding treatment. In this situation, an interworking solution must be developed for sub-IP context transfer between the two technologies. This issue is outside the scope of the Seamoby working group. 8 Applicability The primary motivation for developing an IP context transfer assumes that service sustainment during handover is desirable. And yet, there may be situations where either the user or the access network would prefer to re-establish or re-negotiate a service or a service feature. For example, if the mobile node crosses administration domains where the operational policies change, negotiation of a different level of service may be required by the respective operators. More important, the concept of context transfer also assumes that the service is worth sustaining through a variety of handover scenarios, and that context transfer is the best approach. The former may not be true for certain types of service - for example, multicast, "push" information services. In addition, even if service level sustainment is desirable, context transfer may not be the most cost efficient solution. Alternatives to context transfer for sustaining services during handover are out of scope for the Seamoby working group. The possibility of other solutions is only noted here to emphasize that context transfer is but one of possibly many approaches. Finally, context transfer is an enhancement at the IP level to improve upon the performance of a handover between IP forwarding nodes. Many networks provide support for handover at the link layer, within and between subnetworks, and context transfer may not provide a significant improvement over the these link layer solutions. 9 Performance Considerations The purpose of context transfer is to sustain the services being provided to a mobile node's traffic during handover. It is essentially an enhancement to a mobility solution that ultimately must result in an improvement in handover performance. The various aspects of performance must be a prime consideration in the development of the context transfer solution. 10 Security Considerations Some of the considerations for context transfer security include: Levkowetz et al. [Page 9] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt - information privacy: the context may contain information which the end user would prefer to keep hidden from unauthorized viewers. - transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving forwarding node, and therefore could potentially affect the operation of the access network itself; the potential threats include denial of service and theft of service attacks; context transfer must only occur between forwarding nodes that have an established trust relationship. - security preservation: part of the context transfer may include information pertinent to a security association established between the mobile node and another entity on the network; for this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures. It is expected that the measures used to secure the transport of information between peers in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions. The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions. 11 Recommendations The Seamoby context transfer design team recommends the following: - investigation into candidates for context transfer - in particular, feature context transfer, and an analysis of the transfer requirements for each candidate; - the development of a framework and protocol(s) that will support the transfer of configuration and state context between the forwarding nodes of an IP network. The context transfer solution must interwork with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network. References Levkowetz et al. [Page 10] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt [1] Blake, et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. Authors' Addresses O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN Phone: +46 8 477 9942 EMail: henrik@levkowetz.com Pat R. Calhoun Network and Security Research Center, Sun Labs 15 Network Circle Menlo Park CA 94025 USA Phone: +1 650-786-7733 EMail: pcalhoun@eng.sun.com Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA Phone: +1 613-765-1437 EMail: gkenward@nortelnetworks.com Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA Phone: +1 613 763-6553 EMail: hmsyed@nortelnetworks.com Jukka Manner Department of Computer Science, University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND Levkowetz et al. [Page 11] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Phone: +358-9-191-44210 EMail: jmanner@cs.helsinki.fi Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA Phone: +1 847-632-5030 EMail: madjid.nakhjiri@motorola.com Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA Phone: +1 781 993 3627 EMail: govind.krishnamurthi@nokia.com Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA Phone: +1 650 625 2359 EMail: rajeev.koodli@nokia.com Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA Phone: +1 613 789 0090 EMail: kulwinder.atwal@zucotto.com Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA Phone: +1 408 525 5386 Levkowetz et al. [Page 12] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt EMail: mat@cisco.com Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA Phone: +1 805 544 1089 EMail: mat.horan@comdev.cc Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA EMail: phil_neumiller@3com.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Levkowetz et al. [Page 13] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Funding for the RFC editor function is currently provided by the Internet Society. Levkowetz et al. [Page 14] From owner-seamoby@diameter.org Wed Jun 13 15:23: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 PAA29877 for ; Wed, 13 Jun 2001 15:23:30 -0400 (EDT) Received: (qmail 3219 invoked by alias); 13 Jun 2001 19:08:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3212 invoked by uid 200); 13 Jun 2001 19:08:21 -0000 Received: (qmail 3199 invoked from network); 13 Jun 2001 19:08:18 -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; 13 Jun 2001 19:08:18 -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 f5DJI9E28224 for ; Wed, 13 Jun 2001 15:18:09 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 15:18:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 15:18:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5CFF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Emil Sturniolo'" , Phillip Neumiller Cc: "'seamoby'" , wirelessinternet Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Wed, 13 Jun 2001 15:17:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F43D.8CC420E0" 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_01C0F43D.8CC420E0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Emil Sturniolo [mailto:EmilS@NetMotionWireless.com] > Sent: Wednesday, June 13, 2001 12:53 PM > To: Phillip Neumiller > Cc: 'seamoby'; wirelessinternet > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > was Re: [seamob y] ct problem statement > > *snip* > occurs would allow for much smoother handoffs. From our experience, > depending on the OS, handoffs today can take a significantly long time > (many, many seconds). Be glad to privately answer any It's scraps of information like this that makes ARDiS, Mobitex, DataTAC look like really, really good mobile wireless data solutions (Phil at least should understand my reference ;^} ). In those networks, handovers are measured in terms of tens of milliseconds, not seconds. *sigh* Gary *snip* > > ------_=_NextPart_001_01C0F43D.8CC420E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] RE: Authentication & Authorization = "in-the-large" was Re: [seamob y] ct problem = statement

> -----Original Message-----
> From: Emil Sturniolo [mailto:EmilS@NetMotionWirele= ss.com]
> Sent: Wednesday, June 13, 2001 12:53 PM
> To: Phillip Neumiller
> Cc: 'seamoby'; wirelessinternet
> Subject: RE: [seamoby] RE: Authentication & = Authorization
> "in-the-large"
> was Re: [seamob y] ct problem statement
>
>

*snip*

> occurs would allow for much smoother handoffs. = From our experience,
> depending on the OS, handoffs today can take a = significantly long time
> (many, many seconds). Be glad to privately = answer any

It's scraps of information like this that makes = ARDiS, Mobitex, DataTAC look like really, really good mobile wireless = data solutions (Phil at least should understand

my reference ;^} ). In those networks, handovers are = measured in terms of tens of milliseconds, not seconds.

*sigh*

Gary

*snip*

>
>

------_=_NextPart_001_01C0F43D.8CC420E0-- From owner-seamoby@diameter.org Wed Jun 13 15:58: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 PAA00470 for ; Wed, 13 Jun 2001 15:57:34 -0400 (EDT) Received: (qmail 4540 invoked by alias); 13 Jun 2001 19:37:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4528 invoked by uid 200); 13 Jun 2001 19:37:02 -0000 Received: (qmail 4518 invoked from network); 13 Jun 2001 19:36:58 -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; 13 Jun 2001 19:36:58 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5DJkoE02586 for ; Wed, 13 Jun 2001 15:46:50 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 13 Jun 2001 15:46:43 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 15:46:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" Cc: "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Date: Wed, 13 Jun 2001 15:46:26 -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 Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, June 13, 2001 2:31 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby' > Cc: 'seamoby-context'; 'Allison Mankin' > Subject: RE: [seamoby] > draft-ietf-seamoby-context-transfer-problem-02.txt > Sensitivity: Confidential > > > Gary, > > Thanks for the new revision. > > I had two questions: > > 1- Does this mean we are ending DoS analysis? Nothing ever ends. What would you rather do, get a problem statement completed for approval by the IESG, or debate DOS? > > 2-Why are we concerned about Theft of service in a CT draft? TOS is the primary reason for authentication. I don't know if there is a problem here, and I don't want to analyze it for the ps. It's only provided as an example. Gary > > Thanks, > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, June 12, 2001 9:40 AM > To: 'seamoby' > Cc: 'seamoby-context'; 'Allison Mankin' > Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt > Importance: High > Sensitivity: Confidential > > > Below is a revision of the second version of the problem > statement draft. > I have tried to accommodate Allisons' wishes, as well as > John's concern over > explicitly referring to DOS (I hope what I have provided is sufficient > John). > > Bash away. > > Gary > > ============================================================== > ============== > > > Context and Micro-mobility Routing Working Group > O. H. Levkowetz > Internet Draft > ABNW > draft-ietf-seamoby-context-transfer-problem- > P. R. Calhoun > 02.txt Sun > MicroSystems, Inc > Expires: December 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 > > June 2001 > > > Problem Description: Reasons For Performing Context > Transfers > Between Nodes in an IP Access Network > > 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. > > Copyright Notice > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > Levkowetz et al. > [Page 1] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > Abstract > > 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. > > > Table of Contents > > 1 > Introduction...................................................2 > 2 Reference > Definitions..........................................3 > 3 The Need for Context > Transfer..................................4 > 3.1 Scope of the Context Transfer Solution > .....................5 > 3.2 Reference Architectures > ....................................6 > 4 A Description of > Context.......................................6 > 4.1 Feature > ....................................................6 > 4.2 Feature Context > ............................................7 > 4.3 Microflow Context > ..........................................7 > 4.4 Common Context > .............................................7 > 4.5 Examples of Feature Context > ................................8 > 5 Context Transfer and > Mobility..................................8 > 6 Forwarding Node > Capabilities...................................8 > 7 Inter-technology Context > Transfers.............................8 > 8 > Applicability..................................................9 > 9 Performance > Considerations.....................................9 > 10 Security > Considerations.......................................9 > 11 > Recommendations..............................................10 > > > 1 Introduction > > There are a large number of IP access networks that > support hosts > that are mobile. 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 a host may > change frequently and rapidly. > > In networks where the hosts are mobile, the > forwarding path through > the access network must often be redirected in order > to deliver the > host's IP traffic to the new point of access. The > success of a time > sensitive service such as VoIP telephony, video, > etc., in a mobile > environment depends heavily upon the minimization of > the impact of > this traffic redirection. In the process of > establishing the new > forwarding path, the nodes along the new path must be > prepared to > provide similar forwarding treatment to the IP packets. > > Levkowetz et al. > [Page 2] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > The information required in support of a specific forwarding > treatment provided to IP traffic is part of the > context for that > traffic. This context is comprised of configuration and state > information. To minimize the impact of a path change > on an IP flow, > the context used at the forwarding nodes along the > original path, > must be replicated at the forwarding nodes along the > new path. > > The transfer of context information may be advantageous in > minimizing the impact of host mobility on, for > example, AAA, header > compression, QoS, Policy, and possibly sub-IP > protocols and services > > such as PPP. Context transfer at a minimum will be > used to replicate > > the configuration information needed to establish the > respective > protocols and services. In addition, it may also provide the > capability to replicate state information, allowing stateful > protocols and services at the new node to be > activated along the new > > path with less delay and less signalling overhead. > > > 2 Reference Definitions > > Mobile Node > > An IP node capable of changing its point of attachment to the > network. The mobile node is usually an end user host, > but may be a > forwarding node for a network that is itself mobile. > > Forwarding Node > > A node that supports IP forwarding within the access > network. This > includes all routers, gateways, servers and other > nodes within the > network that have IP protocol stacks and forward IP > traffic to and > from a mobile node. > > A forwarding node will be connected to one or more > other forwarding > nodes. Some forwarding nodes will be connected to > zero or more > mobile nodes. The forwarding nodes that connect to > mobile nodes will > > do so through a layer two entity that supports wireless > communications. > > Microflow > > One useful definition for the fundamental unit of IP > service is the > microflow. RFC 2475 [1] defines a microflow as: > > A single instance of an application-to application > flow of packets > destined to or originated from a mobile device (MN or > MH), which is > identified by source address, source port, > destination address, > destination port and protocol id. > > > Levkowetz et al. > [Page 3] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > RFC 2207 [2] provides a definition of a microflow > that applies to > IPSec packets. It is based on the IPSec SPI found in > the AH or ESP > headers. Other methods for identifying for IP > microflows may be > defined in the future, e.g. the Ipv6 flow label. > > > 3 The Need for Context Transfer > > In networks where the hosts are mobile, the > forwarding path through > the access network must often be redirected in order > to deliver the > host's IP traffic to the new point of access. The > success of a time > sensitive service such as VoIP telephony, video, > etc., in a mobile > environment depends heavily upon the minimization of > the impact of > this traffic redirection. In the process of > establishing the new > forwarding path, the nodes along the new path must be > prepared to > provide similar forwarding treatment to the IP packets. > > Figure 1 and 2 below illustrate an example of a > handover scenario. A > > mobile node, MN7, is shown attached to the Internet > via an access > network. The forwarding nodes, FN1 through to FN7 > comprise a portion > > of this access network. FN1 and FN7 are the last > forwarding nodes > before the untethered link to MN7. This last link > allows the nodes > to move while maintaining connectivity to the edge of > the access > network - e.g. the last link is wireless. For > simplicity, many > details of a real access network topology have been > left out of the > diagrams. > > Prior to handoff, the path for MN7's traffic > traverses FN1 and FN2. > It is presumable that FN1 and FN2 have been > configured to provide > specific forwarding services for MN7's traffic, and > that some of > these services may require state information to be > maintained. > > > > MN7's traffic > > <------------------> > > ------- ------- > > [ MN7 ]<= = = =>| FN1 |=================| FN2 > |======== > ------- /------- > > / > > -------/ > > | FN4 | > > /-------\ > > / \ > > / \ > > -------/ > \------- > - - -| FN7 | | FN6 > |---- > ------- > ------- > > > Figure 1: Path Prior to Handover > > > > > > Levkowetz et al. > [Page 4] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > When MN7's movement results in the link to FN1 to be > replaced by a > link to FN7, MN7's traffic must be re-directed along a new > forwarding path, illustrated in Figure 2 as the path > through FN7, > FN4 and FN2. In many mobile networks, this handover can occur > frequently, and sometimes with little or no warning. > ------- ------- > > - - -| FN1 |----------------| FN2 > |======== > ------- //------- > > // MN7's > traffic > -------/ > <-----------> > | FN4 | > > //------\ > > MN7's traffic // \ > > <-----------> // \ > > -------/ > \------- > [ MN7 ]<= = = =>| FN7 | | FN6 > |---- > ------- > ------- > > > Figure 2: Path Re-Directed After Handover > > > > > If the forwarding treatment provided to MN7's traffic > is to be > sustained, the support conditions at FN1 and FN2 must > be reproduced > at FN7 and FN4. At the very least, this requires that > FN7 and FN4 be > > configured to provide the appropriate support to the > traffic flow. > However, establishing forwarding support along the > new path through > the use of IP signalling protocols would be relatively time > consuming. In addition, given that some forwarding > services may > maintain state information, simply configuring FN7 > and FN4 would not > > circumvent disruption of the services. > > Given that FN7 and FN4 support the same functionality > as FN1, it > should be possible to reproduce the needed support > along the new > forwarding path by capturing the salient information > at FN1 as it > exists just prior to the handover, and then use that > information to > replicate the state of FN1 at FN7 and FN4. > > > 3.1 Scope of the Context Transfer Solution > > The information required to produce the necessary forwarding > treatments at a node is referred to as the support > "context". In > order to replicate the context of one forwarding node > at another > forwarding node, an open, standard solution for > context transfer > must be developed. > > > Levkowetz et al. > [Page 5] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > In addition, for a forwarding node to be able to > interpret the > transferred context, both the syntax and the semantics of the > context information must be defined. Definition of the actual > context information will be specific to the support > feature being > replicated, however, a generic container format of > the payload of > context transfer messages is required for inter-operability. > > > 3.2 Reference Architectures > > The concept of the "forwarding node" is used here to > describe the > general context transfer problem. In different > networks, the actual > context transfer may take place between different > entities within > the network. In some cases the preferred context > transfer peers > might be the routers at the edge of the access > network. In other > situations, it may be more appropriate to transfer > context between > wireless access points that also support forwarding > of IP packets. > > The context transfer solution will be applicable to > any nodes that > support forwarding of a mobile nodes IP traffic. > > > 4 A Description of Context > > The term ` > `context' > ' pertains to all information required by a > forwarding node specific to supporting the IP traffic for a > particular mobile node. > > The context for a mobile node can be partitioned into three > categories: > > - information required to provide generally > support to the > mobile node; > > - information required to provide common > support to the > mobile node's traffic; > > - information required to support specific > features of the > forwarding treatment for an IP microflow. > > > 4.1 Feature > > A feature is an aspect of the IP forwarding treatment that is > instantiated for each mobile node, and which may > support one or more > > of the mobile nodes microflows. A feature must > include associated > configuration information: at the very least, some > identification > information for the mobile node, such as the mobile node's IP > address. A feature may have associated state information. > > > Levkowetz et al. > [Page 6] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > In other words, for the purpose of supporting > mobility the features > of interest all have context pertinent to the forwarding of a > specific mobile nodes IP packets. Examples of > features include: > header compression, security, subscriber policy, and > quality of > service. > > Each feature is, in general, supported by an > amalgamation of one or > more protocols and associated local support mechanisms. As an > example, header compression is a feature that > consists of various > "mechanisms" such as IP/TCP header compression and > IPv6/UDP/RTP > header compression, operating according to > well-defined "protocols". > > Thus, an instance of a feature reflects the state > associated with > protocols and the corresponding mechanisms. > > > 4.2 Feature Context > > Feature context is the condition or state of an instance of a > particular feature. It represents the current > evolution of the > behaviour of that feature instance. At a given > instant in time, > feature context is represented by the values of the > associated data > elements. > > Some of the data elements associated with a feature are time > invariant and, thus, represent the configuration of > the feature > instance. Other data elements, which are often > referred to as the > "state variables" for the feature instance, change > value over time > as a consequence of the various operations performed > in support of > the feature instance. > > A feature context is believed to be the smallest > indivisible unit of > > context that can be transferred between forwarding nodes. > > > 4.3 Microflow Context > > A microflow context is the collection of the various feature > contexts associated with a single IP microflow. It is > the smallest > unit of context that must be transferred in order to > re-establish > support for the microflow at a forwarding node. > > > 4.4 Common Context > > Some of the associated feature contexts may be > applicable to more > then one of the IP microflows comprising the mobile > node's traffic. > An example of this might be the authentication state > for the mobile. > > This type of feature context is also required to support each > microflow, but because of the multiplicity of the > relationship to > the mobile node's microflows, it would seem prudent > to transfer one > instance of the context, independent of the microflow > context. > > Levkowetz et al. > [Page 7] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > > 4.5 Examples of Feature Context > > Some examples of feature contexts that are candidates > for context > transfer are given below. This list is provided > solely to illustrate > > the nature of the context transfer problem domain. > > - encryption context; > - authentication context; > - authorization context; > - accounting context; > - header compression context; > - quality of service context; > - policy enforcement context; > - multicast group membership; > - buffer state; > - sub-network layer context (e.g. PPP context). > > > 5 Context Transfer and Mobility > > Context transfer is an enhancement to a mobility > solution that is > clearly most effective when used on a local scale > between forwarding > > nodes within a subnetwork. However, with due > consideration to the > nature of the context and the requirements for > transfer of that > context, context transfer should be applicable > between any two > similar forwarding nodes. > > > 6 Forwarding Node Capabilities > > Context transfer between two forwarding nodes is > worthwhile only if > the receiving node's capabilities are similar enough > to those of the > > sending node that the received context can be > utilized. This does > not mean that the two nodes are identical in their > implementation, > nor does it even imply that they must have identical > capabilities. > > A forwarding node that cannot make use of received > context could, > and should, refuse the transfer. This would result in > a situation no > > different then mobile handover without context transfer. > > > 7 Inter-technology Context Transfers > > The context transfer described here operates at the > IP layer, and > should be applicable to situations where the > forwarding nodes are > supporting different wireless link technologies. > > > Levkowetz et al. > [Page 8] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > An exception to this would be where sub-IP layer > context is an > intrinsic part of the forwarding treatment. In this > situation, an > interworking solution must be developed for sub-IP > context transfer > between the two technologies. This issue is outside > the scope of the > > Seamoby working group. > > > 8 Applicability > > The primary motivation for developing an IP context > transfer assumes > > that service sustainment during handover is > desirable. And yet, > there may be situations where either the user or the > access network > would prefer to re-establish or re-negotiate a > service or a service > feature. For example, if the mobile node crosses > administration > domains where the operational policies change, > negotiation of a > different level of service may be required by the respective > operators. > > More important, the concept of context transfer also > assumes that > the service is worth sustaining through a variety of handover > scenarios, and that context transfer is the best > approach. The > former may not be true for certain types of service - > for example, > multicast, "push" information services. In addition, > even if service > > level sustainment is desirable, context transfer may > not be the most > > cost efficient solution. > > Alternatives to context transfer for sustaining > services during > handover are out of scope for the Seamoby working group. The > possibility of other solutions is only noted here to > emphasize that > context transfer is but one of possibly many approaches. > > Finally, context transfer is an enhancement at the IP > level to > improve upon the performance of a handover between IP > forwarding > nodes. Many networks provide support for handover at > the link layer, > > within and between subnetworks, and context transfer > may not provide > > a significant improvement over the these link layer > solutions. > > > 9 Performance Considerations > > The purpose of context transfer is to sustain the > services being > provided to a mobile node's traffic during handover. It is > essentially an enhancement to a mobility solution > that ultimately > must result in an improvement in handover > performance. The various > aspects of performance must be a prime consideration in the > development of the context transfer solution. > > > 10 Security Considerations > > Some of the considerations for context transfer > security include: > > Levkowetz et al. > [Page 9] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > - information privacy: the context may > contain information > which the end user would prefer to keep hidden from > unauthorized viewers. > > - transfer legitimacy: a false or purposely corrupted > context transfer could have a severe impact > upon the > operation of the receiving forwarding node, > and therefore > could potentially affect the operation of > the access > network itself; the potential threats > include denial of > service and theft of service attacks; > context transfer > must only occur between forwarding nodes > that have an > established trust relationship. > > - security preservation: part of the context > transfer may > include information pertinent to a security > association > established between the mobile node and > another entity on > > the network; for this security association > to be preserved > > during handover, the transfer of the > security context > must include the appropriate security measures. > > It is expected that the measures used to secure the > transport of > information between peers in an IP network should be > sufficient for > context transfer. However, given the above > considerations, there > may be reason to provide for additional security > measures beyond the > > available IETF solutions. > > The context transfer investigation must identify any > novel security > > measures required for context transfer that exceed > the capabilities > > of the existing or emerging IETF solutions. > > > 11 Recommendations > > The Seamoby context transfer design team recommends > the following: > > - investigation into candidates for context > transfer - in > particular, feature context transfer, and > an analysis > of the transfer requirements for each candidate; > > - the development of a framework and > protocol(s) that will > support the transfer of configuration and > state context > between the forwarding nodes of an IP network. > > The context transfer solution must interwork with > existing and > emerging IP protocols, in particular, those protocols > supporting > mobility in an IP network. > > > References > > > Levkowetz et al. > [Page 10] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > [1] Blake, et al., "An Architecture for > Differentiated Services", > RFC 2475, December 1998. > > [2] Berger & O'Malley, "RSVP Extensions for IPSEC > Data Flows", > RFC 2207, September 1997. > > Authors' Addresses > O. Henrik Levkowetz > A Brand New World > Osterogatan 1 > S-164 28 Kista > SWEDEN > > Phone: +46 8 477 9942 > EMail: henrik@levkowetz.com > > > Pat R. Calhoun > Network and Security Research Center, Sun Labs > 15 Network Circle > Menlo Park CA 94025 > USA > > Phone: +1 650-786-7733 > EMail: pcalhoun@eng.sun.com > > > Gary Kenward > Nortel Networks > 3500 Carling Avenue > Nepean, Ontario K2G 6J8 > CANADA > > Phone: +1 613-765-1437 > EMail: gkenward@nortelnetworks.com > > > Hamid Syed > Nortel Networks > 100 Constellation Crescent > Nepean Ontario K2G 6J8 > CANADA > > Phone: +1 613 763-6553 > EMail: hmsyed@nortelnetworks.com > > Jukka Manner > Department of Computer Science, University of Helsinki > P.O. Box 26 (Teollisuuskatu 23) > FIN-00014 Helsinki > FINLAND > > Levkowetz et al. > [Page 11] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > Phone: +358-9-191-44210 > EMail: jmanner@cs.helsinki.fi > > > Madjid Nakhjiri > Motorola > 1501 West Shure Drive > Arlington Heights IL 60004 > USA > > Phone: +1 847-632-5030 > EMail: madjid.nakhjiri@motorola.com > > > Govind Krishnamurthi > Communications Systems Laboratory, Nokia Research Center > 5 Wayside Road > Burlington MA 01803 > USA > > Phone: +1 781 993 3627 > EMail: govind.krishnamurthi@nokia.com > > > Rajeev Koodli > Communications Systems Lab, Nokia Research Center > 313 Fairchild Drive > Mountain View CA 94043 > USA > > Phone: +1 650 625 2359 > EMail: rajeev.koodli@nokia.com > > > Kulwinder S. Atwal > Zucotto Wireless Inc. > Ottawa Ontario K1P 6E2 > CANADA > > Phone: +1 613 789 0090 > EMail: kulwinder.atwal@zucotto.com > > > Michael Thomas > Cisco Systems > 375 E Tasman Rd > San Jose CA 95134 > USA > > Phone: +1 408 525 5386 > > Levkowetz et al. > [Page 12] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > EMail: mat@cisco.com > > > Mat Horan > COM DEV Wireless Group > San Luis Obispo CA 93401 > USA > > Phone: +1 805 544 1089 > EMail: mat.horan@comdev.cc > > > Phillip Neumiller > 3Com Corporation > 1800 W. Central Road > Mount Prospect IL 60056 > USA > > EMail: phil_neumiller@3com.com > > > Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > This document and translations of it may be copied > and furnished to > others, and derivative works that comment on or > otherwise explain it > > or assist in its implementation may be prepared, > copied, published > and distributed, in whole or in part, without > restriction of any > kind, provided that the above copyright notice and > this paragraph > are included on all such copies and derivative works. > However, this > document itself may not be modified in any way, such > as by removing > the copyright notice or references to the Internet > Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the > procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into > languages other than > English. > > The limited permissions granted above are perpetual > and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is > provided on an > > "AS IS" basis and THE INTERNET SOCIETY AND THE > INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgement > > > Levkowetz et al. > [Page 13] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > Funding for the RFC editor function is currently > provided by the > Internet Society. > > Levkowetz et al. > [Page 14] > > From owner-seamoby@diameter.org Wed Jun 13 18:30: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 SAA02773 for ; Wed, 13 Jun 2001 18:30:23 -0400 (EDT) Received: (qmail 7050 invoked by alias); 13 Jun 2001 22:18:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7044 invoked by uid 200); 13 Jun 2001 22:18:00 -0000 Received: (qmail 7039 invoked from network); 13 Jun 2001 22:17:58 -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; 13 Jun 2001 22:17:58 -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 f5DMRpE20254 for ; Wed, 13 Jun 2001 18:27:51 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 18:27:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 18:27:59 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D0D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Arthur Ross'" , Emil Sturniolo , Phillip Neumiller Cc: "'seamoby'" , wirelessinternet Subject: RE: [WirelessInternet] RE: [seamoby] RE: Authentication & Author ization "in-the-large" was Re: [seamob y] ct problem statement Date: Wed, 13 Jun 2001 18:28:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F458.1A3D0580" 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_01C0F458.1A3D0580 Content-Type: text/plain; charset="iso-8859-1" Great idea Arthur and Emil. Indeed, this is where Seamoby started, 6 months ago. But somehow, we cannot even seem to get agreements on ct even for a narrow definition of mobility. I think I'm going to try to figure out how to climb Mt. BlackComb before I attempt to climb K2. Gary > -----Original Message----- > From: Arthur Ross [mailto:a.ross@ieee.org] > Sent: Wednesday, June 13, 2001 1:12 PM > To: Emil Sturniolo; Phillip Neumiller > Cc: 'seamoby'; wirelessinternet > Subject: Re: [WirelessInternet] RE: [seamoby] RE: Authentication & > Authorization "in-the-large" was Re: [seamob y] ct problem statement > > > At 9:53 -0700 06/13/2001, Emil Sturniolo wrote: > >I have one other comment on DoS attacks. It seems that much > of this thread > >was focused on looking at this from a wireless perspective. I like to > >reinforce that even though wireless maybe the worst case, we > must also > >consider transferring state between wireless and wired > infrastructures. From > >conversations we have had with our customers, all > indications point to the > >fact that some of their mobile devices will be tethered to a > network at > >least part of the time. As Pat said, we need to insure that > we do not > >create any new avenues for denial of service attacks, no > matter how the > >mobile device is connected to the network. > > > I VERY STRONGLY support this view. "Mobility" should be viewed in the > broadest possible sense. Changes in point of attachment may > entail changes > of technology, e.g. one flavor of air interface to another, > wireless to > wired, one LAN to another, etc. At least we should not PRECLUDE such > transitions, even though in the short term they may not be too common. > > Also, in this vein, the question of what IS the data > source/sink entity > executing the motion may eventually rise to the fore. The current view > ("host"), as I have said before, may be too narrow, rooted in the > historical model and insufficiently forward-looking. > > -- ahmr > ------_=_NextPart_001_01C0F458.1A3D0580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [WirelessInternet] RE: [seamoby] RE: Authentication & = Authorization "in-the-large" was Re: [seamob y] ct problem = statement

Great idea Arthur and Emil.
Indeed, this is where Seamoby started, 6 months = ago.

But somehow, we cannot even seem to get agreements on = ct even for a narrow definition of mobility. I think I'm going to try = to figure out how to climb Mt. BlackComb before I attempt to climb = K2.

Gary

> -----Original Message-----
> From: Arthur Ross [mailto:a.ross@ieee.org]
> Sent: Wednesday, June 13, 2001 1:12 PM
> To: Emil Sturniolo; Phillip Neumiller
> Cc: 'seamoby'; wirelessinternet
> Subject: Re: [WirelessInternet] RE: [seamoby] = RE: Authentication &
> Authorization "in-the-large" was Re: = [seamob y] ct problem statement
>
>
> At 9:53 -0700 06/13/2001, Emil Sturniolo = wrote:
> >I have one other comment on DoS attacks. It = seems that much
> of this thread
> >was focused on looking at this from a = wireless perspective. I like to
> >reinforce that even though wireless maybe = the worst case, we
> must also
> >consider transferring state between = wireless and wired
> infrastructures. From
> >conversations we have had with our = customers, all
> indications point to the
> >fact that some of their mobile devices will = be tethered to a
> network at
> >least part of the time.  As Pat said, = we need to insure that
> we do not
> >create any new avenues for denial of = service attacks, no
> matter how the
> >mobile device is connected to the = network.
> >
> I VERY STRONGLY support this view. = "Mobility" should be viewed in the
> broadest possible sense. Changes in point of = attachment may
> entail changes
> of technology, e.g. one flavor of air interface = to another,
> wireless to
> wired, one LAN to another, etc. At least we = should not PRECLUDE such
> transitions, even though in the short term they = may not be too common.
>
> Also, in this vein, the question of what IS the = data
> source/sink entity
> executing the motion may eventually rise to the = fore. The current view
> ("host"), as I have said before, may = be too narrow, rooted in the
> historical model and insufficiently = forward-looking.
>
>    -- ahmr
>

------_=_NextPart_001_01C0F458.1A3D0580-- From owner-seamoby@diameter.org Wed Jun 13 18:48: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 SAA02959 for ; Wed, 13 Jun 2001 18:48:05 -0400 (EDT) Received: (qmail 7599 invoked by alias); 13 Jun 2001 22:23:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7593 invoked by uid 200); 13 Jun 2001 22:23:31 -0000 Received: (qmail 7564 invoked from network); 13 Jun 2001 22:23:21 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jun 2001 22:23:21 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA06053 for ; Wed, 13 Jun 2001 15:27:10 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA12915 for ; Wed, 13 Jun 2001 15:33:46 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 17:33:46 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D8D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby'" , "'seamoby-context'" Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Date: Wed, 13 Jun 2001 17:33:45 -0500 Sensitivity: Company-Confidential 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, See below. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, June 13, 2001 2:46 PM To: 'Nakhjiri Madjid-MNAKHJI1' Cc: 'seamoby'; 'seamoby-context' Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt Sensitivity: Confidential Madjid: > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, June 13, 2001 2:31 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby' > Cc: 'seamoby-context'; 'Allison Mankin' > Subject: RE: [seamoby] > draft-ietf-seamoby-context-transfer-problem-02.txt > Sensitivity: Confidential > > > Gary, > > Thanks for the new revision. > > I had two questions: > > 1- Does this mean we are ending DoS analysis? Nothing ever ends. What would you rather do, get a problem statement completed for approval by the IESG, or debate DOS? MN>> Well, Do we know whether IESG is happy? If yes, then who am I to to debate this? But we don't know that, do we? > > 2-Why are we concerned about Theft of service in a CT draft? TOS is the primary reason for authentication. I don't know if there is a problem here, and I don't want to analyze it for the ps. It's only provided as an example. MN>> We talked about mutual authentication between CT-peers (ARs), which is a pre-authentication for any upcoming CTs and mobiles. That does not solve Theft of service problems, besides that is not CT's problem either. Madjid Gary > > Thanks, > Madjid > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Tuesday, June 12, 2001 9:40 AM > To: 'seamoby' > Cc: 'seamoby-context'; 'Allison Mankin' > Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt > Importance: High > Sensitivity: Confidential > > > Below is a revision of the second version of the problem > statement draft. > I have tried to accommodate Allisons' wishes, as well as > John's concern over > explicitly referring to DOS (I hope what I have provided is sufficient > John). > > Bash away. > > Gary > > ============================================================== > ============== > > > Context and Micro-mobility Routing Working Group > O. H. Levkowetz > Internet Draft > ABNW > draft-ietf-seamoby-context-transfer-problem- > P. R. Calhoun > 02.txt Sun > MicroSystems, Inc > Expires: December 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 > > June 2001 > > > Problem Description: Reasons For Performing Context > Transfers > Between Nodes in an IP Access Network > > 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. > > Copyright Notice > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > Levkowetz et al. > [Page 1] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > Abstract > > 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. > > > Table of Contents > > 1 > Introduction...................................................2 > 2 Reference > Definitions..........................................3 > 3 The Need for Context > Transfer..................................4 > 3.1 Scope of the Context Transfer Solution > .....................5 > 3.2 Reference Architectures > ....................................6 > 4 A Description of > Context.......................................6 > 4.1 Feature > ....................................................6 > 4.2 Feature Context > ............................................7 > 4.3 Microflow Context > ..........................................7 > 4.4 Common Context > .............................................7 > 4.5 Examples of Feature Context > ................................8 > 5 Context Transfer and > Mobility..................................8 > 6 Forwarding Node > Capabilities...................................8 > 7 Inter-technology Context > Transfers.............................8 > 8 > Applicability..................................................9 > 9 Performance > Considerations.....................................9 > 10 Security > Considerations.......................................9 > 11 > Recommendations..............................................10 > > > 1 Introduction > > There are a large number of IP access networks that > support hosts > that are mobile. 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 a host may > change frequently and rapidly. > > In networks where the hosts are mobile, the > forwarding path through > the access network must often be redirected in order > to deliver the > host's IP traffic to the new point of access. The > success of a time > sensitive service such as VoIP telephony, video, > etc., in a mobile > environment depends heavily upon the minimization of > the impact of > this traffic redirection. In the process of > establishing the new > forwarding path, the nodes along the new path must be > prepared to > provide similar forwarding treatment to the IP packets. > > Levkowetz et al. > [Page 2] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > The information required in support of a specific forwarding > treatment provided to IP traffic is part of the > context for that > traffic. This context is comprised of configuration and state > information. To minimize the impact of a path change > on an IP flow, > the context used at the forwarding nodes along the > original path, > must be replicated at the forwarding nodes along the > new path. > > The transfer of context information may be advantageous in > minimizing the impact of host mobility on, for > example, AAA, header > compression, QoS, Policy, and possibly sub-IP > protocols and services > > such as PPP. Context transfer at a minimum will be > used to replicate > > the configuration information needed to establish the > respective > protocols and services. In addition, it may also provide the > capability to replicate state information, allowing stateful > protocols and services at the new node to be > activated along the new > > path with less delay and less signalling overhead. > > > 2 Reference Definitions > > Mobile Node > > An IP node capable of changing its point of attachment to the > network. The mobile node is usually an end user host, > but may be a > forwarding node for a network that is itself mobile. > > Forwarding Node > > A node that supports IP forwarding within the access > network. This > includes all routers, gateways, servers and other > nodes within the > network that have IP protocol stacks and forward IP > traffic to and > from a mobile node. > > A forwarding node will be connected to one or more > other forwarding > nodes. Some forwarding nodes will be connected to > zero or more > mobile nodes. The forwarding nodes that connect to > mobile nodes will > > do so through a layer two entity that supports wireless > communications. > > Microflow > > One useful definition for the fundamental unit of IP > service is the > microflow. RFC 2475 [1] defines a microflow as: > > A single instance of an application-to application > flow of packets > destined to or originated from a mobile device (MN or > MH), which is > identified by source address, source port, > destination address, > destination port and protocol id. > > > Levkowetz et al. > [Page 3] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > RFC 2207 [2] provides a definition of a microflow > that applies to > IPSec packets. It is based on the IPSec SPI found in > the AH or ESP > headers. Other methods for identifying for IP > microflows may be > defined in the future, e.g. the Ipv6 flow label. > > > 3 The Need for Context Transfer > > In networks where the hosts are mobile, the > forwarding path through > the access network must often be redirected in order > to deliver the > host's IP traffic to the new point of access. The > success of a time > sensitive service such as VoIP telephony, video, > etc., in a mobile > environment depends heavily upon the minimization of > the impact of > this traffic redirection. In the process of > establishing the new > forwarding path, the nodes along the new path must be > prepared to > provide similar forwarding treatment to the IP packets. > > Figure 1 and 2 below illustrate an example of a > handover scenario. A > > mobile node, MN7, is shown attached to the Internet > via an access > network. The forwarding nodes, FN1 through to FN7 > comprise a portion > > of this access network. FN1 and FN7 are the last > forwarding nodes > before the untethered link to MN7. This last link > allows the nodes > to move while maintaining connectivity to the edge of > the access > network - e.g. the last link is wireless. For > simplicity, many > details of a real access network topology have been > left out of the > diagrams. > > Prior to handoff, the path for MN7's traffic > traverses FN1 and FN2. > It is presumable that FN1 and FN2 have been > configured to provide > specific forwarding services for MN7's traffic, and > that some of > these services may require state information to be > maintained. > > > > MN7's traffic > > <------------------> > > ------- ------- > > [ MN7 ]<= = = =>| FN1 |=================| FN2 > |======== > ------- /------- > > / > > -------/ > > | FN4 | > > /-------\ > > / \ > > / \ > > -------/ > \------- > - - -| FN7 | | FN6 > |---- > ------- > ------- > > > Figure 1: Path Prior to Handover > > > > > > Levkowetz et al. > [Page 4] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > When MN7's movement results in the link to FN1 to be > replaced by a > link to FN7, MN7's traffic must be re-directed along a new > forwarding path, illustrated in Figure 2 as the path > through FN7, > FN4 and FN2. In many mobile networks, this handover can occur > frequently, and sometimes with little or no warning. > ------- ------- > > - - -| FN1 |----------------| FN2 > |======== > ------- //------- > > // MN7's > traffic > -------/ > <-----------> > | FN4 | > > //------\ > > MN7's traffic // \ > > <-----------> // \ > > -------/ > \------- > [ MN7 ]<= = = =>| FN7 | | FN6 > |---- > ------- > ------- > > > Figure 2: Path Re-Directed After Handover > > > > > If the forwarding treatment provided to MN7's traffic > is to be > sustained, the support conditions at FN1 and FN2 must > be reproduced > at FN7 and FN4. At the very least, this requires that > FN7 and FN4 be > > configured to provide the appropriate support to the > traffic flow. > However, establishing forwarding support along the > new path through > the use of IP signalling protocols would be relatively time > consuming. In addition, given that some forwarding > services may > maintain state information, simply configuring FN7 > and FN4 would not > > circumvent disruption of the services. > > Given that FN7 and FN4 support the same functionality > as FN1, it > should be possible to reproduce the needed support > along the new > forwarding path by capturing the salient information > at FN1 as it > exists just prior to the handover, and then use that > information to > replicate the state of FN1 at FN7 and FN4. > > > 3.1 Scope of the Context Transfer Solution > > The information required to produce the necessary forwarding > treatments at a node is referred to as the support > "context". In > order to replicate the context of one forwarding node > at another > forwarding node, an open, standard solution for > context transfer > must be developed. > > > Levkowetz et al. > [Page 5] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > In addition, for a forwarding node to be able to > interpret the > transferred context, both the syntax and the semantics of the > context information must be defined. Definition of the actual > context information will be specific to the support > feature being > replicated, however, a generic container format of > the payload of > context transfer messages is required for inter-operability. > > > 3.2 Reference Architectures > > The concept of the "forwarding node" is used here to > describe the > general context transfer problem. In different > networks, the actual > context transfer may take place between different > entities within > the network. In some cases the preferred context > transfer peers > might be the routers at the edge of the access > network. In other > situations, it may be more appropriate to transfer > context between > wireless access points that also support forwarding > of IP packets. > > The context transfer solution will be applicable to > any nodes that > support forwarding of a mobile nodes IP traffic. > > > 4 A Description of Context > > The term ` > `context' > ' pertains to all information required by a > forwarding node specific to supporting the IP traffic for a > particular mobile node. > > The context for a mobile node can be partitioned into three > categories: > > - information required to provide generally > support to the > mobile node; > > - information required to provide common > support to the > mobile node's traffic; > > - information required to support specific > features of the > forwarding treatment for an IP microflow. > > > 4.1 Feature > > A feature is an aspect of the IP forwarding treatment that is > instantiated for each mobile node, and which may > support one or more > > of the mobile nodes microflows. A feature must > include associated > configuration information: at the very least, some > identification > information for the mobile node, such as the mobile node's IP > address. A feature may have associated state information. > > > Levkowetz et al. > [Page 6] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > In other words, for the purpose of supporting > mobility the features > of interest all have context pertinent to the forwarding of a > specific mobile nodes IP packets. Examples of > features include: > header compression, security, subscriber policy, and > quality of > service. > > Each feature is, in general, supported by an > amalgamation of one or > more protocols and associated local support mechanisms. As an > example, header compression is a feature that > consists of various > "mechanisms" such as IP/TCP header compression and > IPv6/UDP/RTP > header compression, operating according to > well-defined "protocols". > > Thus, an instance of a feature reflects the state > associated with > protocols and the corresponding mechanisms. > > > 4.2 Feature Context > > Feature context is the condition or state of an instance of a > particular feature. It represents the current > evolution of the > behaviour of that feature instance. At a given > instant in time, > feature context is represented by the values of the > associated data > elements. > > Some of the data elements associated with a feature are time > invariant and, thus, represent the configuration of > the feature > instance. Other data elements, which are often > referred to as the > "state variables" for the feature instance, change > value over time > as a consequence of the various operations performed > in support of > the feature instance. > > A feature context is believed to be the smallest > indivisible unit of > > context that can be transferred between forwarding nodes. > > > 4.3 Microflow Context > > A microflow context is the collection of the various feature > contexts associated with a single IP microflow. It is > the smallest > unit of context that must be transferred in order to > re-establish > support for the microflow at a forwarding node. > > > 4.4 Common Context > > Some of the associated feature contexts may be > applicable to more > then one of the IP microflows comprising the mobile > node's traffic. > An example of this might be the authentication state > for the mobile. > > This type of feature context is also required to support each > microflow, but because of the multiplicity of the > relationship to > the mobile node's microflows, it would seem prudent > to transfer one > instance of the context, independent of the microflow > context. > > Levkowetz et al. > [Page 7] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > > 4.5 Examples of Feature Context > > Some examples of feature contexts that are candidates > for context > transfer are given below. This list is provided > solely to illustrate > > the nature of the context transfer problem domain. > > - encryption context; > - authentication context; > - authorization context; > - accounting context; > - header compression context; > - quality of service context; > - policy enforcement context; > - multicast group membership; > - buffer state; > - sub-network layer context (e.g. PPP context). > > > 5 Context Transfer and Mobility > > Context transfer is an enhancement to a mobility > solution that is > clearly most effective when used on a local scale > between forwarding > > nodes within a subnetwork. However, with due > consideration to the > nature of the context and the requirements for > transfer of that > context, context transfer should be applicable > between any two > similar forwarding nodes. > > > 6 Forwarding Node Capabilities > > Context transfer between two forwarding nodes is > worthwhile only if > the receiving node's capabilities are similar enough > to those of the > > sending node that the received context can be > utilized. This does > not mean that the two nodes are identical in their > implementation, > nor does it even imply that they must have identical > capabilities. > > A forwarding node that cannot make use of received > context could, > and should, refuse the transfer. This would result in > a situation no > > different then mobile handover without context transfer. > > > 7 Inter-technology Context Transfers > > The context transfer described here operates at the > IP layer, and > should be applicable to situations where the > forwarding nodes are > supporting different wireless link technologies. > > > Levkowetz et al. > [Page 8] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > An exception to this would be where sub-IP layer > context is an > intrinsic part of the forwarding treatment. In this > situation, an > interworking solution must be developed for sub-IP > context transfer > between the two technologies. This issue is outside > the scope of the > > Seamoby working group. > > > 8 Applicability > > The primary motivation for developing an IP context > transfer assumes > > that service sustainment during handover is > desirable. And yet, > there may be situations where either the user or the > access network > would prefer to re-establish or re-negotiate a > service or a service > feature. For example, if the mobile node crosses > administration > domains where the operational policies change, > negotiation of a > different level of service may be required by the respective > operators. > > More important, the concept of context transfer also > assumes that > the service is worth sustaining through a variety of handover > scenarios, and that context transfer is the best > approach. The > former may not be true for certain types of service - > for example, > multicast, "push" information services. In addition, > even if service > > level sustainment is desirable, context transfer may > not be the most > > cost efficient solution. > > Alternatives to context transfer for sustaining > services during > handover are out of scope for the Seamoby working group. The > possibility of other solutions is only noted here to > emphasize that > context transfer is but one of possibly many approaches. > > Finally, context transfer is an enhancement at the IP > level to > improve upon the performance of a handover between IP > forwarding > nodes. Many networks provide support for handover at > the link layer, > > within and between subnetworks, and context transfer > may not provide > > a significant improvement over the these link layer > solutions. > > > 9 Performance Considerations > > The purpose of context transfer is to sustain the > services being > provided to a mobile node's traffic during handover. It is > essentially an enhancement to a mobility solution > that ultimately > must result in an improvement in handover > performance. The various > aspects of performance must be a prime consideration in the > development of the context transfer solution. > > > 10 Security Considerations > > Some of the considerations for context transfer > security include: > > Levkowetz et al. > [Page 9] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > - information privacy: the context may > contain information > which the end user would prefer to keep hidden from > unauthorized viewers. > > - transfer legitimacy: a false or purposely corrupted > context transfer could have a severe impact > upon the > operation of the receiving forwarding node, > and therefore > could potentially affect the operation of > the access > network itself; the potential threats > include denial of > service and theft of service attacks; > context transfer > must only occur between forwarding nodes > that have an > established trust relationship. > > - security preservation: part of the context > transfer may > include information pertinent to a security > association > established between the mobile node and > another entity on > > the network; for this security association > to be preserved > > during handover, the transfer of the > security context > must include the appropriate security measures. > > It is expected that the measures used to secure the > transport of > information between peers in an IP network should be > sufficient for > context transfer. However, given the above > considerations, there > may be reason to provide for additional security > measures beyond the > > available IETF solutions. > > The context transfer investigation must identify any > novel security > > measures required for context transfer that exceed > the capabilities > > of the existing or emerging IETF solutions. > > > 11 Recommendations > > The Seamoby context transfer design team recommends > the following: > > - investigation into candidates for context > transfer - in > particular, feature context transfer, and > an analysis > of the transfer requirements for each candidate; > > - the development of a framework and > protocol(s) that will > support the transfer of configuration and > state context > between the forwarding nodes of an IP network. > > The context transfer solution must interwork with > existing and > emerging IP protocols, in particular, those protocols > supporting > mobility in an IP network. > > > References > > > Levkowetz et al. > [Page 10] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > [1] Blake, et al., "An Architecture for > Differentiated Services", > RFC 2475, December 1998. > > [2] Berger & O'Malley, "RSVP Extensions for IPSEC > Data Flows", > RFC 2207, September 1997. > > Authors' Addresses > O. Henrik Levkowetz > A Brand New World > Osterogatan 1 > S-164 28 Kista > SWEDEN > > Phone: +46 8 477 9942 > EMail: henrik@levkowetz.com > > > Pat R. Calhoun > Network and Security Research Center, Sun Labs > 15 Network Circle > Menlo Park CA 94025 > USA > > Phone: +1 650-786-7733 > EMail: pcalhoun@eng.sun.com > > > Gary Kenward > Nortel Networks > 3500 Carling Avenue > Nepean, Ontario K2G 6J8 > CANADA > > Phone: +1 613-765-1437 > EMail: gkenward@nortelnetworks.com > > > Hamid Syed > Nortel Networks > 100 Constellation Crescent > Nepean Ontario K2G 6J8 > CANADA > > Phone: +1 613 763-6553 > EMail: hmsyed@nortelnetworks.com > > Jukka Manner > Department of Computer Science, University of Helsinki > P.O. Box 26 (Teollisuuskatu 23) > FIN-00014 Helsinki > FINLAND > > Levkowetz et al. > [Page 11] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > > Phone: +358-9-191-44210 > EMail: jmanner@cs.helsinki.fi > > > Madjid Nakhjiri > Motorola > 1501 West Shure Drive > Arlington Heights IL 60004 > USA > > Phone: +1 847-632-5030 > EMail: madjid.nakhjiri@motorola.com > > > Govind Krishnamurthi > Communications Systems Laboratory, Nokia Research Center > 5 Wayside Road > Burlington MA 01803 > USA > > Phone: +1 781 993 3627 > EMail: govind.krishnamurthi@nokia.com > > > Rajeev Koodli > Communications Systems Lab, Nokia Research Center > 313 Fairchild Drive > Mountain View CA 94043 > USA > > Phone: +1 650 625 2359 > EMail: rajeev.koodli@nokia.com > > > Kulwinder S. Atwal > Zucotto Wireless Inc. > Ottawa Ontario K1P 6E2 > CANADA > > Phone: +1 613 789 0090 > EMail: kulwinder.atwal@zucotto.com > > > Michael Thomas > Cisco Systems > 375 E Tasman Rd > San Jose CA 95134 > USA > > Phone: +1 408 525 5386 > > Levkowetz et al. > [Page 12] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > EMail: mat@cisco.com > > > Mat Horan > COM DEV Wireless Group > San Luis Obispo CA 93401 > USA > > Phone: +1 805 544 1089 > EMail: mat.horan@comdev.cc > > > Phillip Neumiller > 3Com Corporation > 1800 W. Central Road > Mount Prospect IL 60056 > USA > > EMail: phil_neumiller@3com.com > > > Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > This document and translations of it may be copied > and furnished to > others, and derivative works that comment on or > otherwise explain it > > or assist in its implementation may be prepared, > copied, published > and distributed, in whole or in part, without > restriction of any > kind, provided that the above copyright notice and > this paragraph > are included on all such copies and derivative works. > However, this > document itself may not be modified in any way, such > as by removing > the copyright notice or references to the Internet > Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the > procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into > languages other than > English. > > The limited permissions granted above are perpetual > and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is > provided on an > > "AS IS" basis and THE INTERNET SOCIETY AND THE > INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgement > > > Levkowetz et al. > [Page 13] > > > Internet Draft > June 2001 > > draft-ietf-seamoby-context-transfer-problem-02.txt > > Funding for the RFC editor function is currently > provided by the > Internet Society. > > Levkowetz et al. > [Page 14] > > From owner-seamoby@diameter.org Thu Jun 14 07:11: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 HAA24952 for ; Thu, 14 Jun 2001 07:11:36 -0400 (EDT) Received: (qmail 10225 invoked by alias); 14 Jun 2001 10:59:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10219 invoked by uid 200); 14 Jun 2001 10:59:49 -0000 Received: (qmail 10214 invoked from network); 14 Jun 2001 10:59:47 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 10:59:47 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24895; Thu, 14 Jun 2001 07:09:46 -0400 (EDT) Message-Id: <200106141109.HAA24895@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@cdma-2000.org, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-shahrier-mobileip-mmp-00.txt Date: Thu, 14 Jun 2001 07:09:46 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Low-Overhead Mobility Management Protocol in IP Layer Author(s) : S. Shahrier Filename : draft-shahrier-mobileip-mmp-00.txt Pages : 7 Date : 13-Jun-01 The Future Mobile Internet has to support many types of traffic flows, including both real-time and non real-time services. In addition, the network has to keep account of the location of each mobile node (MN) as it moves around the network. This draft proposes a novel protocol that combines mobility management with optimal routing for use over the mobile air interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shahrier-mobileip-mmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shahrier-mobileip-mmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shahrier-mobileip-mmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613133741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shahrier-mobileip-mmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shahrier-mobileip-mmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613133741.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Jun 14 14:08: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 OAA05954 for ; Thu, 14 Jun 2001 14:08:24 -0400 (EDT) Received: (qmail 15783 invoked by alias); 14 Jun 2001 17:56:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15777 invoked by uid 200); 14 Jun 2001 17:56:27 -0000 Received: (qmail 15772 invoked from network); 14 Jun 2001 17:56:24 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 17:56:24 -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 LAA27864 for ; Thu, 14 Jun 2001 11:06:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5EI6WJ20032 for ; Thu, 14 Jun 2001 11:06:32 -0700 X-mProtect: Thu, 14 Jun 2001 11:06:32 -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 smtpd6OQzow; Thu, 14 Jun 2001 11:06:30 PDT Message-ID: <3B28FD26.9CB1581@iprg.nokia.com> Date: Thu, 14 Jun 2001 11:06:30 -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: Seamless Mobility Working Group Subject: [seamoby] More about authorization vs. authentication Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, Sorry to have missed out on the last few days of discussion. It seems to me that it is crucial to get some definitions right, because they are important for the requirements for context transfer. I've studied a number of sources to get useful information, and have been very fortunate to get clarifications and suggestions from e-mail that have helped me understand the issues better. Thanks to Henry Haverinen for sending the following definitions (which he cited from http://www.pcwebopaedia.com/) =============================================================== Authentication: The process of identifying an individual, usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authorization: The process of granting or denying access to a network resource. Most computer security systems are based on a two-step process. The first stage is authentication, which ensures that a user is who he or she claims to be. The second stage is authorization, which allows the user access to various resources based on the user's identity. ================================================================ However, there are other competing definitions for these terms, often not quite compatible with each other. I really think that we have to get some terminology by which specific proposals can be judged against the security requirements for context transfer. It seems debatable (at least) whether the security requirements are met by existing IPsec protocols. Maybe for protocol design the general procedure can be described as follows: 1. A node asks for access to some resource, and presents its credentials. 2. The request is received, and the credentials verified. 3. If the verification succeeds, information about access to the resource is delivered to the requesting node. This enumeration doesn't explicitly mention authentication or authorization, and yet to me it seems clear and unambiguous. Thus, I would suggest that we could use the term "credential verification" to replace authentication. From what I have read, most people would understand the meaning of that term better. Then, the process of "authorization" could either be taken to mean some sort of internal database access, or else the delivery of the access information in (3). Or maybe there wouldn't be any need to use that terminology at all. As an aside, I looked in on some related discussion from the AAA working group, and found some statement that authorization can be provided without authentication. Here are definitions from RFC 2989: Authentication The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication). Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. These definitions support the type of distinctions I had tried to make in previous e-mails, and that I have understood to describe the relevant care-of address operations for Mobile IPv6. They also have the advantage of being somewhat compatible with the definitions from www.pcwebopaedia.com. They could be taken as a start for the appropriate definitions within [seamoby], if the terms are to be used at all. Bottom line: one's perspective on this issue seems to depend on whether "authentication" is taken to mean "identity authentication", and maybe we could get away without using the terms anyway if we focus on credential verification. Regards, Charlie P. From owner-seamoby@diameter.org Thu Jun 14 14:21: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 OAA06428 for ; Thu, 14 Jun 2001 14:20:56 -0400 (EDT) Received: (qmail 16322 invoked by alias); 14 Jun 2001 18:03:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16316 invoked by uid 200); 14 Jun 2001 18:03:31 -0000 Received: (qmail 16301 invoked from network); 14 Jun 2001 18:03:06 -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; 14 Jun 2001 18:03:06 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5EICqE10989 for ; Thu, 14 Jun 2001 14:12:52 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 14 Jun 2001 14:12:42 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 14:12:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D15@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , Seamless Mobility Working Group Subject: RE: [seamoby] More about authorization vs. authentication Date: Thu, 14 Jun 2001 14:12:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F4FD.962AE270" 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_01C0F4FD.962AE270 Content-Type: text/plain; charset="iso-8859-1" For what it's worth, Charlie, I like the wording. As good as it will get I suspect. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Thursday, June 14, 2001 2:07 PM > To: Seamless Mobility Working Group > Subject: [seamoby] More about authorization vs. authentication > > > > Hello folks, > > Sorry to have missed out on the last few days of discussion. > It seems to me that it is crucial to get some definitions right, > because they are important for the requirements for context > transfer. I've studied a number of sources to get useful > information, and have been very fortunate to get clarifications > and suggestions from e-mail that have helped me understand the > issues better. > > Thanks to Henry Haverinen for sending the following > definitions (which he cited from http://www.pcwebopaedia.com/) > > =============================================================== > > Authentication: > The process of identifying an individual, usually based on a > username and password. In security systems, authentication is > distinct from authorization, which is the process of giving > individuals access to system objects based on their identity. > Authentication merely ensures that the individual is who he > or she claims to be, but says nothing about the access rights > of the individual. > > Authorization: > The process of granting or denying access to a network resource. > Most computer security systems are based on a two-step process. > The first stage is authentication, which ensures that a user is > who he or she claims to be. The second stage is authorization, > which allows the user access to various resources based on the > user's identity. > > ================================================================ > > However, there are other competing definitions for these > terms, often not quite compatible with each other. > > I really think that we have to get some terminology by which > specific proposals can be judged against the security requirements > for context transfer. It seems debatable (at least) whether > the security requirements are met by existing IPsec protocols. > > Maybe for protocol design the general procedure can be > described as follows: > > 1. A node asks for access to some resource, and presents > its credentials. > > 2. The request is received, and the credentials verified. > > 3. If the verification succeeds, information about access to > the resource is delivered to the requesting node. > > This enumeration doesn't explicitly mention authentication or > authorization, and yet to me it seems clear and unambiguous. > Thus, I would suggest that we could use the term "credential > verification" to replace authentication. From what I have > read, most people would understand the meaning of that term > better. Then, the process of "authorization" could either be > taken to mean some sort of internal database access, or else > the delivery of the access information in (3). Or maybe > there wouldn't be any need to use that terminology at all. > > As an aside, I looked in on some related discussion from > the AAA working group, and found some statement that > authorization can be provided without authentication. > > Here are definitions from RFC 2989: > > Authentication > The act of verifying a claimed identity, in the form of a > pre-existing label from a mutually known name > space, as the > originator of a message (message authentication) > or as the > end-point of a channel (entity authentication). > > Authorization > The act of determining if a particular right, such as > access to some resource, can be granted to the > presenter of > a particular credential. > > These definitions support the type of distinctions I had tried to > make in previous e-mails, and that I have understood to describe > the relevant care-of address operations for Mobile IPv6. They > also have the advantage of being somewhat compatible with the > definitions from www.pcwebopaedia.com. They could be taken as > a start for the appropriate definitions within [seamoby], if the > terms are to be used at all. > > Bottom line: one's perspective on this issue seems to depend on > whether "authentication" is taken to mean "identity authentication", > and maybe we could get away without using the terms anyway if we > focus on credential verification. > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F4FD.962AE270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] More about authorization vs. = authentication

For what it's worth, Charlie, I like the = wording.
As good as it will get I suspect.

Gary



> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Thursday, June 14, 2001 2:07 PM
> To: Seamless Mobility Working Group
> Subject: [seamoby] More about authorization vs. = authentication
>
>
>
> Hello folks,
>
> Sorry to have missed out on the last few days = of discussion.
> It seems to me that it is crucial to get some = definitions right,
> because they are important for the requirements = for context
> transfer.  I've studied a number of = sources to get useful
> information, and have been very fortunate to = get clarifications
> and suggestions from e-mail that have helped me = understand the
> issues better.
>
> Thanks to Henry Haverinen for sending the = following
> definitions (which he cited from http://www.pcwebopaedia.com/)
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Authentication:
> The process of identifying an individual, = usually based on a
> username and password. In security systems, = authentication is
> distinct from authorization, which is the = process of giving
> individuals access to system objects based on = their identity.
> Authentication merely ensures that the = individual is who he
> or she claims to be, but says nothing about the = access rights
> of the individual.
>
> Authorization:
> The process of granting or denying access to a = network resource.
> Most computer security systems are based on a = two-step process.
> The first stage is authentication, which = ensures that a user is
> who he or she claims to be. The second stage is = authorization,
> which allows the user access to various = resources based on the
> user's identity.
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> However, there are other competing definitions = for these
> terms, often not quite compatible with each = other.
>
> I really think that we have to get some = terminology by which
> specific proposals can be judged against the = security requirements
> for context transfer.  It seems debatable = (at least) whether
> the security requirements are met by existing = IPsec protocols.
>
> Maybe for protocol design the general procedure = can be
> described as follows:
>
> 1. A node asks for access to some resource, and = presents
>    its credentials.
>
> 2. The request is received, and the credentials = verified.
>
> 3. If the verification succeeds, information = about access to
>    the resource is delivered to = the requesting node.
>
> This enumeration doesn't explicitly mention = authentication or
> authorization, and yet to me it seems clear and = unambiguous.
> Thus, I would suggest that we could use the = term "credential
> verification" to replace = authentication.  From what I have
> read, most people would understand the meaning = of that term
> better.  Then, the process of = "authorization" could either be
> taken to mean some sort of internal database = access, or else
> the delivery of the access information in = (3).  Or maybe
> there wouldn't be any need to use that = terminology at all.
>
> As an aside, I looked in on some related = discussion from
> the AAA working group, and found some statement = that
> authorization can be provided without = authentication.
>
> Here are definitions from RFC 2989:
>
>    Authentication
>          = ;    The act of verifying a claimed identity, in the = form of a
>          = ;    pre-existing label from a mutually known name =
> space, as the
>          = ;    originator of a message (message authentication) =
> or as the
>          = ;    end-point of a channel (entity = authentication).
>
>    Authorization
>          = ;    The act of determining if a particular right, such = as
>          = ;    access to some resource, can be granted to the =
> presenter of
>          = ;    a particular credential.
>
> These definitions support the type of = distinctions I had tried to
> make in previous e-mails, and that I have = understood to describe
> the relevant care-of address operations for = Mobile IPv6.  They
> also have the advantage of being somewhat = compatible with the
> definitions from www.pcwebopaedia.com.  = They could be taken as
> a start for the appropriate definitions within = [seamoby], if the
> terms are to be used at all.
>
> Bottom line: one's perspective on this issue = seems to depend on
> whether "authentication" is taken to = mean "identity authentication",
> and maybe we could get away without using the = terms anyway if we
> focus on credential verification.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F4FD.962AE270-- From owner-seamoby@diameter.org Thu Jun 14 17:09: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 RAA09827 for ; Thu, 14 Jun 2001 17:09:23 -0400 (EDT) Received: (qmail 17663 invoked by alias); 14 Jun 2001 20:58:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17657 invoked by uid 200); 14 Jun 2001 20:58:04 -0000 Received: (qmail 17649 invoked from network); 14 Jun 2001 20:58:03 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 20:58:03 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA02354; Thu, 14 Jun 2001 14:08:40 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA11525; Thu, 14 Jun 2001 14:08:40 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 16:08:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D91@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Phillip Neumiller Cc: Nakhjiri Madjid-MNAKHJI1 , Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 16:08:39 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, June 13, 2001 8:29 AM To: Phillip Neumiller Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > There are companies that build products (WRQ's reflection comes > to mind) that freeze the state of the IP stack (gracefully in > the application sense), until the flow of IP traffic can resume. > This is sort of an ultra-slow handover. I see no reason why THIS > can not be made seamless with CT. Why should CT not be capable > of accomodating this Pat? Sure, they could, but what is seamless in this sense? The user has no service for some time, so what is an extra couple of seconds while signalling occurs over the air to update the local ARs state?? The user would probably not even notice. Actually, you seem to imply something that I am not sure that I've been thinking about that much, which is the mobile updating the AR's state. This, btw, can be problematic, since the mobile doesn't necessarily share an SA with the AR (hence DoS attacks), and a malicious mobile could send bogus (mal-formed) CT packets in an attempt to crash (or cause mis-behaving) ARs. Something to think about in the DoS space. MN>> Yes, involving the MN is CT is definitely a whole other ball of wax. As I said earlier the assumption was that the CT happens AR to AR and I was exploring the DoSs for that case. The MN is not authenticated to the newAR, so all kinds of security problems exists until the MN is "properly introduced" to the newAR. Madjid PatC From owner-seamoby@diameter.org Thu Jun 14 17:17: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 RAA09910 for ; Thu, 14 Jun 2001 17:17:15 -0400 (EDT) Received: (qmail 18139 invoked by alias); 14 Jun 2001 21:05:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18133 invoked by uid 200); 14 Jun 2001 21:05:04 -0000 Received: (qmail 18128 invoked from network); 14 Jun 2001 21:05:02 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 21:05:02 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA21958 for ; Thu, 14 Jun 2001 14:09:02 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA11635 for ; Thu, 14 Jun 2001 14:15:39 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 16:15:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D92@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: Comments Re: [seamoby] ct problem statement Date: Thu, 14 Jun 2001 16:15:38 -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 Ok, Thinking a bit further about this problem, I can see that I should not have posed the problem as an authentication or authorization problem (since the credentials are the same anyway). I should not have posed the problem as an AR goes crazy problem either, since there is no measure against the corrupt police force (you are right). However, this is the problem: By doing a pre-authentication between the ARs that are CT-peers, you are doing a CT source authentication once and only once for all the upcoming CTs. This does not prevent a third node/ AR to come and pretend it is one the CT peers and send context (in a DoS), we did not talk about message authentications or signatures (sort of like what MIP does with its binding updates). Note that I am not proposing the use of AH for CT, we all know where that might lead to from MIPv6 experience. But This case sounds like a man in middle attack or DoS attack, does it not? Finally, as I said again, I don't think IETF cares about theft of service, that is operator's headache. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, June 13, 2001 9:16 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: Comments Re: [seamoby] ct problem statement Well, Madjid. I agree with what you say, but would add two points: 1. I think Pat said it, but if the intradomain ARs cannot be trusted then it's game over; no amount of rules and procedures will save you if your police force is corrupt ;^}. I believe this also holds true for interdomain ARs, once the trust relationship is established between the operators. Note that I am referring to explicit DOS attacks here. Faulty ARs are a different problem, and I don't believe that you provide fault tolerance through security procedures. 2. When you get down to it, the *only* security problem the wireless operators have ever really been concerned with is theft of service. Back in the early 90s, AT&T claimed they lost $1M / day in stolen service. This was because AMP had a very simple security scheme. I am sure that operators are somewhat concerned about eavesdropping, particularly given all the high profile cases that occurred in the '90s. However, I believe that the general consensus is that the channel coding is sufficient with 2G networks. Does anyone have a real industry analysis, from the operators p.o.v? This is somewhat off track. My only observation is that I do not recall any similar conversation on DOS being reported out of 3GPP, 3GPP2, 3GIP, or MWIF. But maybe I missed it. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Tuesday, June 12, 2001 6:17 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri > Madjid-MNAKHJI1; 'Charles > E. Perkins' > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Thanks Gary, > > See below: > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Monday, June 11, 2001 3:06 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' > Cc: 'seamoby' > Subject: RE: Comments Re: [seamoby] ct problem statement > > > Madjid, Charlie, et al: > Madjid, I think you have captured the essence of the real issue. > Authentication > and authorization are different, but for the most part, > authorization has > never really been needed for the internet, mainly for the reasons you > describe. > The real interesting issue (besides how to authorize every > doorknob and > aircraft carrier on the planet), is whether, in a mobile > environment, how > often > one needs to authenticate. > Consider that a mobile node travelling through the network > will, with each > > handover, open up opportunities for an interloper to steal a > service, if > that > service is only authorized and the service user is not authenticated. > > > MN>> I think the point of DoS is missed here. > Note, we are not discussing service theft here (that > is the operators problem). Stealing service by an un-authorized > user is not the issue. The issue is launching a DENIAL of service > attack by a node that can do CT (you can translate it as authorized > to do CT), so we are talking about authorizing oldAR to send CT > or authorizing newAR to request CT. > > It seems that a lot of folks are confusing service theft with > DoS attack. With service theft, you are just not paying for usage. > With DoS attack, you are making the network so busy, it can not > give service to anybody, *DENIAL* of service. > > Madjid > > From owner-seamoby@diameter.org Thu Jun 14 17:37: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 RAA10216 for ; Thu, 14 Jun 2001 17:37:51 -0400 (EDT) Received: (qmail 18632 invoked by alias); 14 Jun 2001 21:26:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18626 invoked by uid 200); 14 Jun 2001 21:26:19 -0000 Received: (qmail 18618 invoked from network); 14 Jun 2001 21:26:17 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 21:26:17 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA24580; Thu, 14 Jun 2001 14:36:50 -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 OAA00900; Thu, 14 Jun 2001 14:36:50 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 16:36:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D94@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 16:36:47 -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 Pat, See below (MN>>>>) -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Tuesday, June 12, 2001 6:32 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Pat Calhoun'; Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement On Tue, Jun 12, 2001 at 05:08:48PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > > of course. My intention was not to kill the whole thread, just the > definition wars that are going on :) > > MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot > of text for readability. > > > > > 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS. > > I would claim that such events are unlikely to happen. When a user wants to > move > from one service area to another, the spectrum will be overlapping. The > operators > of these networks will allow/disallow CT between the routers handling these > service areas. If they permit it, then will ensure that secure communication > is available between them. > > MN>> I am not quite sure I understand your point. I am not sure > how spectrum overlap comes in? Sorry, what I meant was that the service areas are close enough that it makes sense to CT. If there is a long no-service time between both service areas, then CT doesn't really make that much sense, right? MN>>>> I am still not sure how proximity prevents launching DoS attacks by a third party pretending to be a authenticated CT-Peer, if you don't do message authentication. > Anyway, seems like you are asuuming one and the same operator handling > both oldAR and newAR. I didn't mean to assume this. > What if they belong to two different operators. > And then one operator decides to mess with the other one, by having > its ARs that are already authenticated to its neighbor ARs (from the > other operator) do DoS, i.e. Right, so my point is that if CT is to occur between two ARs, they MUST know about each other to begin with, right? If so, then a pre-existing SA exists between the ARs, and security will ensure that no DoS attack can exist. MN>>>> see my comments above. Actually, there is one way to do a DoS attack that has just come to mind, and involves a rogue mobile sending bogus L2 messages faking handoffs, but this doesn't just affect CT, as it would also affect the handoff procedures, and this only exists on wireless links that are not authenticated. MN>>>> Change the rouge MN with somebody pretending to be an AR, then you got a case, haven't you? > OP1 (AR1) does a DoS on OP2(AR2) although AR1-AR2 had a pre-authentication. That is not really an attack that we need to consider. Once you trust one side of a conversation, there isn't a whole lot that you can do to protect yourself against bad behavior (well, a good implementation can protect itself properly). MN>>>> you are right, I realized later that no security measure can protect you here, but an AR3 can come in the middle here, can't it? Madjid From owner-seamoby@diameter.org Thu Jun 14 17:47: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 RAA10326 for ; Thu, 14 Jun 2001 17:47:38 -0400 (EDT) Received: (qmail 19105 invoked by alias); 14 Jun 2001 21:35:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19099 invoked by uid 200); 14 Jun 2001 21:35:37 -0000 Received: (qmail 19091 invoked from network); 14 Jun 2001 21:35:35 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 21:35:35 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 17:45:37 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FEE@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" , Phillip Neumiller Cc: Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 17:45:37 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 14, 2001 5:09 PM > To: 'Pat Calhoun'; Phillip Neumiller > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; Kulwinder > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 13, 2001 8:29 AM > To: Phillip Neumiller > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie > Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: Re: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > > There are companies that build products (WRQ's reflection comes > > to mind) that freeze the state of the IP stack (gracefully in > > the application sense), until the flow of IP traffic can resume. > > This is sort of an ultra-slow handover. I see no reason why THIS > > can not be made seamless with CT. Why should CT not be capable > > of accomodating this Pat? > > Sure, they could, but what is seamless in this sense? The user has > no service for some time, so what is an extra couple of seconds while > signalling occurs over the air to update the local ARs state?? The > user would probably not even notice. > > Actually, you seem to imply something that I am not sure that I've > been thinking about that much, which is the mobile updating the > AR's state. This, btw, can be problematic, since the mobile doesn't > necessarily share an SA with the AR (hence DoS attacks), and a > malicious mobile could send bogus (mal-formed) CT packets in an > attempt to crash (or cause mis-behaving) ARs. > > Something to think about in the DoS space. > > MN>> Yes, involving the MN is CT is definitely a whole other > ball of wax. As I said earlier the assumption was that the CT happens > AR to AR and I was exploring the DoSs for that case. > The MN is not authenticated to the newAR, so all kinds of security > problems exists until the MN is "properly introduced" to the newAR. What do you mean "properly introduced" to the newAR. The MN can certainly authenticate to the newAR. The MN can just show up at the new AR and introduce itself. It called "Reactive" Context Transfer. The preferred case, of course, is when the oldAR transfers trust to the newAR. But, certainly we must consider the case of an MN just showing up at the newAR. The newAR is then faced with finding out where the MN was last attached and invalidating the oldSA. The MN has to present a credential to the newAR that the oldAR will accept as valid. - Kulwinder. > > Madjid > > PatC > From owner-seamoby@diameter.org Thu Jun 14 18:03: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 SAA10516 for ; Thu, 14 Jun 2001 18:02:59 -0400 (EDT) Received: (qmail 19591 invoked by alias); 14 Jun 2001 21:51:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19585 invoked by uid 200); 14 Jun 2001 21:51:04 -0000 Received: (qmail 19577 invoked from network); 14 Jun 2001 21:51:02 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 21:51:02 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA14584; Thu, 14 Jun 2001 15:01:34 -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 PAA24744; Thu, 14 Jun 2001 15:01:33 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 17:01:34 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D97@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Kulwinder Atwal'" , Nakhjiri Madjid-MNAKHJI1 , "'Pat Calhoun'" , Phillip Neumiller Cc: "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 17:01: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: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Thursday, June 14, 2001 4:46 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 14, 2001 5:09 PM > To: 'Pat Calhoun'; Phillip Neumiller > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; Kulwinder > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 13, 2001 8:29 AM > To: Phillip Neumiller > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie > Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: Re: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > > There are companies that build products (WRQ's reflection comes > > to mind) that freeze the state of the IP stack (gracefully in > > the application sense), until the flow of IP traffic can resume. > > This is sort of an ultra-slow handover. I see no reason why THIS > > can not be made seamless with CT. Why should CT not be capable > > of accomodating this Pat? > > Sure, they could, but what is seamless in this sense? The user has > no service for some time, so what is an extra couple of seconds while > signalling occurs over the air to update the local ARs state?? The > user would probably not even notice. > > Actually, you seem to imply something that I am not sure that I've > been thinking about that much, which is the mobile updating the > AR's state. This, btw, can be problematic, since the mobile doesn't > necessarily share an SA with the AR (hence DoS attacks), and a > malicious mobile could send bogus (mal-formed) CT packets in an > attempt to crash (or cause mis-behaving) ARs. > > Something to think about in the DoS space. > > MN>> Yes, involving the MN is CT is definitely a whole other > ball of wax. As I said earlier the assumption was that the CT happens > AR to AR and I was exploring the DoSs for that case. > The MN is not authenticated to the newAR, so all kinds of security > problems exists until the MN is "properly introduced" to the newAR. What do you mean "properly introduced" to the newAR. The MN can certainly authenticate to the newAR. The MN can just show up at the new AR and introduce itself. It called "Reactive" Context Transfer. MN>>> Kulwinder, by "properly introduced", I meant to skip the security details between MN and newAR. Yes, MN can authenticate itself to newAR but not as part of CT, and for sure not before CT completition, especially, if the intention of CT was to transfer MN's for-AAA-Security-needed context. I don't think reactive context transfer was meant to be initiated by MN and definitely not after "MN's introduction itself to newAR". What does this introduction mean in context of "context transfer" anyway. If CT is supposed to happen between ARs, where does this introduction come in? Unless you are talking about an L2 connectivity signal or even an L2 authentication (which is not very fast!!!). The scenario is an AR-AR CT, then an MN-newAR authentication (proper introduction) based on transferred credential after CT is complete. The preferred case, of course, is when the oldAR transfers trust to the newAR. MN>> Of course. That is why I mentioned "properly introduced" But, certainly we must consider the case of an MN just showing up at the newAR. The newAR is then faced with finding out where the MN was last attached and invalidating the oldSA. The MN has to present a credential to the newAR that the oldAR will accept as valid. MN>> Yes, but that is not where CT helps, you are out of the CT-is-an-optimization territory. MN does a lot of negotiations for establishing the context anyway. BTW, I just noticed that my initials and acronym for Mobile Node are the same :( "MN>> means I am talking :) Madjid > > Madjid > > PatC > From owner-seamoby@diameter.org Thu Jun 14 18:32: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 SAA10851 for ; Thu, 14 Jun 2001 18:32:16 -0400 (EDT) Received: (qmail 20095 invoked by alias); 14 Jun 2001 22:20:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20089 invoked by uid 200); 14 Jun 2001 22:20:04 -0000 Received: (qmail 20081 invoked from network); 14 Jun 2001 22:20:02 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 22:20:02 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 18:30:09 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FF0@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , Kulwinder Atwal , "'Pat Calhoun'" , Phillip Neumiller Cc: "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 18:30:09 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 14, 2001 6:02 PM > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > Calhoun'; Phillip > Neumiller > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Thursday, June 14, 2001 4:46 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Thursday, June 14, 2001 5:09 PM > > To: 'Pat Calhoun'; Phillip Neumiller > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > Kulwinder > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > Subject: RE: [seamoby] RE: Authentication & Authorization > > "in-the-large" > > w as Re: [seamob y] ct problem statement > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Wednesday, June 13, 2001 8:29 AM > > To: Phillip Neumiller > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie > > Perkins; Kulwinder Atwal; 'seamoby'; > > wirelessinternet@internet.motlabs.com > > Subject: Re: [seamoby] RE: Authentication & Authorization > > "in-the-large" > > w as Re: [seamob y] ct problem statement > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > > > There are companies that build products (WRQ's reflection comes > > > to mind) that freeze the state of the IP stack (gracefully in > > > the application sense), until the flow of IP traffic can resume. > > > This is sort of an ultra-slow handover. I see no reason why THIS > > > can not be made seamless with CT. Why should CT not be capable > > > of accomodating this Pat? > > > > Sure, they could, but what is seamless in this sense? The user has > > no service for some time, so what is an extra couple of > seconds while > > signalling occurs over the air to update the local ARs state?? The > > user would probably not even notice. > > > > Actually, you seem to imply something that I am not sure that I've > > been thinking about that much, which is the mobile updating the > > AR's state. This, btw, can be problematic, since the mobile doesn't > > necessarily share an SA with the AR (hence DoS attacks), and a > > malicious mobile could send bogus (mal-formed) CT packets in an > > attempt to crash (or cause mis-behaving) ARs. > > > > Something to think about in the DoS space. > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > ball of wax. As I said earlier the assumption was that the > CT happens > > AR to AR and I was exploring the DoSs for that case. > > > > The MN is not authenticated to the newAR, so all kinds of security > > problems exists until the MN is "properly introduced" to the newAR. > > What do you mean "properly introduced" to the newAR. The MN > can certainly > authenticate to the newAR. The MN can just show up at the new AR and > introduce itself. It called "Reactive" Context Transfer. > > MN>>> Kulwinder, by "properly introduced", I meant to skip > the security > details between MN and newAR. Yes, MN can authenticate itself > to newAR but > not as part of CT, and for sure not before CT completition, > especially, if > the intention of CT was to transfer MN's > for-AAA-Security-needed context. > > I don't think reactive context transfer was meant to be > initiated by MN and > definitely not after "MN's introduction itself to newAR". Of course it was intended. Read the Archive. If the MN is switching between wireless and wired, _as_stated_in_our_charter_, there is no other way other than MN initiated CT. What do you expect will happen when an MN loses connectivity between ARs and just shows up at the newAR? Do you _really_ expect the End-User to drive back during Rush Hour to the oldAR and try again? > What does this > introduction mean in context of "context transfer" anyway. If > CT is supposed > to happen between ARs, where does this introduction come in? > Unless you are > talking about an L2 connectivity signal or even an L2 > authentication (which > is not very fast!!!). > The scenario is an AR-AR CT, then an MN-newAR authentication (proper > introduction) > based on transferred credential after CT is complete. How does the newAR even know that the MN has arrived if the MN does not annouce itself? Why should the newAR waste time doing a CT for an MN that is not authorized? Sounds like an opportunity for a DOS attack. Authorize first. Then do CT. Especially for an MN that has arrived unannouced at the newAR due to a service disruption will moving between ARs. - Kulwinder. > > The preferred case, of course, is when the oldAR transfers > trust to the > newAR. > > MN>> Of course. That is why I mentioned "properly introduced" > > But, certainly we must consider the case of an MN just > showing up at the > newAR. The newAR is then faced with finding out where the MN was last > attached and invalidating the oldSA. The MN has to present a > credential to > the newAR that the oldAR will accept as valid. > > MN>> Yes, but that is not where CT helps, you are out of the > CT-is-an-optimization > territory. MN does a lot of negotiations for establishing the context > anyway. > > BTW, I just noticed that my initials and acronym for Mobile > Node are the > same :( > "MN>> means I am talking :) > > Madjid > > > > > > > > > > > > > Madjid > > > > PatC > > > From owner-seamoby@diameter.org Thu Jun 14 18:52: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 SAA10942 for ; Thu, 14 Jun 2001 18:52:44 -0400 (EDT) Received: (qmail 20595 invoked by alias); 14 Jun 2001 22:41:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20589 invoked by uid 200); 14 Jun 2001 22:41:28 -0000 Received: (qmail 20576 invoked by uid 500); 14 Jun 2001 22:41:24 -0000 Date: Thu, 14 Jun 2001 15:41:23 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , Arthur Ross , Charlie Perkins , Kulwinder Atwal , "'seamoby'" , wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Message-ID: <20010614154123.Y17928@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Pat Calhoun' , Arthur Ross , Charlie Perkins , Kulwinder Atwal , 'seamoby' , wirelessinternet@internet.motlabs.com References: <35DBB8B7AC89D4118E98009027B1009B017A9D94@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: <35DBB8B7AC89D4118E98009027B1009B017A9D94@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Thu, Jun 14, 2001 at 04:36:47PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 14, 2001 at 04:36:47PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Sorry, what I meant was that the service areas are close enough that it > makes sense to CT. If there is a long no-service time between both service > areas, then CT doesn't really make that much sense, right? > > MN>>>> I am still not sure how proximity prevents launching DoS attacks > by a third party pretending to be a authenticated CT-Peer, if you don't > do message authentication. proximity has nothing to do with DoS. My argument (if I even remember that far back) was that CT doesn't really make a whole lotta sense if there isn't a fast handoff (TM) that occurs anyways. So, if the device is disconnected for more than a second (or perhaps the number should be larger), then the benefits of CT are questionable. Let the MN signal all over again. PatC From owner-seamoby@diameter.org Thu Jun 14 19:22: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 TAA11150 for ; Thu, 14 Jun 2001 19:22:31 -0400 (EDT) Received: (qmail 21105 invoked by alias); 14 Jun 2001 23:11:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21099 invoked by uid 200); 14 Jun 2001 23:11:08 -0000 Received: (qmail 21090 invoked from network); 14 Jun 2001 23:11:04 -0000 Received: from hume.neobright.net (root@209.143.19.251) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jun 2001 23:11:04 -0000 Received: from WRQ1-NorthCoast.bright.net (wrq1-northcoast.bright.net [209.143.22.124]) by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id TAA20111 for ; Thu, 14 Jun 2001 19:21:32 -0400 Received: from WRQNC7 [10.1.1.172] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for ; Thu, 14 Jun 2001 19:17:46 -0400 From: "Emil Sturniolo" To: "Pat Calhoun" , "Nakhjiri Madjid-MNAKHJI1" Cc: "Arthur Ross" , "Charlie Perkins" , "Kulwinder Atwal" , "'seamoby'" , Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 19:15:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010614154123.Y17928@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-MDaemon-Deliver-To: seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit -----Original Message----- From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]On Behalf Of Pat Calhoun Sent: Thursday, June 14, 2001 6:41 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Pat Calhoun'; Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement On Thu, Jun 14, 2001 at 04:36:47PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Sorry, what I meant was that the service areas are close enough that it > makes sense to CT. If there is a long no-service time between both service > areas, then CT doesn't really make that much sense, right? > > MN>>>> I am still not sure how proximity prevents launching DoS attacks > by a third party pretending to be a authenticated CT-Peer, if you don't > do message authentication. proximity has nothing to do with DoS. My argument (if I even remember that far back) was that CT doesn't really make a whole lotta sense if there isn't a fast handoff (TM) that occurs anyways. So, if the device is disconnected for more than a second (or perhaps the number should be larger), then the benefits of CT are questionable. Let the MN signal all over again. PatC [ES] Pat, I think this really depends on your point of view. If one considers the cost of the link, reducing any additional signaling may save me $$$ in the long run, especially in a pay-per-byte mode. Consider the face that one would have to renegotiate the SA, compression state, etc for every transport layer session that is established. It could represent a significant penalty. Lets not just consider performance alone. Cordially, Emil Sturniolo EmilS@NetMotionWireless.com 330-723-9099 Office 330-461-0326 Mobile/Vmail www.NetMotionWireless.com = = = = = = = = = = = = = = = This message contains information that may be confidential and privileged. Unless you are the addressee or are authorized by the addressee, you may not use, copy or disclose the information contained in this message. If you have received this message in error, please delete it and advise the sender. From owner-seamoby@diameter.org Thu Jun 14 21:00: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 UAA12298 for ; Thu, 14 Jun 2001 20:59:58 -0400 (EDT) Received: (qmail 21743 invoked by alias); 15 Jun 2001 00:48:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21737 invoked by uid 200); 15 Jun 2001 00:48:16 -0000 Received: (qmail 21729 invoked from network); 15 Jun 2001 00:48:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 00:48:14 -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 RAA29769; Thu, 14 Jun 2001 17:58:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5F0wMa32707; Thu, 14 Jun 2001 17:58:22 -0700 X-mProtect: Thu, 14 Jun 2001 17:58:22 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQR0VxR; Thu, 14 Jun 2001 17:58:20 PDT Message-ID: <3B295DCC.A0F831E9@iprg.nokia.com> Date: Thu, 14 Jun 2001 17:58:52 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Arthur Ross , "'seamoby'" Subject: [seamoby] The two-year-ago token References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, If I remember right, the token went under the nickname of "blob" in those days. When I try to apply the token theory to context transfer, I get the following: - Mobile supplies token - New access router validates token == how does it prevent against another node "prematurely" using the token? == how does it prevent replay? == does the same token work for all nearby access routers? - New access router asks old access router for context features - Old access router sends stuff - ... In this scenario, I don't see much advantage because the old access router could more easily check some credentials produced by the mobile node as part of its request to get stuff from the old access router. Or maybe it's all a matter of definition, and a "blob" and a "token" should be treated as variations of some "credential data", and the only point is which access router verifies it. Or we might be worried about how much data has to go over the air. I don't doubt that the token theory can be made to work. It's just a matter of picking the most economical solution. Regards, Charlie P. Pat Calhoun wrote: > On Mon, Jun 11, 2001 at 02:17:55PM -0700, Arthur Ross wrote: > > At 13:06 -0700 06/11/2001, Gary Kenward wrote: > > > > > It would seem that for a mobile solution, the preferred approach > > > would incorporate some sort of "authorization" tokens that would > > > could be passed between ARs as part of the mobile node's context > > > (in a secure fashion of course). There would have to be a tight > > > association maintained between the authentication information and > > > these authorization tokens. If this is the best approach, then once > > > again, it would be difficult to distinguish authentication from > > > authorization. > > > > > > > > Gary et al: > > > > This is very close to what I have long thought might be a good solution > > to this problem, i.e. the notion of a "token" that the MN might carry > > around from AR to AR, presenting it as a sort of "ticket for service". > > The token would be some sort of public-key thingy, which would be > > delivered to the MN upon successful initial authentication and, > > possibly, authorization. It, or some complementary key variable might > > also be pre-distributed by the network to neighbor ARs (for suitable > > definitions of "neighbor") in anticipation of possible movement. > > Successful use upon change of access point would require some sort of > > combination of a "secret" in the MN with the over-the-air token, > > perhaps some sort of challenge-response technique. > > > > ... but we digress into solution space .... > > indeed, and it is interesting that I proposed something very similar > in MIP at least 2 years ago, and it was never adopted as a WG document :( > > PatC From owner-seamoby@diameter.org Thu Jun 14 23:08: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 XAA15252 for ; Thu, 14 Jun 2001 23:08:01 -0400 (EDT) Received: (qmail 22397 invoked by alias); 15 Jun 2001 02:51:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22391 invoked by uid 200); 15 Jun 2001 02:51:43 -0000 Received: (qmail 22385 invoked from network); 15 Jun 2001 02:51:41 -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; 15 Jun 2001 02:51:41 -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 f5F31cE16001 for ; Thu, 14 Jun 2001 23:01:38 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 14 Jun 2001 23:01:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 23:01:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D20@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large" w as Re: [seamob y] ct problem statement Date: Thu, 14 Jun 2001 23:01:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F547.84F51030" 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_01C0F547.84F51030 Content-Type: text/plain; charset="iso-8859-1" Kulwinder: I don't agree with your observation. We did discuss how CT was to be initiated, and agreed that there would be no explicit signalling from the MN (not at least as far as CT was concerned). The definition of reactive CT (read the problem statement)has to do with the order/timing of events, not with where the initiating event comes from. Gary > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Thursday, June 14, 2001 6:30 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > Calhoun'; Phillip > Neumiller > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > Subject: RE: [seamoby] RE: Authentication & Authorization > "in-the-large" > w as Re: [seamob y] ct problem statement > > > > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Thursday, June 14, 2001 6:02 PM > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > Calhoun'; Phillip > > Neumiller > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > Subject: RE: [seamoby] RE: Authentication & Authorization > > "in-the-large" > > w as Re: [seamob y] ct problem statement > > > > > > > > > > -----Original Message----- > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > Sent: Thursday, June 14, 2001 4:46 PM > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > wirelessinternet@internet.motlabs.com > > Subject: RE: [seamoby] RE: Authentication & Authorization > > "in-the-large" > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Thursday, June 14, 2001 5:09 PM > > > To: 'Pat Calhoun'; Phillip Neumiller > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > Kulwinder > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > To: Phillip Neumiller > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > wirelessinternet@internet.motlabs.com > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller wrote: > > > > There are companies that build products (WRQ's reflection comes > > > > to mind) that freeze the state of the IP stack (gracefully in > > > > the application sense), until the flow of IP traffic can resume. > > > > This is sort of an ultra-slow handover. I see no > reason why THIS > > > > can not be made seamless with CT. Why should CT not be capable > > > > of accomodating this Pat? > > > > > > Sure, they could, but what is seamless in this sense? The user has > > > no service for some time, so what is an extra couple of > > seconds while > > > signalling occurs over the air to update the local ARs state?? The > > > user would probably not even notice. > > > > > > Actually, you seem to imply something that I am not sure that I've > > > been thinking about that much, which is the mobile updating the > > > AR's state. This, btw, can be problematic, since the > mobile doesn't > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > malicious mobile could send bogus (mal-formed) CT packets in an > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > Something to think about in the DoS space. > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > ball of wax. As I said earlier the assumption was that the > > CT happens > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > The MN is not authenticated to the newAR, so all kinds of security > > > problems exists until the MN is "properly introduced" to > the newAR. > > > > What do you mean "properly introduced" to the newAR. The MN > > can certainly > > authenticate to the newAR. The MN can just show up at the > new AR and > > introduce itself. It called "Reactive" Context Transfer. > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > the security > > details between MN and newAR. Yes, MN can authenticate itself > > to newAR but > > not as part of CT, and for sure not before CT completition, > > especially, if > > the intention of CT was to transfer MN's > > for-AAA-Security-needed context. > > > > I don't think reactive context transfer was meant to be > > initiated by MN and > > definitely not after "MN's introduction itself to newAR". > > Of course it was intended. Read the Archive. If the MN is switching > between wireless and wired, _as_stated_in_our_charter_, there > is no other > way other than MN initiated CT. > > What do you expect will happen when an MN loses connectivity > between ARs and > just shows up at the newAR? Do you _really_ expect the > End-User to drive > back during Rush Hour to the oldAR and try again? > > > What does this > > introduction mean in context of "context transfer" anyway. If > > CT is supposed > > to happen between ARs, where does this introduction come in? > > Unless you are > > talking about an L2 connectivity signal or even an L2 > > authentication (which > > is not very fast!!!). > > The scenario is an AR-AR CT, then an MN-newAR authentication (proper > > introduction) > > based on transferred credential after CT is complete. > > How does the newAR even know that the MN has arrived if the > MN does not > annouce itself? Why should the newAR waste time doing a CT > for an MN that > is not authorized? Sounds like an opportunity for a DOS > attack. Authorize > first. Then do CT. Especially for an MN that has arrived > unannouced at the > newAR due to a service disruption will moving between ARs. > > - Kulwinder. > > > > > The preferred case, of course, is when the oldAR transfers > > trust to the > > newAR. > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > But, certainly we must consider the case of an MN just > > showing up at the > > newAR. The newAR is then faced with finding out where the > MN was last > > attached and invalidating the oldSA. The MN has to present a > > credential to > > the newAR that the oldAR will accept as valid. > > > > MN>> Yes, but that is not where CT helps, you are out of the > > CT-is-an-optimization > > territory. MN does a lot of negotiations for establishing > the context > > anyway. > > > > BTW, I just noticed that my initials and acronym for Mobile > > Node are the > > same :( > > "MN>> means I am talking :) > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > PatC > > > > > > ------_=_NextPart_001_01C0F547.84F51030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] RE: Authentication & Authorization = "in-the-large" w as Re: [seamob y] ct problem = statement

Kulwinder:

  I don't agree with your observation. We did = discuss how CT was to be
initiated, and agreed that there would be no = explicit signalling from
the MN (not at least as far as CT was concerned). =

  The definition of reactive CT (read the = problem statement)has to do with
the order/timing of events, not with where the = initiating event comes from.

Gary

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucot= to.com]
> Sent: Thursday, June 14, 2001 6:30 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder = Atwal; 'Pat
> Calhoun'; Phillip
> Neumiller
> Cc: 'seamoby'; = wirelessinternet@internet.motlabs.com
> Subject: RE: [seamoby] RE: Authentication & = Authorization
> "in-the-large"
> w as Re: [seamob y] ct problem statement
>
>
>
>
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> > Sent: Thursday, June 14, 2001 6:02 = PM
> > To: 'Kulwinder Atwal'; Nakhjiri = Madjid-MNAKHJI1; 'Pat
> > Calhoun'; Phillip
> > Neumiller
> > Cc: 'seamoby'; = wirelessinternet@internet.motlabs.com
> > Subject: RE: [seamoby] RE: Authentication = & Authorization
> > "in-the-large"
> > w as Re: [seamob y] ct problem = statement
> >
> >
> >
> >
> > -----Original Message-----
> > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucot= to.com]
> > Sent: Thursday, June 14, 2001 4:46 = PM
> > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat = Calhoun'; Phillip Neumiller
> > Cc: Arthur Ross; Charlie Perkins; = Kulwinder Atwal; 'seamoby';
> > = wirelessinternet@internet.motlabs.com
> > Subject: RE: [seamoby] RE: Authentication = & Authorization
> > "in-the-large"
> > w as Re: [seamob y] ct problem = statement
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1 =
> [mailto:Madjid.Nakhjiri@moto= rola.com]
> > > Sent: Thursday, June 14, 2001 5:09 = PM
> > > To: 'Pat Calhoun'; Phillip = Neumiller
> > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur = Ross; Charlie Perkins;
> > Kulwinder
> > > Atwal; 'seamoby'; = wirelessinternet@internet.motlabs.com
> > > Subject: RE: [seamoby] RE: = Authentication & Authorization
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem = statement
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> > > Sent: Wednesday, June 13, 2001 8:29 = AM
> > > To: Phillip Neumiller
> > > Cc: 'Pat Calhoun'; Nakhjiri = Madjid-MNAKHJI1; Arthur Ross; Charlie
> > > Perkins; Kulwinder Atwal; = 'seamoby';
> > > = wirelessinternet@internet.motlabs.com
> > > Subject: Re: [seamoby] RE: = Authentication & Authorization
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem = statement
> > >
> > >
> > > On Wed, Jun 13, 2001 at 09:13:09AM = -0400, Phillip Neumiller wrote:
> > > > There are companies that build = products (WRQ's reflection comes
> > > > to mind) that freeze the state = of the IP stack (gracefully in
> > > > the application sense), until = the flow of IP traffic can resume.
> > > > This is sort of an ultra-slow = handover.  I see no
> reason why THIS
> > > > can not be made seamless with = CT.  Why should CT not be capable
> > > > of accomodating this Pat?
> > >
> > > Sure, they could, but what is = seamless in this sense? The user has
> > > no service for some time, so what is = an extra couple of
> > seconds while
> > > signalling occurs over the air to = update the local ARs state?? The
> > > user would probably not even = notice.
> > >
> > > Actually, you seem to imply something = that I am not sure that I've
> > > been thinking about that much, which = is the mobile updating the
> > > AR's state. This, btw, can be = problematic, since the
> mobile doesn't
> > > necessarily share an SA with the AR = (hence DoS attacks), and a
> > > malicious mobile could send bogus = (mal-formed) CT packets in an
> > > attempt to crash (or cause = mis-behaving) ARs.
> > >
> > > Something to think about in the DoS = space.
> > >
> > > MN>> Yes, involving the MN is = CT is definitely a whole other
> > > ball of wax. As I said earlier the = assumption was that the
> > CT happens
> > > AR to AR and I was exploring the DoSs = for that case.
> >
> >
> > > The MN is not authenticated to the = newAR, so all kinds of security
> > > problems exists until the MN is = "properly introduced" to
> the newAR.
> >
> > What do you mean "properly = introduced" to the newAR.  The MN
> > can certainly
> > authenticate to the newAR.  The MN = can just show up at the
> new AR and
> > introduce itself.  It called = "Reactive" Context Transfer.
> >
> > MN>>> Kulwinder, by = "properly introduced", I meant to skip
> > the security
> > details between MN and newAR. Yes, MN can = authenticate itself
> > to newAR but
> > not as part of CT, and for sure not before = CT completition,
> > especially, if
> > the intention of CT was to transfer MN's =
> > for-AAA-Security-needed context.
> >
> > I don't think reactive context transfer = was meant to be
> > initiated by MN and
> > definitely not after "MN's = introduction itself to newAR".
>
> Of course it was intended.  Read the = Archive.  If the MN is switching
> between wireless and wired, = _as_stated_in_our_charter_, there
> is no other
> way other than MN initiated CT.
>
> What do you expect will happen when an MN loses = connectivity
> between ARs and
> just shows up at the newAR?  Do you = _really_ expect the
> End-User to drive
> back during Rush Hour to the oldAR and try = again?
> 
> > What does this
> > introduction mean in context of = "context transfer" anyway. If
> > CT is supposed
> > to happen between ARs, where does this = introduction come in?
> > Unless you are
> > talking about an L2 connectivity signal or = even an L2
> > authentication (which
> > is not very fast!!!).
> > The scenario is an AR-AR CT, then an = MN-newAR authentication (proper
> > introduction)
> > based on transferred credential after CT = is complete.
>
> How does the newAR even know that the MN has = arrived if the
> MN does not
> annouce itself?  Why should the newAR = waste time doing a CT
> for an MN that
> is not authorized?  Sounds like an = opportunity for a DOS
> attack.  Authorize
> first.  Then do CT.  Especially for = an MN that has arrived
> unannouced at the
> newAR due to a service disruption will moving = between ARs.
>
> - Kulwinder.
>
> >
> > The preferred case, of course, is when the = oldAR transfers
> > trust to the
> > newAR.
> >
> > MN>> Of course. That is why I = mentioned "properly introduced"
> >
> > But, certainly we must consider the case = of an MN just
> > showing up at the
> > newAR.  The newAR is then faced with = finding out where the
> MN was last
> > attached and invalidating the oldSA.  = The MN has to present a
> > credential to
> > the newAR that the oldAR will accept as = valid.
> >
> > MN>> Yes, but that is not where CT = helps, you are out of the
> > CT-is-an-optimization
> > territory. MN does a lot of negotiations = for establishing
> the context
> > anyway.
> >
> > BTW, I just noticed that my initials and = acronym for Mobile
> > Node are the
> > same :(
> > "MN>> means I am talking = :)
> >
> > Madjid
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > Madjid
> > >
> > > PatC
> > >
> >
>

------_=_NextPart_001_01C0F547.84F51030-- From owner-seamoby@diameter.org Fri Jun 15 05:20: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 FAA02043 for ; Fri, 15 Jun 2001 05:20:24 -0400 (EDT) Received: (qmail 23450 invoked by alias); 15 Jun 2001 09:09:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23444 invoked by uid 200); 15 Jun 2001 09:09:12 -0000 Received: (qmail 23436 invoked from network); 15 Jun 2001 09:09:10 -0000 Received: from chello213047128084.15.vie.surfer.at (HELO ssaserv1.roesti.cc) (213.47.128.84) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 09:09:10 -0000 Received: by chello213047128084.15.vie.surfer.at with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 11:14:55 +0200 Message-ID: <71C667A91D79D41197910050DA46B3C902FC77@chello213047128084.15.vie.surfer.at> From: Hannes Tschofenig To: "'Charlie Perkins '" , "'Pat Calhoun '" Cc: "'Arthur Ross '" , "''seamoby' '" Subject: RE: [seamoby] The two-year-ago token Date: Fri, 15 Jun 2001 11:14:51 +0200 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 Hello folks, If I remember right, the token went under the nickname of "blob" in those days. When I try to apply the token theory to context transfer, I get the following: - Mobile supplies token - New access router validates token == how does it prevent against another node "prematurely" using the token? == how does it prevent replay? == does the same token work for all nearby access routers? - New access router asks old access router for context features - Old access router sends stuff - ... # one possible use of a token (ticket) would be: # the mobile node A when authenticating to a AR1 would obtain a # session key k(a,ar1) and a # token {TS,TT,k(a,ar1),ID(a),ID(ar1)}k(ar) whereby # TS is a timestamp, TT is the maximum lifetime and k(a,ar1) is the # session key used between the client and the ar1. the key k(ar) # shared between all ARs. # # when a mobile node moves to a new AR (AR2) he would use old session # key k(a,ar1) to build an authenticator # {CurrentTimestamp,...}k(a,ar1) and sends this authenticator together # with the received ticket to the new AR (AR2). # # AR2 is able to decrypt the received token(ticket) to receive the # embedded session key k(a,ar1). Using the session key he is able # to verify the authenticator and authenticate the user. # (AR2 has to do more verification steps which are omitted here!) == how does it prevent replay? # yes - only a authenticated user knows the session key and is able to # build the authenticator. == does the same token work for all nearby access routers? # it depends how many routers share the same key k(ar). # what do you think? # ciao # hannes From owner-seamoby@diameter.org Fri Jun 15 08:37: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 IAA05378 for ; Fri, 15 Jun 2001 08:37:59 -0400 (EDT) Received: (qmail 24311 invoked by alias); 15 Jun 2001 12:26:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24305 invoked by uid 200); 15 Jun 2001 12:26:29 -0000 Received: (qmail 24295 invoked by uid 500); 15 Jun 2001 12:26:27 -0000 Date: Fri, 15 Jun 2001 05:26:27 -0700 From: Pat Calhoun To: Charlie Perkins Cc: Pat Calhoun , Arthur Ross , "'seamoby'" Subject: Re: [seamoby] The two-year-ago token Message-ID: <20010615052626.J17928@charizard.diameter.org> Mail-Followup-To: Charlie Perkins , Pat Calhoun , Arthur Ross , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> <3B295DCC.A0F831E9@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B295DCC.A0F831E9@iprg.nokia.com>; from charliep@IPRG.nokia.com on Thu, Jun 14, 2001 at 05:58:52PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote: > If I remember right, the token went under the nickname of "blob" > in those days. correct. > When I try to apply the token theory to context > transfer, I get the following: > > - Mobile supplies token No, the access router provides the token to the mobile. The token includes the amount of time the user has been authorized to have access, the features the mobile has been authorized to use, an encrypted session key that the access router uses to secure messages between itself and the mobile, a timestamp, expiration time, and is digitally signed. > - New access router validates token correct. > == how does it prevent against another node "prematurely" > using the token? What does this mean?!? Once a token has been provided to the mobile, it isn't premature.... > == how does it prevent replay? The token has a lifetime, which SHOULD be the same as the authorized amount of the time the user may access the network (this, btw, is returned by AAA). > == does the same token work for all nearby access routers? yes. There is a need for all access routers to be able to verify the validity of the token. This could require that they all share a Private key, or some other mechanism on the back end that would allow them to share the decrypted version of the token. > - New access router asks old access router for context features correct, and this is based on the info contained in the token. > - Old access router sends stuff which it agreed to do, based on the features in the token. > - ... ... > In this scenario, I don't see much advantage because the > old access router could more easily check some credentials > produced by the mobile node as part of its request to get > stuff from the old access router. Or maybe it's all a matter > of definition, and a "blob" and a "token" should be treated > as variations of some "credential data", and the only point > is which access router verifies it. Or we might be worried > about how much data has to go over the air. I believe that the concern at the time was the amount of data over the air, but this still significantly reduces the amount of time it would take to construct all of this information if AAA had to be contacted. Keep in mind, though, that the primary use for the blob at the time was to carry session keys across access routers to eliminate the need to re-establish an SA between the MN and the FA. This was done prior to the context transfer work, and if CT exists, then it most likely is much more efficient to simply CT this information across ARs, instead of have the mobile supply it. PatC From owner-seamoby@diameter.org Fri Jun 15 09:15: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 JAA06612 for ; Fri, 15 Jun 2001 09:15:30 -0400 (EDT) Received: (qmail 24949 invoked by alias); 15 Jun 2001 13:04:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24943 invoked by uid 200); 15 Jun 2001 13:04:18 -0000 Received: (qmail 24935 invoked from network); 15 Jun 2001 13:04:16 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 13:04:16 -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 GAA26128; Fri, 15 Jun 2001 06:14:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FDEK731832; Fri, 15 Jun 2001 06:14:20 -0700 X-mProtect: Fri, 15 Jun 2001 06:14:20 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHP82mY; Fri, 15 Jun 2001 06:14:18 PDT Message-ID: <3B2A0A25.416AC95F@iprg.nokia.com> Date: Fri, 15 Jun 2001 06:14:13 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Charlie Perkins , "'seamoby'" Subject: Re: [seamoby] The two-year-ago token References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> <3B295DCC.A0F831E9@iprg.nokia.com> <20010615052626.J17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat, quick question: Pat Calhoun wrote: > On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote: > > If I remember right, the token went under the nickname of "blob" > > in those days. > correct. > > > When I try to apply the token theory to context > > transfer, I get the following: > > > > - Mobile supplies token > No, the access router provides the token to the mobile. The token includes > the amount of time the user has been authorized to have access, the features > the mobile has been authorized to use, an encrypted session key that the > access router uses to secure messages between itself and the mobile, a timestamp, > expiration time, and is digitally signed. > If the token equals authorization, who performs the authentication? (in new terminology, what credentials are necessary to obtain the token). Thanks, Cedric. From owner-seamoby@diameter.org Fri Jun 15 09:35: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 JAA07713 for ; Fri, 15 Jun 2001 09:35:29 -0400 (EDT) Received: (qmail 25478 invoked by alias); 15 Jun 2001 13:24:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25472 invoked by uid 200); 15 Jun 2001 13:24:15 -0000 Received: (qmail 25462 invoked by uid 500); 15 Jun 2001 13:24:13 -0000 Date: Fri, 15 Jun 2001 06:24:13 -0700 From: Pat Calhoun To: Cedric Westphal Cc: Pat Calhoun , Charlie Perkins , "'seamoby'" Subject: Re: [seamoby] The two-year-ago token Message-ID: <20010615062412.L17928@charizard.diameter.org> Mail-Followup-To: Cedric Westphal , Pat Calhoun , Charlie Perkins , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> <3B295DCC.A0F831E9@iprg.nokia.com> <20010615052626.J17928@charizard.diameter.org> <3B2A0A25.416AC95F@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2A0A25.416AC95F@iprg.nokia.com>; from cedric@IPRG.nokia.com on Fri, Jun 15, 2001 at 06:14:13AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 15, 2001 at 06:14:13AM -0700, Cedric Westphal wrote: > Pat, > > quick question: > > Pat Calhoun wrote: > > > On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote: > > > If I remember right, the token went under the nickname of "blob" > > > in those days. > > correct. > > > > > When I try to apply the token theory to context > > > transfer, I get the following: > > > > > > - Mobile supplies token > > No, the access router provides the token to the mobile. The token includes > > the amount of time the user has been authorized to have access, the features > > the mobile has been authorized to use, an encrypted session key that the > > access router uses to secure messages between itself and the mobile, a timestamp, > > expiration time, and is digitally signed. > > > > If the token equals authorization, who performs the authentication? > (in new terminology, what credentials are necessary to obtain the token). When the mobile first gains access to the network, the user's home AAA is contacted, and the mobile is granted access. The AAA message contains the authorization lifetime, and this information is used by the FA in creating the token (or blob). In the mobile ip case, the AAA server would also create the MN-FA session key, and this data would be included in the blob. All future mobile ip messages from the mobile would include the MN-FA authentication extension, and new ARs would use the session key embedded in the blob (which is encrypted, of course) to authenticate the MN-FA authentication extension, eliminating the need for the AAA to be contacted again. PatC From owner-seamoby@diameter.org Fri Jun 15 11:10: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 LAA11332 for ; Fri, 15 Jun 2001 11:10:42 -0400 (EDT) Received: (qmail 27796 invoked by alias); 15 Jun 2001 14:59:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27790 invoked by uid 200); 15 Jun 2001 14:59:05 -0000 Received: (qmail 27782 invoked from network); 15 Jun 2001 14:59:03 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 14:59:03 -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 IAA01178; Fri, 15 Jun 2001 08:09:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FF9DZ16305; Fri, 15 Jun 2001 08:09:13 -0700 X-mProtect: Fri, 15 Jun 2001 08:09:13 -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 smtpdaJPb3d; Fri, 15 Jun 2001 08:09:12 PDT Message-ID: <3B2A2518.C7DBC81@iprg.nokia.com> Date: Fri, 15 Jun 2001 08:09:12 -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: Pat Calhoun CC: "'seamoby'" Subject: Re: [seamoby] The two-year-ago token References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> <3B295DCC.A0F831E9@iprg.nokia.com> <20010615052626.J17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: >> When I try to apply the token theory to context >> transfer, I get the following: >> >> - Mobile supplies token > No, the access router provides the token to the mobile. The token includes > the amount of time the user has been authorized to have access, the features > the mobile has been authorized to use, an encrypted session key that the > access router uses to secure messages between itself and the mobile, a timestamp, > expiration time, and is digitally signed. To be more precise, my three-word description should have read: "the mobile supplies to the new access router the token which was given to it by the previous access router." >> == how does it prevent against another node "prematurely" >> using the token? > What does this mean?!? Once a token has been provided to the mobile, > it isn't premature.... If node X overhears my token, then it _could_ use it before I got around to using it. Thus, the answer to my question would be "by encrypting the token". I'm only just pointing out that the whole tokenizing procedure needs care. >> == how does it prevent replay? > The token has a lifetime, which SHOULD be the same as the authorized > amount of the time the user may access the network (this, btw, is > returned by AAA). That's not good enough actually. Again, I know it can be solved, but the problem could be that someone might borrow my context by asking it to be transferred again, even within the lifetime of the token. There are many variations. It's worthwhile to note that the previous access router SHOULD (or, maybe MUST) maintain the state even for a little while after it has been requested, because the context transfer SHOULD (or, maybe MUST) be resilient to one or two dropped packets in the control message flow. >> == does the same token work for all nearby access routers? > yes. There is a need for all access routers to be able to verify the > validity of the token. This could require that they all share a Private > key, or some other mechanism on the back end that would allow them to > share the decrypted version of the token. This is the big disadvantage of the blob scheme compared to the scheme whereby the previous access router itself checks the transfer credentials. > I believe that the concern at the time was the amount of data > over the air, but this still significantly reduces the amount > of time it would take to construct all of this information if > AAA had to be contacted. Agreed. > PatC Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 11:45:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12316 for ; Fri, 15 Jun 2001 11:45:21 -0400 (EDT) Received: (qmail 30725 invoked by alias); 15 Jun 2001 15:28:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30714 invoked by uid 200); 15 Jun 2001 15:28:52 -0000 Received: (qmail 30692 invoked by uid 500); 15 Jun 2001 15:28:48 -0000 Date: Fri, 15 Jun 2001 08:28:48 -0700 From: Pat Calhoun To: "Charles E. Perkins" Cc: Pat Calhoun , "'seamoby'" Subject: Re: [seamoby] The two-year-ago token Message-ID: <20010615082848.X17928@charizard.diameter.org> Mail-Followup-To: "Charles E. Perkins" , Pat Calhoun , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5CD5@zcard031.ca.nortel.com> <20010611140953.R17928@charizard.diameter.org> <3B295DCC.A0F831E9@iprg.nokia.com> <20010615052626.J17928@charizard.diameter.org> <3B2A2518.C7DBC81@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2A2518.C7DBC81@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 15, 2001 at 08:09:12AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 15, 2001 at 08:09:12AM -0700, Charles E. Perkins wrote: > Pat Calhoun wrote: > >> == how does it prevent against another node "prematurely" > >> using the token? > > > What does this mean?!? Once a token has been provided to the mobile, > > it isn't premature.... > > If node X overhears my token, then it _could_ use it before I got > around to using it. Thus, the answer to my question would be > "by encrypting the token". I'm only just pointing out that the > whole tokenizing procedure needs care. let him. Unless he has the somehow figured out how to retrieve the session keys from your device, the token is useless... Again, session keys are used to authenticate messages. The token isn't useful at all to the mobile, it's an AR thing. > > >> == how does it prevent replay? > > The token has a lifetime, which SHOULD be the same as the authorized > > amount of the time the user may access the network (this, btw, is > > returned by AAA). > > That's not good enough actually. Again, I know it can be solved, > but the problem could be that someone might borrow my context > by asking it to be transferred again, even within the lifetime > of the token. There are many variations. It's worthwhile to note > that the previous access router SHOULD (or, maybe MUST) maintain > the state even for a little while after it has been requested, > because the context transfer SHOULD (or, maybe MUST) be resilient > to one or two dropped packets in the control message flow. But your point here is that someone has stolen the session key, which would be mandatory in order to generate such an attack. I would claim that if someone has been successful in stealing your key, then there isn't a whole lot that you can do to protect yourself against such an attack (not to mention many others). > > >> == does the same token work for all nearby access routers? > > yes. There is a need for all access routers to be able to verify the > > validity of the token. This could require that they all share a Private > > key, or some other mechanism on the back end that would allow them to > > share the decrypted version of the token. > > This is the big disadvantage of the blob scheme compared to the scheme > whereby the previous access router itself checks the transfer credentials. I think that we agree that even when the ARs communicate, they must secure the data, so it happens either way. Having said that, I agree that direct communication is preferable, but again, this was a SIMPLE proposal way back when CT didn't even exist (well, not that it does today either, but you know what I mean) Thanks, PatC From owner-seamoby@diameter.org Fri Jun 15 12:03: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 MAA12834 for ; Fri, 15 Jun 2001 12:03:38 -0400 (EDT) Received: (qmail 32688 invoked by alias); 15 Jun 2001 15:51:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32682 invoked by uid 200); 15 Jun 2001 15:51:52 -0000 Received: (qmail 32674 invoked from network); 15 Jun 2001 15:51:49 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 15:51:49 -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 KAA23711; Fri, 15 Jun 2001 10:02:28 -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 JAA11280; Fri, 15 Jun 2001 09:02:28 -0700 (PDT) Message-Id: <200106151602.JAA11280@heliopolis.eng.sun.com> Date: Fri, 15 Jun 2001 09:02:28 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] The two-year-ago token To: charliep@IPRG.nokia.com, pcalhoun@diameter.org Cc: pcalhoun@diameter.org, a.ross@ieee.org, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: frHOvivg6voRbh+LGQ/0lw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Another advantage is reduction in the amount of PDP/PEP traffic needed to authorize QoS after the mobile has moved. If the PEP can make the decision based on the blob, this traffic can be eliminated, considerably speeding up reestablishing QoS on the new subnet. jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Fri, 15 Jun 2001 05:26:27 -0700 >From: Pat Calhoun >To: Charlie Perkins >Cc: Pat Calhoun , Arthur Ross , "'seamoby'" >Subject: Re: [seamoby] The two-year-ago token >Mail-Followup-To: Charlie Perkins , Pat Calhoun , Arthur Ross , 'seamoby' >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote: >> If I remember right, the token went under the nickname of "blob" >> in those days. >correct. > >> When I try to apply the token theory to context >> transfer, I get the following: >> >> - Mobile supplies token >No, the access router provides the token to the mobile. The token includes >the amount of time the user has been authorized to have access, the features >the mobile has been authorized to use, an encrypted session key that the >access router uses to secure messages between itself and the mobile, a timestamp, >expiration time, and is digitally signed. > >> - New access router validates token >correct. > >> == how does it prevent against another node "prematurely" >> using the token? >What does this mean?!? Once a token has been provided to the mobile, >it isn't premature.... > >> == how does it prevent replay? >The token has a lifetime, which SHOULD be the same as the authorized >amount of the time the user may access the network (this, btw, is >returned by AAA). > >> == does the same token work for all nearby access routers? >yes. There is a need for all access routers to be able to verify the >validity of the token. This could require that they all share a Private >key, or some other mechanism on the back end that would allow them to >share the decrypted version of the token. > >> - New access router asks old access router for context features >correct, and this is based on the info contained in the token. > >> - Old access router sends stuff >which it agreed to do, based on the features in the token. > >> - ... >... > >> In this scenario, I don't see much advantage because the >> old access router could more easily check some credentials >> produced by the mobile node as part of its request to get >> stuff from the old access router. Or maybe it's all a matter >> of definition, and a "blob" and a "token" should be treated >> as variations of some "credential data", and the only point >> is which access router verifies it. Or we might be worried >> about how much data has to go over the air. > >I believe that the concern at the time was the amount of data >over the air, but this still significantly reduces the amount >of time it would take to construct all of this information if >AAA had to be contacted. > >Keep in mind, though, that the primary use for the blob at the >time was to carry session keys across access routers to eliminate >the need to re-establish an SA between the MN and the FA. This >was done prior to the context transfer work, and if CT exists, >then it most likely is much more efficient to simply CT this >information across ARs, instead of have the mobile supply it. > >PatC From owner-seamoby@diameter.org Fri Jun 15 13:02: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 NAA16552 for ; Fri, 15 Jun 2001 13:02:27 -0400 (EDT) Received: (qmail 3815 invoked by alias); 15 Jun 2001 16:50:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3809 invoked by uid 200); 15 Jun 2001 16:50:57 -0000 Received: (qmail 3804 invoked from network); 15 Jun 2001 16:50:55 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 16:50:55 -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 KAA08470; Fri, 15 Jun 2001 10:01:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FH14309445; Fri, 15 Jun 2001 10:01:04 -0700 X-mProtect: Fri, 15 Jun 2001 10:01:04 -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 smtpd7s3Ixi; Fri, 15 Jun 2001 10:01:02 PDT Message-ID: <3B2A3F4E.709B42B7@iprg.nokia.com> Date: Fri, 15 Jun 2001 10:01:02 -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: Gary Kenward CC: "'seamoby'" Subject: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D20@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, > Gary Kenward wrote: > ....... We did discuss how CT was to be > initiated, and agreed that there would be no explicit signalling from > the MN (not at least as far as CT was concerned). I would consider this as wholly unacceptable, except that in your next paragraph you state: > The definition of reactive CT (read the problem statement)has to do with > the order/timing of events, not with where the initiating event comes from. So then I started to wonder about how one might define "reactive" to make the previous sentence come true. But, the word "reactive" does not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. No help there. I did find some redefinition of "reactive" in draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, not the result of design team discussions. In fact, I have some other comments on the latter document, but for now I would just like to suggest that it should not be taken as relevant to the current discussion about reactive context transfers. That puts me back to square one. From that standpoint, I would like to suggest that the context transfer problem statement needs to very clearly define the following concepts: - Network-initiated context transfer, for which the access network tells the mobile where to go - Mobile-initiated context transfer, for which the mobile tells the network where it wants to go - Predictive context transfer, for which either the mobile or the network initiates context transfer BEFORE leaving the previous access router - Reactive context transfer, for which either the mobile or the network initiates context transfer AFTER the mobile arrives (establishes a link) at the new access router. I like the word "predictive" for several reasons: - It has exactly the right meaning, and even connotes that caution is necessary because not all predictions come true - In contrast to some other alternatives one often hears, it is a word that one can find in the dictionary. Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 13:22: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 NAA17824 for ; Fri, 15 Jun 2001 13:22:56 -0400 (EDT) Received: (qmail 4395 invoked by alias); 15 Jun 2001 17:11:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4389 invoked by uid 200); 15 Jun 2001 17:11:30 -0000 Received: (qmail 4384 invoked by uid 500); 15 Jun 2001 17:11:28 -0000 Date: Fri, 15 Jun 2001 10:11:28 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] IP Paging Design Team has concluded Message-ID: <20010615101128.K17928@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, First, I'd like to thank James Kempf for his outstanding work in getting the documents out fast, and in excellent quality. Of course, his job could not have been done without the help of the IP Paging design team members as well. Since both the Problem Statement and the Requirements Internet-Drafts are now in the hands of the IESG, this design team is concluded. The seamoby web page has been updated to reflect this change. Thanks PatC From owner-seamoby@diameter.org Fri Jun 15 13:33: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 NAA18436 for ; Fri, 15 Jun 2001 13:33:01 -0400 (EDT) Received: (qmail 4911 invoked by alias); 15 Jun 2001 17:20:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4906 invoked by uid 200); 15 Jun 2001 17:20:12 -0000 Received: (qmail 4901 invoked from network); 15 Jun 2001 17:20:10 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 17:20:10 -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 KAA10989; Fri, 15 Jun 2001 10:30:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FHUK922529; Fri, 15 Jun 2001 10:30:20 -0700 X-mProtect: Fri, 15 Jun 2001 10:30:20 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQ0PaYp; Fri, 15 Jun 2001 10:30:19 PDT Message-ID: <3B2A462B.BD729BEE@iprg.nokia.com> Date: Fri, 15 Jun 2001 10:30:19 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'seamoby'" Subject: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C9F5D20@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, Gary Kenward wrote: > > > Kulwinder: > > I don't agree with your observation. We did discuss how CT was to be > > initiated, and agreed that there would be no explicit signalling from > the MN (not at least as far as CT was concerned). > Rajeev: I don't believe that we ever said there would be no explicit signaling from the MN! In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives the option to the MN to indicate how the feature contexts be handled. I would have strong objection to this. > > The definition of reactive CT (read the problem statement)has to do > with > the order/timing of events, not with where the initiating event comes > from. Rajeev: I don't remember going through reactive CT or proactive CT during problem statement phase at all. Nevertheless, where is the definition of reactive CT that says a MN cannot initiate signaling ? Regards, -Rajeev > > > Gary > > > -----Original Message----- > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > Sent: Thursday, June 14, 2001 6:30 PM > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > Calhoun'; Phillip > > Neumiller > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > Subject: RE: [seamoby] RE: Authentication & Authorization > > "in-the-large" > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Thursday, June 14, 2001 6:02 PM > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > Calhoun'; Phillip > > > Neumiller > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > -----Original Message----- > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > Sent: Thursday, June 14, 2001 4:46 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > Kulwinder > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > To: Phillip Neumiller > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > Charlie > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > wirelessinternet@internet.motlabs.com > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > wrote: > > > > > There are companies that build products (WRQ's reflection > comes > > > > > to mind) that freeze the state of the IP stack (gracefully in > > > > > the application sense), until the flow of IP traffic can > resume. > > > > > This is sort of an ultra-slow handover. I see no > > reason why THIS > > > > > can not be made seamless with CT. Why should CT not be > capable > > > > > of accomodating this Pat? > > > > > > > > Sure, they could, but what is seamless in this sense? The user > has > > > > no service for some time, so what is an extra couple of > > > seconds while > > > > signalling occurs over the air to update the local ARs state?? > The > > > > user would probably not even notice. > > > > > > > > Actually, you seem to imply something that I am not sure that > I've > > > > been thinking about that much, which is the mobile updating the > > > > AR's state. This, btw, can be problematic, since the > > mobile doesn't > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > malicious mobile could send bogus (mal-formed) CT packets in an > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > Something to think about in the DoS space. > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > ball of wax. As I said earlier the assumption was that the > > > CT happens > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > security > > > > problems exists until the MN is "properly introduced" to > > the newAR. > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > can certainly > > > authenticate to the newAR. The MN can just show up at the > > new AR and > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > the security > > > details between MN and newAR. Yes, MN can authenticate itself > > > to newAR but > > > not as part of CT, and for sure not before CT completition, > > > especially, if > > > the intention of CT was to transfer MN's > > > for-AAA-Security-needed context. > > > > > > I don't think reactive context transfer was meant to be > > > initiated by MN and > > > definitely not after "MN's introduction itself to newAR". > > > > Of course it was intended. Read the Archive. If the MN is > switching > > between wireless and wired, _as_stated_in_our_charter_, there > > is no other > > way other than MN initiated CT. > > > > What do you expect will happen when an MN loses connectivity > > between ARs and > > just shows up at the newAR? Do you _really_ expect the > > End-User to drive > > back during Rush Hour to the oldAR and try again? > > > > > What does this > > > introduction mean in context of "context transfer" anyway. If > > > CT is supposed > > > to happen between ARs, where does this introduction come in? > > > Unless you are > > > talking about an L2 connectivity signal or even an L2 > > > authentication (which > > > is not very fast!!!). > > > The scenario is an AR-AR CT, then an MN-newAR authentication > (proper > > > introduction) > > > based on transferred credential after CT is complete. > > > > How does the newAR even know that the MN has arrived if the > > MN does not > > annouce itself? Why should the newAR waste time doing a CT > > for an MN that > > is not authorized? Sounds like an opportunity for a DOS > > attack. Authorize > > first. Then do CT. Especially for an MN that has arrived > > unannouced at the > > newAR due to a service disruption will moving between ARs. > > > > - Kulwinder. > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > trust to the > > > newAR. > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > But, certainly we must consider the case of an MN just > > > showing up at the > > > newAR. The newAR is then faced with finding out where the > > MN was last > > > attached and invalidating the oldSA. The MN has to present a > > > credential to > > > the newAR that the oldAR will accept as valid. > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > CT-is-an-optimization > > > territory. MN does a lot of negotiations for establishing > > the context > > > anyway. > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > Node are the > > > same :( > > > "MN>> means I am talking :) > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > PatC > > > > > > > > > From owner-seamoby@diameter.org Fri Jun 15 13:37: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 NAA18678 for ; Fri, 15 Jun 2001 13:37:20 -0400 (EDT) Received: (qmail 5389 invoked by alias); 15 Jun 2001 17:25:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5383 invoked by uid 200); 15 Jun 2001 17:25:55 -0000 Received: (qmail 5378 invoked by uid 500); 15 Jun 2001 17:25:53 -0000 Date: Fri, 15 Jun 2001 10:25:53 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Micro-Mobility Design Team concludes Message-ID: <20010615102553.L17928@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 Micro-Mobility folks had a very difficult task to complete, and that was to write the problem statement. The PS spec was extremely useful in understanding the problem space, and was responsible for the handoff discovery work on our charter. It was also responsible for some possible new routing work being done in the IRTF. I would like to thank Dana Blair for his great work in getting this work done, as well as John Loughney, the editor of the problem statement. The seamoby web page has been updated to reflect the fact that this design team is concluded. Thanks, PatC From owner-seamoby@diameter.org Fri Jun 15 13:40:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18860 for ; Fri, 15 Jun 2001 13:40:21 -0400 (EDT) Received: (qmail 5757 invoked by alias); 15 Jun 2001 17:27:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5746 invoked by uid 200); 15 Jun 2001 17:27:54 -0000 Received: (qmail 5731 invoked by uid 500); 15 Jun 2001 17:27:51 -0000 Date: Fri, 15 Jun 2001 10:27:51 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: Re: [seamoby] Micro-Mobility Design Team concludes Message-ID: <20010615102751.M17928@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org References: <20010615102553.L17928@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010615102553.L17928@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Jun 15, 2001 at 10:25:53AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk I failed to mention that this work could not have happened without the help of all of the design team members. PatC On Fri, Jun 15, 2001 at 10:25:53AM -0700, Pat Calhoun wrote: > All, > > The Micro-Mobility folks had a very difficult task to complete, and that > was to write the problem statement. The PS spec was extremely useful in > understanding the problem space, and was responsible for the handoff discovery > work on our charter. It was also responsible for some possible new routing > work being done in the IRTF. > > I would like to thank Dana Blair for his great work in getting this work > done, as well as John Loughney, the editor of the problem statement. > > The seamoby web page has been updated to reflect the fact that this > design team is concluded. > > Thanks, > > PatC From owner-seamoby@diameter.org Fri Jun 15 13:53: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 NAA19546 for ; Fri, 15 Jun 2001 13:53:04 -0400 (EDT) Received: (qmail 6656 invoked by alias); 15 Jun 2001 17:39:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6650 invoked by uid 200); 15 Jun 2001 17:39:59 -0000 Received: (qmail 6645 invoked from network); 15 Jun 2001 17:39:57 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 17:39:57 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 13:50:05 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FFB@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Gary Kenward Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Fri, 15 Jun 2001 13:50:04 -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 I would strongly object as well. No MN involvement is technology specific and implementation specific. The End-User needs the ability to decide when to switch between different link-layers: wireless and wired. There is NO way for the network to know this is about to happen. Infact, there was much dicussion in support of this as a requirement. We need to add some new text. - Kulwinder. > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Friday, June 15, 2001 1:30 PM > To: Gary Kenward > Cc: 'seamoby' > Subject: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > Authorization ... > > > > Hello Gary, > > > Gary Kenward wrote: > > > > > > > Kulwinder: > > > > I don't agree with your observation. We did discuss how > CT was to be > > > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > > > Rajeev: I don't believe that we ever said there would be no explicit > signaling from the MN! > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives > the option to the MN to indicate how the feature contexts be handled. > > I would have strong objection to this. > > > > > > The definition of reactive CT (read the problem > statement)has to do > > with > > the order/timing of events, not with where the initiating > event comes > > from. > > Rajeev: I don't remember going through reactive CT or proactive CT > during problem statement phase at all. Nevertheless, where is the > definition of reactive CT that says a MN cannot initiate signaling ? > > Regards, > > -Rajeev > > > > > > > > Gary > > > > > -----Original Message----- > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > Sent: Thursday, June 14, 2001 6:30 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > Calhoun'; Phillip > > > Neumiller > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > Kulwinder > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > To: Phillip Neumiller > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > Charlie > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > wrote: > > > > > > There are companies that build products (WRQ's reflection > > comes > > > > > > to mind) that freeze the state of the IP stack > (gracefully in > > > > > > the application sense), until the flow of IP traffic can > > resume. > > > > > > This is sort of an ultra-slow handover. I see no > > > reason why THIS > > > > > > can not be made seamless with CT. Why should CT not be > > capable > > > > > > of accomodating this Pat? > > > > > > > > > > Sure, they could, but what is seamless in this sense? The user > > has > > > > > no service for some time, so what is an extra couple of > > > > seconds while > > > > > signalling occurs over the air to update the local ARs state?? > > The > > > > > user would probably not even notice. > > > > > > > > > > Actually, you seem to imply something that I am not sure that > > I've > > > > > been thinking about that much, which is the mobile > updating the > > > > > AR's state. This, btw, can be problematic, since the > > > mobile doesn't > > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > > malicious mobile could send bogus (mal-formed) CT > packets in an > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > ball of wax. As I said earlier the assumption was that the > > > > CT happens > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > security > > > > > problems exists until the MN is "properly introduced" to > > > the newAR. > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > can certainly > > > > authenticate to the newAR. The MN can just show up at the > > > new AR and > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > the security > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > to newAR but > > > > not as part of CT, and for sure not before CT completition, > > > > especially, if > > > > the intention of CT was to transfer MN's > > > > for-AAA-Security-needed context. > > > > > > > > I don't think reactive context transfer was meant to be > > > > initiated by MN and > > > > definitely not after "MN's introduction itself to newAR". > > > > > > Of course it was intended. Read the Archive. If the MN is > > switching > > > between wireless and wired, _as_stated_in_our_charter_, there > > > is no other > > > way other than MN initiated CT. > > > > > > What do you expect will happen when an MN loses connectivity > > > between ARs and > > > just shows up at the newAR? Do you _really_ expect the > > > End-User to drive > > > back during Rush Hour to the oldAR and try again? > > > > > > > What does this > > > > introduction mean in context of "context transfer" anyway. If > > > > CT is supposed > > > > to happen between ARs, where does this introduction come in? > > > > Unless you are > > > > talking about an L2 connectivity signal or even an L2 > > > > authentication (which > > > > is not very fast!!!). > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > (proper > > > > introduction) > > > > based on transferred credential after CT is complete. > > > > > > How does the newAR even know that the MN has arrived if the > > > MN does not > > > annouce itself? Why should the newAR waste time doing a CT > > > for an MN that > > > is not authorized? Sounds like an opportunity for a DOS > > > attack. Authorize > > > first. Then do CT. Especially for an MN that has arrived > > > unannouced at the > > > newAR due to a service disruption will moving between ARs. > > > > > > - Kulwinder. > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > trust to the > > > > newAR. > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > But, certainly we must consider the case of an MN just > > > > showing up at the > > > > newAR. The newAR is then faced with finding out where the > > > MN was last > > > > attached and invalidating the oldSA. The MN has to present a > > > > credential to > > > > the newAR that the oldAR will accept as valid. > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > CT-is-an-optimization > > > > territory. MN does a lot of negotiations for establishing > > > the context > > > > anyway. > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > Node are the > > > > same :( > > > > "MN>> means I am talking :) > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > PatC > > > > > > > > > > > > > From owner-seamoby@diameter.org Fri Jun 15 14:02: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 OAA20055 for ; Fri, 15 Jun 2001 14:01:55 -0400 (EDT) Received: (qmail 7251 invoked by alias); 15 Jun 2001 17:48:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7245 invoked by uid 200); 15 Jun 2001 17:48:11 -0000 Received: (qmail 7240 invoked from network); 15 Jun 2001 17:48:09 -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; 15 Jun 2001 17:48:09 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FHw7E27606 for ; Fri, 15 Jun 2001 13:58:07 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 15 Jun 2001 13:57:55 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 13:57:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 13:57:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5C4.B4C10E40" 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_01C0F5C4.B4C10E40 Content-Type: text/plain; charset="iso-8859-1" Charlie: For us, it is unacceptable that CT should be dependent upon some layer 3 messaging from the MN. Over the air transit latencies are just too great, and we don' see the value. I think here we simply must agree that we have different views of the world. This whole issue was discussed at great length, and it was clear then that there was no "right" approach. We decided then that we would abstract out the initiating event - some called it a trigger - and that would allow for different networks and different vendors to define the approach they like the best. Who triggers context transfer is not relevant, unless we believe we are going to build the trigger into CTP as a signalling message. There was a long debate, and it was decided very early on that it was not necessary to build this into CTP. That does not mean that this approach is excluded from the mobility solution, nor does it mean that an MN message could not trigger CT indirectly. It simply means that CTP will not include an MN to AR message. You can refer to the archives if you question this, in particular, the conference call meeting minutes. At the moment, I would suggest strongly that we retain that decision. It allows both camps to work on their preferred solution. More importantly, it would allow us to move forward. What you are proposing is to return to the discussions of six months ago. This would be unacceptable to me, for sure, and I suspect others engaged with this process would also be very frustrated. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 1:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: [seamoby] Reactive context transfer > > > > Hello Gary, > > > Gary Kenward wrote: > > > ....... We did discuss how CT was to be > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > I would consider this as wholly unacceptable, except that in your > next paragraph you state: > > > The definition of reactive CT (read the problem > statement)has to do with > > the order/timing of events, not with where the initiating > event comes from. > > So then I started to wonder about how one might define "reactive" to > make the previous sentence come true. But, the word "reactive" does > not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. > No help there. I did find some redefinition of "reactive" in > draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, > not the result of design team discussions. In fact, I have some > other comments on the latter document, but for now I would just like > to suggest that it should not be taken as relevant to the current > discussion about reactive context transfers. > > That puts me back to square one. From that standpoint, I would like > to suggest that the context transfer problem statement needs to > very clearly define the following concepts: > > - Network-initiated context transfer, for which the access network > tells the mobile where to go > > - Mobile-initiated context transfer, for which the mobile tells the > network where it wants to go > > - Predictive context transfer, for which either the mobile or the > network initiates context transfer BEFORE leaving the previous > access router > > - Reactive context transfer, for which either the mobile or > the network > initiates context transfer AFTER the mobile arrives (establishes > a link) at the new access router. > > > I like the word "predictive" for several reasons: > > - It has exactly the right meaning, and even connotes that caution > is necessary because not all predictions come true > > - In contrast to some other alternatives one often hears, it is > a word that one can find in the dictionary. > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F5C4.B4C10E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Reactive context transfer

Charlie:

 For us, it is unacceptable that CT should be = dependent upon
some layer 3 messaging from the MN. Over the air = transit latencies
are just too great, and we don' see the value. I = think here we
simply must agree that we have different views of = the world.

 This whole issue was discussed at great length, = and it was
clear then that there was no "right" = approach. We decided then
that we would abstract out the initiating event - = some called
it a trigger - and that would allow for different = networks and
different vendors to define the approach they like = the best.

 Who triggers context transfer is not relevant, = unless we believe
we are going to build the trigger into CTP as a = signalling message.
There was a long debate, and it was decided very = early on that
it was not necessary to build this into CTP. That = does not
mean that this approach is excluded from the = mobility solution, nor
does it mean that an MN message could not trigger CT = indirectly. It
simply means that CTP will not include an MN to AR = message.

 You can refer to the archives if you question = this, in particular,
the conference call meeting minutes.

 At the moment, I would suggest strongly that we = retain that decision.
It allows both camps to work on their preferred = solution. More importantly,
it would allow us to move forward.

 What you are proposing is to return to the = discussions of six months ago.
This would be unacceptable to me, for sure, and I = suspect others engaged
with this process would also be very = frustrated.

Gary


> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: [seamoby] Reactive context = transfer
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> >        = .......          &nbs= p;        We did discuss how CT was = to be
> > initiated, and agreed that there would be = no explicit
> signalling from
> > the MN (not at least as far as CT was = concerned).
>
> I would consider this as wholly unacceptable, = except that in your
> next paragraph you state:
>
> >   The definition of reactive CT = (read the problem
> statement)has to do with
> > the order/timing of events, not with where = the initiating
> event comes from.
>
> So then I started to wonder about how one might = define "reactive" to
> make the previous sentence come true.  = But, the word "reactive" does
> not occur in = draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
> No help there.  I did find some = redefinition of "reactive" in
> draft-hamid-seamoby-ct-fwk-00.txt, but that = document was, I believe,
> not the result of design team = discussions.  In fact, I have some
> other comments on the latter document, but for = now I would just like
> to suggest that it should not be taken as = relevant to the current
> discussion about reactive context = transfers.
>
> That puts me back to square one.  From = that standpoint, I would like
> to suggest that the context transfer problem = statement needs to
> very clearly define the following = concepts:
>
> - Network-initiated context transfer, for which = the access network
>   tells the mobile where to go
>
> - Mobile-initiated context transfer, for which = the mobile tells the
>   network where it wants to go
>
> - Predictive context transfer, for which either = the mobile or the
>   network initiates context transfer = BEFORE leaving the previous
>   access router
>
> - Reactive context transfer, for which either = the mobile or
> the network
>   initiates context transfer AFTER = the mobile arrives (establishes
>   a link) at the new access = router.
>
>
> I like the word "predictive" for = several reasons:
>
> - It has exactly the right meaning, and even = connotes that caution
>   is necessary because not all = predictions come true
>
> - In contrast to some other alternatives one = often hears, it is
>   a word that one can find in the = dictionary.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F5C4.B4C10E40-- From owner-seamoby@diameter.org Fri Jun 15 14:09: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 OAA20536 for ; Fri, 15 Jun 2001 14:09:43 -0400 (EDT) Received: (qmail 7860 invoked by alias); 15 Jun 2001 17:58:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7854 invoked by uid 200); 15 Jun 2001 17:58:11 -0000 Received: (qmail 7849 invoked from network); 15 Jun 2001 17:58:09 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 17:58:09 -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 MAA12740; Fri, 15 Jun 2001 12:08:48 -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 LAA16550; Fri, 15 Jun 2001 11:08:49 -0700 (PDT) Message-Id: <200106151808.LAA16550@heliopolis.eng.sun.com> Date: Fri, 15 Jun 2001 11:08:48 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Reactive context transfer To: charliep@IPRG.nokia.com, gkenward@nortelnetworks.com Cc: seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yZ40meYK3sLZc9Vv4zm15A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Charlie/Gary, > For us, it is unacceptable that CT should be dependent upon >some layer 3 messaging from the MN. Over the air transit latencies >are just too great, and we don' see the value. I think here we >simply must agree that we have different views of the world. > I agree with this. Increasing the handover latency even more results in a higher probability of human perceptible artifacts in real time streams. We cannot realistically recommend IP as a substrate for 4G telephony unless we can design handover so that the probability of artifacts is absolutely minimal. > This whole issue was discussed at great length, and it was >clear then that there was no "right" approach. We decided then >that we would abstract out the initiating event - some called >it a trigger - and that would allow for different networks and >different vendors to define the approach they like the best. > I agree with this as well. In WLANs, for example, the aggregate bandwidth is much higher. The amount of latency in small cells with few MNs moving slowly (walking speed at best) will probably be small enough that the MN can become actively involved in context transfer. The specification needs to parameterized so that triggering of handover depends on the characteristics of the radio link. Charlie's original message had four possiblities, which I view as being two sets of orthogonal characteristics, with two possibilities each. One set is network, mobile triggered. The other is source, target triggered (or what you have been calling proactive and reactive). I think the spec needs to call these out. jak From owner-seamoby@diameter.org Fri Jun 15 14:13: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 OAA20760 for ; Fri, 15 Jun 2001 14:13:02 -0400 (EDT) Received: (qmail 8359 invoked by alias); 15 Jun 2001 18:01:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8352 invoked by uid 200); 15 Jun 2001 18:01:23 -0000 Received: (qmail 8341 invoked from network); 15 Jun 2001 18:01:20 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:01:20 -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 LAA14229; Fri, 15 Jun 2001 11:11:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FIBTl23478; Fri, 15 Jun 2001 11:11:29 -0700 X-mProtect: Fri, 15 Jun 2001 11:11:29 -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 smtpd1G3Uq0; Fri, 15 Jun 2001 11:11:27 PDT Message-ID: <3B2A4FCF.ABB497A@iprg.nokia.com> Date: Fri, 15 Jun 2001 11:11:27 -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: Gary Kenward CC: "'seamoby'" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, > Gary Kenward wrote: > For us, it is unacceptable that CT should be dependent upon > some layer 3 messaging from the MN. Over the air transit latencies > are just too great, and we don' see the value. I think here we > simply must agree that we have different views of the world. Maybe we're not so far apart after all. Of course I agree that we should have the possibility to do context transfer without requiring the mobile node to trigger the process. I'm just holding out for the possibility that the mobile node CAN trigger the process in some circumstances. For instance, it would probably be just fine over 802.11, even if it's not advisable over some cellular media. > This whole issue was discussed at great length, and it was > clear then that there was no "right" approach. We decided then > that we would abstract out the initiating event - some called > it a trigger - and that would allow for different networks and > different vendors to define the approach they like the best. Exactly. Thus, I claim we aren't so far apart. But, some of the allowable choices should include allowing the mobile node to initiate the process of context transfer. > Who triggers context transfer is not relevant, unless we believe > we are going to build the trigger into CTP as a signalling message. > There was a long debate, and it was decided very early on that > it was not necessary to build this into CTP. That does not > mean that this approach is excluded from the mobility solution, nor > does it mean that an MN message could not trigger CT indirectly. It > simply means that CTP will not include an MN to AR message. Again, just because context transfer CAN be accomplished without a trigger from the mobile node in SOME circumstances, does not mean that the mobile node should be disallowed from supplying the trigger in OTHER circumstances. Thus, I agree with the second and third sentences, but it seems pretty clear that we can ALLOW such a trigger indication without dragging down the rest of the protocol. Thus I am asking for reconsideration of the 4th sentence, and I don't see any downside at all. > You can refer to the archives if you question this, in particular, > the conference call meeting minutes. That's raising the bar pretty high for my participation in this particular discussion. Would it be O.K. to ask that you respond just to my points in this e-mail? > What you are proposing is to return to the discussions of six months ago. > This would be unacceptable to me, for sure, and I suspect others engaged > with this process would also be very frustrated. Well, from the e-mail I've seen so far, it looks like there may be frustrations on both sides. Moreover, to accomodate those who wish to allow mobile-node triggering, I don't think would cause any discomfort to those who want to have network-initiated transfers. So why not? Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 14:22: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 OAA21219 for ; Fri, 15 Jun 2001 14:22:15 -0400 (EDT) Received: (qmail 8922 invoked by alias); 15 Jun 2001 18:08:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8916 invoked by uid 200); 15 Jun 2001 18:08:52 -0000 Received: (qmail 8911 invoked from network); 15 Jun 2001 18:08:50 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:08:50 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA21562 for ; Fri, 15 Jun 2001 11:19:30 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA25004 for ; Fri, 15 Jun 2001 11:12:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 13:19:28 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Kulwinder Atwal'" , "'Rajeev Koodli'" , Gary Kenward Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Fri, 15 Jun 2001 13:19: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 I think it is possible to receive link layer trigger at the new access router which can be used to initiate context transfer. This will be mostly useful in case of some intra-technology handovers. In case MN moves across different technologies, yes some sort of MN trigger is useful. Having said that is it a good idea to limit the scope of CT protocol? I think we should allow both the options. regards, ajoy -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Friday, June 15, 2001 12:50 PM To: 'Rajeev Koodli'; Gary Kenward Cc: 'seamoby' Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... I would strongly object as well. No MN involvement is technology specific and implementation specific. The End-User needs the ability to decide when to switch between different link-layers: wireless and wired. There is NO way for the network to know this is about to happen. Infact, there was much dicussion in support of this as a requirement. We need to add some new text. - Kulwinder. > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Friday, June 15, 2001 1:30 PM > To: Gary Kenward > Cc: 'seamoby' > Subject: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > Authorization ... > > > > Hello Gary, > > > Gary Kenward wrote: > > > > > > > Kulwinder: > > > > I don't agree with your observation. We did discuss how > CT was to be > > > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > > > Rajeev: I don't believe that we ever said there would be no explicit > signaling from the MN! > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives > the option to the MN to indicate how the feature contexts be handled. > > I would have strong objection to this. > > > > > > The definition of reactive CT (read the problem > statement)has to do > > with > > the order/timing of events, not with where the initiating > event comes > > from. > > Rajeev: I don't remember going through reactive CT or proactive CT > during problem statement phase at all. Nevertheless, where is the > definition of reactive CT that says a MN cannot initiate signaling ? > > Regards, > > -Rajeev > > > > > > > > Gary > > > > > -----Original Message----- > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > Sent: Thursday, June 14, 2001 6:30 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > Calhoun'; Phillip > > > Neumiller > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > Kulwinder > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > To: Phillip Neumiller > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > Charlie > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > wrote: > > > > > > There are companies that build products (WRQ's reflection > > comes > > > > > > to mind) that freeze the state of the IP stack > (gracefully in > > > > > > the application sense), until the flow of IP traffic can > > resume. > > > > > > This is sort of an ultra-slow handover. I see no > > > reason why THIS > > > > > > can not be made seamless with CT. Why should CT not be > > capable > > > > > > of accomodating this Pat? > > > > > > > > > > Sure, they could, but what is seamless in this sense? The user > > has > > > > > no service for some time, so what is an extra couple of > > > > seconds while > > > > > signalling occurs over the air to update the local ARs state?? > > The > > > > > user would probably not even notice. > > > > > > > > > > Actually, you seem to imply something that I am not sure that > > I've > > > > > been thinking about that much, which is the mobile > updating the > > > > > AR's state. This, btw, can be problematic, since the > > > mobile doesn't > > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > > malicious mobile could send bogus (mal-formed) CT > packets in an > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > ball of wax. As I said earlier the assumption was that the > > > > CT happens > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > security > > > > > problems exists until the MN is "properly introduced" to > > > the newAR. > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > can certainly > > > > authenticate to the newAR. The MN can just show up at the > > > new AR and > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > the security > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > to newAR but > > > > not as part of CT, and for sure not before CT completition, > > > > especially, if > > > > the intention of CT was to transfer MN's > > > > for-AAA-Security-needed context. > > > > > > > > I don't think reactive context transfer was meant to be > > > > initiated by MN and > > > > definitely not after "MN's introduction itself to newAR". > > > > > > Of course it was intended. Read the Archive. If the MN is > > switching > > > between wireless and wired, _as_stated_in_our_charter_, there > > > is no other > > > way other than MN initiated CT. > > > > > > What do you expect will happen when an MN loses connectivity > > > between ARs and > > > just shows up at the newAR? Do you _really_ expect the > > > End-User to drive > > > back during Rush Hour to the oldAR and try again? > > > > > > > What does this > > > > introduction mean in context of "context transfer" anyway. If > > > > CT is supposed > > > > to happen between ARs, where does this introduction come in? > > > > Unless you are > > > > talking about an L2 connectivity signal or even an L2 > > > > authentication (which > > > > is not very fast!!!). > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > (proper > > > > introduction) > > > > based on transferred credential after CT is complete. > > > > > > How does the newAR even know that the MN has arrived if the > > > MN does not > > > annouce itself? Why should the newAR waste time doing a CT > > > for an MN that > > > is not authorized? Sounds like an opportunity for a DOS > > > attack. Authorize > > > first. Then do CT. Especially for an MN that has arrived > > > unannouced at the > > > newAR due to a service disruption will moving between ARs. > > > > > > - Kulwinder. > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > trust to the > > > > newAR. > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > But, certainly we must consider the case of an MN just > > > > showing up at the > > > > newAR. The newAR is then faced with finding out where the > > > MN was last > > > > attached and invalidating the oldSA. The MN has to present a > > > > credential to > > > > the newAR that the oldAR will accept as valid. > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > CT-is-an-optimization > > > > territory. MN does a lot of negotiations for establishing > > > the context > > > > anyway. > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > Node are the > > > > same :( > > > > "MN>> means I am talking :) > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > PatC > > > > > > > > > > > > > From owner-seamoby@diameter.org Fri Jun 15 14:27: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 OAA21490 for ; Fri, 15 Jun 2001 14:27:28 -0400 (EDT) Received: (qmail 9156 invoked by alias); 15 Jun 2001 18:11:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9148 invoked by uid 200); 15 Jun 2001 18:11:38 -0000 Received: (qmail 9137 invoked from network); 15 Jun 2001 18:11:33 -0000 Received: from ihemail1.lucent.com (HELO ihemail1.firewall.lucent.com) (192.11.222.161) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:11:33 -0000 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5FIM9923357 for ; Fri, 15 Jun 2001 14:22:09 -0400 (EDT) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5FILtc23128 for ; Fri, 15 Jun 2001 14:21:55 -0400 (EDT) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA16867; Fri, 15 Jun 2001 14:21:53 -0400 (EDT) Cc: Seamless Mobility Working Group Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA16858; Fri, 15 Jun 2001 14:21:51 -0400 (EDT) Message-ID: <3B2A523E.C6CB774B@lucent.com> Date: Fri, 15 Jun 2001 14:21:50 -0400 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" Original-CC: Seamless Mobility Working Group Subject: Re: [seamoby] More about authorization vs. authentication References: <3B28FD26.9CB1581@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Charlie, I think you make a mistake in equating "claimed identity" with "individual". THe AAA group's definitions seem to provide a better starting point. If we think in terms of authorizing a specific role (as opposed to authorizing an individual), the required security bindings will become much clearer. An individual's "networking role" can be authorized to make a context transfer. It doesn't have to use the same security contexts as the application login role. Authentication mechanisms go beyond credential verfication as they also include e.g. the mechanism for submitting the credentials. ..Erik "Charles E. Perkins" wrote: > > Hello folks, > > Sorry to have missed out on the last few days of discussion. > It seems to me that it is crucial to get some definitions right, > because they are important for the requirements for context > transfer. I've studied a number of sources to get useful > information, and have been very fortunate to get clarifications > and suggestions from e-mail that have helped me understand the > issues better. > > Thanks to Henry Haverinen for sending the following > definitions (which he cited from http://www.pcwebopaedia.com/) > > =============================================================== > > Authentication: > The process of identifying an individual, usually based on a > username and password. In security systems, authentication is > distinct from authorization, which is the process of giving > individuals access to system objects based on their identity. > Authentication merely ensures that the individual is who he > or she claims to be, but says nothing about the access rights > of the individual. > > Authorization: > The process of granting or denying access to a network resource. > Most computer security systems are based on a two-step process. > The first stage is authentication, which ensures that a user is > who he or she claims to be. The second stage is authorization, > which allows the user access to various resources based on the > user's identity. > > ================================================================ > > However, there are other competing definitions for these > terms, often not quite compatible with each other. > > I really think that we have to get some terminology by which > specific proposals can be judged against the security requirements > for context transfer. It seems debatable (at least) whether > the security requirements are met by existing IPsec protocols. > > Maybe for protocol design the general procedure can be > described as follows: > > 1. A node asks for access to some resource, and presents > its credentials. > > 2. The request is received, and the credentials verified. > > 3. If the verification succeeds, information about access to > the resource is delivered to the requesting node. > > This enumeration doesn't explicitly mention authentication or > authorization, and yet to me it seems clear and unambiguous. > Thus, I would suggest that we could use the term "credential > verification" to replace authentication. From what I have > read, most people would understand the meaning of that term > better. Then, the process of "authorization" could either be > taken to mean some sort of internal database access, or else > the delivery of the access information in (3). Or maybe > there wouldn't be any need to use that terminology at all. > > As an aside, I looked in on some related discussion from > the AAA working group, and found some statement that > authorization can be provided without authentication. > > Here are definitions from RFC 2989: > > Authentication > The act of verifying a claimed identity, in the form of a > pre-existing label from a mutually known name space, as the > originator of a message (message authentication) or as the > end-point of a channel (entity authentication). > > Authorization > The act of determining if a particular right, such as > access to some resource, can be granted to the presenter of > a particular credential. > > These definitions support the type of distinctions I had tried to > make in previous e-mails, and that I have understood to describe > the relevant care-of address operations for Mobile IPv6. They > also have the advantage of being somewhat compatible with the > definitions from www.pcwebopaedia.com. They could be taken as > a start for the appropriate definitions within [seamoby], if the > terms are to be used at all. > > Bottom line: one's perspective on this issue seems to depend on > whether "authentication" is taken to mean "identity authentication", > and maybe we could get away without using the terms anyway if we > focus on credential verification. > > Regards, > Charlie P. From owner-seamoby@diameter.org Fri Jun 15 14:33: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 OAA21844 for ; Fri, 15 Jun 2001 14:33:44 -0400 (EDT) Received: (qmail 9504 invoked by alias); 15 Jun 2001 18:15:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9496 invoked by uid 200); 15 Jun 2001 18:15:39 -0000 Received: (qmail 9485 invoked from network); 15 Jun 2001 18:15:35 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:15:35 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:25:45 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FFD@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Gary Kenward'" , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 14:25:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5C8.97971860" 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_01C0F5C8.97971860 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, June 15, 2001 1:58 PM To: 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: [seamoby] Reactive context transfer Charlie: For us, it is unacceptable that CT should be dependent upon some layer 3 messaging from the MN. Over the air transit latencies are just too great, and we don' see the value. I think here we simply must agree that we have different views of the world. This is implementation specific. This whole issue was discussed at great length, and it was clear then that there was no "right" approach. We decided then that we would abstract out the initiating event - some called it a trigger - and that would allow for different networks and different vendors to define the approach they like the best. Since I was the one who proposed triggers. My recollection is quite different. The intent was that we would not know where the trigger packet came from, but at no time did I ever suggest it was out of scope. In fact, I explicitly stated that it could be MN or Network initiated as did Vijay. Who triggers context transfer is not relevant, unless we believe we are going to build the trigger into CTP as a signalling message. There was a long debate, and it was decided very early on that it was not necessary to build this into CTP. That does not mean that this approach is excluded from the mobility solution, nor does it mean that an MN message could not trigger CT indirectly. It simply means that CTP will not include an MN to AR message. You can refer to the archives if you question this, in particular, the conference call meeting minutes. IETF rules do not allow concensus from meetings. ONLY mailing lists concenus is valid. At the moment, I would suggest strongly that we retain that decision. It allows both camps to work on their preferred solution. More importantly, it would allow us to move forward. We cannot move forward until this is resolved. - Kulwinder. What you are proposing is to return to the discussions of six months ago. This would be unacceptable to me, for sure, and I suspect others engaged with this process would also be very frustrated. Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@IPRG.nokia.com ] > Sent: Friday, June 15, 2001 1:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: [seamoby] Reactive context transfer > > > > Hello Gary, > > > Gary Kenward wrote: > > > ....... We did discuss how CT was to be > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > I would consider this as wholly unacceptable, except that in your > next paragraph you state: > > > The definition of reactive CT (read the problem > statement)has to do with > > the order/timing of events, not with where the initiating > event comes from. > > So then I started to wonder about how one might define "reactive" to > make the previous sentence come true. But, the word "reactive" does > not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. > No help there. I did find some redefinition of "reactive" in > draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, > not the result of design team discussions. In fact, I have some > other comments on the latter document, but for now I would just like > to suggest that it should not be taken as relevant to the current > discussion about reactive context transfers. > > That puts me back to square one. From that standpoint, I would like > to suggest that the context transfer problem statement needs to > very clearly define the following concepts: > > - Network-initiated context transfer, for which the access network > tells the mobile where to go > > - Mobile-initiated context transfer, for which the mobile tells the > network where it wants to go > > - Predictive context transfer, for which either the mobile or the > network initiates context transfer BEFORE leaving the previous > access router > > - Reactive context transfer, for which either the mobile or > the network > initiates context transfer AFTER the mobile arrives (establishes > a link) at the new access router. > > > I like the word "predictive" for several reasons: > > - It has exactly the right meaning, and even connotes that caution > is necessary because not all predictions come true > > - In contrast to some other alternatives one often hears, it is > a word that one can find in the dictionary. > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F5C8.97971860 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, June 15, 2001 1:58 PM
To: 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: [seamoby] Reactive context transfer

Charlie:

 For us, it is unacceptable that CT should be dependent upon
some layer 3 messaging from the MN. Over the air transit latencies
are just too great, and we don' see the value. I think here we
simply must agree that we have different views of the world.  

This is implementation specific. 

 This whole issue was discussed at great length, and it was
clear then that there was no "right" approach. We decided then
that we would abstract out the initiating event - some called
it a trigger - and that would allow for different networks and
different vendors to define the approach they like the best.  

Since I was the one who proposed triggers.  My recollection is quite different.

The intent was that we would not know where the trigger packet came from, but at no time did I ever suggest it was out of scope.

In fact, I explicitly stated that it could be MN or Network initiated as did Vijay. 

 Who triggers context transfer is not relevant, unless we believe
we are going to build the trigger into CTP as a signalling message.
There was a long debate, and it was decided very early on that
it was not necessary to build this into CTP. That does not
mean that this approach is excluded from the mobility solution, nor
does it mean that an MN message could not trigger CT indirectly. It
simply means that CTP will not include an MN to AR message.

 You can refer to the archives if you question this, in particular,
the conference call meeting minutes.  

IETF rules do not allow concensus from meetings.  ONLY mailing lists concenus is valid. 

 At the moment, I would suggest strongly that we retain that decision.
It allows both camps to work on their preferred solution. More importantly,
it would allow us to move forward. 

We cannot move forward until this is resolved.

- Kulwinder. 

 What you are proposing is to return to the discussions of six months ago.
This would be unacceptable to me, for sure, and I suspect others engaged
with this process would also be very frustrated.

Gary


> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: [seamoby] Reactive context transfer
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> >        .......                   We did discuss how CT was to be
> > initiated, and agreed that there would be no explicit
> signalling from
> > the MN (not at least as far as CT was concerned).
>
> I would consider this as wholly unacceptable, except that in your
> next paragraph you state:
>
> >   The definition of reactive CT (read the problem
> statement)has to do with
> > the order/timing of events, not with where the initiating
> event comes from.
>
> So then I started to wonder about how one might define "reactive" to
> make the previous sentence come true.  But, the word "reactive" does
> not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
> No help there.  I did find some redefinition of "reactive" in
> draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe,
> not the result of design team discussions.  In fact, I have some
> other comments on the latter document, but for now I would just like
> to suggest that it should not be taken as relevant to the current
> discussion about reactive context transfers.
>
> That puts me back to square one.  From that standpoint, I would like
> to suggest that the context transfer problem statement needs to
> very clearly define the following concepts:
>
> - Network-initiated context transfer, for which the access network
>   tells the mobile where to go
>
> - Mobile-initiated context transfer, for which the mobile tells the
>   network where it wants to go
>
> - Predictive context transfer, for which either the mobile or the
>   network initiates context transfer BEFORE leaving the previous
>   access router
>
> - Reactive context transfer, for which either the mobile or
> the network
>   initiates context transfer AFTER the mobile arrives (establishes
>   a link) at the new access router.
>
>
> I like the word "predictive" for several reasons:
>
> - It has exactly the right meaning, and even connotes that caution
>   is necessary because not all predictions come true
>
> - In contrast to some other alternatives one often hears, it is
>   a word that one can find in the dictionary.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F5C8.97971860-- From owner-seamoby@diameter.org Fri Jun 15 14:41:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22379 for ; Fri, 15 Jun 2001 14:41:17 -0400 (EDT) Received: (qmail 9671 invoked by alias); 15 Jun 2001 18:17:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9664 invoked by uid 200); 15 Jun 2001 18:17:05 -0000 Received: (qmail 9653 invoked from network); 15 Jun 2001 18:17:01 -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; 15 Jun 2001 18:17:01 -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 f5FIQwE02682 for ; Fri, 15 Jun 2001 14:26:59 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Jun 2001 14:26:55 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:26:59 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0E9@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Charles E. Perkins'" , "Gary Kenward" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 14:26:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5C8.C1E4B730" 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_01C0F5C8.C1E4B730 Content-Type: text/plain Hello Charlie, I guess we need to understand the boundaries of context transfer and the actual handover. The first two options you listed are handover scenarios where the decision is made where the mobile is going to handover. I am confused how does it relates to context transfer? The predictive context transfer is the same as the proactive context transfer where context is made available to the new AR before a handover of occurs. Your reactive context transfer definition is more like a "break-before-make" scenario. I do not know how context could be useful if the transfer happens after the handover completion. What will happen to the traffic which has already been handed over to the AR and the context processing is not yet done? particularly with the contexyt information that is calculated on a per packet arrival basis. For example metering?. How metering context could be useful if the meter value at the new AR has already passed. I believe the reactive context transfer is also a make-before-break scenario with context transfer and the handover should occur simulataneously. Ofcourse, context has to reach the new AR before it becomes useless there. cheers -Hamid > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 1:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: [seamoby] Reactive context transfer > > > Hello Gary, > > > Gary Kenward wrote: > > > ....... We did discuss how CT was to be > > initiated, and agreed that there would be no explicit signalling from > > the MN (not at least as far as CT was concerned). > > I would consider this as wholly unacceptable, except that in your > next paragraph you state: > > > The definition of reactive CT (read the problem statement)has to do > with > > the order/timing of events, not with where the initiating event comes > from. > > So then I started to wonder about how one might define "reactive" to > make the previous sentence come true. But, the word "reactive" does > not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. > No help there. I did find some redefinition of "reactive" in > draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, > not the result of design team discussions. In fact, I have some > other comments on the latter document, but for now I would just like > to suggest that it should not be taken as relevant to the current > discussion about reactive context transfers. > > That puts me back to square one. From that standpoint, I would like > to suggest that the context transfer problem statement needs to > very clearly define the following concepts: > > - Network-initiated context transfer, for which the access network > tells the mobile where to go > > - Mobile-initiated context transfer, for which the mobile tells the > network where it wants to go > > - Predictive context transfer, for which either the mobile or the > network initiates context transfer BEFORE leaving the previous > access router > > - Reactive context transfer, for which either the mobile or the network > initiates context transfer AFTER the mobile arrives (establishes > a link) at the new access router. > > > I like the word "predictive" for several reasons: > > - It has exactly the right meaning, and even connotes that caution > is necessary because not all predictions come true > > - In contrast to some other alternatives one often hears, it is > a word that one can find in the dictionary. > > Regards, > Charlie P. ------_=_NextPart_001_01C0F5C8.C1E4B730 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] Reactive context transfer

Hello = Charlie,

I guess we need to = understand the boundaries of context transfer and the actual = handover.

The first two = options you listed are handover scenarios where the decision is made = where the mobile is going to handover. I am confused how does it = relates to context transfer?

The predictive = context transfer is the same as the proactive context transfer where = context is made available to the new AR before a handover of = occurs.

Your reactive = context transfer definition is more like a = "break-before-make" scenario. I do not know how context could = be useful if the transfer happens after the handover completion. What = will happen to the traffic which has already been handed over to the AR = and the context processing is not yet done? particularly with the = contexyt information that is calculated on a per packet arrival basis. = For example metering?. How metering context could be useful if the = meter value at the new AR has already passed. I believe the reactive = context transfer is also a make-before-break scenario with context = transfer and the handover should occur simulataneously. Ofcourse, = context has to reach the new AR before it becomes useless there. =

cheers

-Hamid

    -----Original Message-----
    From:   Charles E. Perkins = [SMTP:charliep@IPRG.nokia.com]
    Sent:   Friday, June 15, 2001 1:01 PM
    To:     Kenward, Gary [WDLN2:AN10:EXCH]
    Cc:     'seamoby'
    Subject:       = [seamoby] Reactive context = transfer


    Hello Gary,

    > Gary Kenward wrote:

    >        = .......          &nbs= p;        We did discuss how CT was = to be
    > initiated, and agreed that there = would be no explicit signalling from
    > the MN (not at least as far as = CT was concerned).

    I would consider this as wholly = unacceptable, except that in your
    next paragraph you state:

    >   The definition of = reactive CT (read the problem statement)has to do with
    > the order/timing of events, not = with where the initiating event comes from.

    So then I started to wonder about how = one might define "reactive" to
    make the previous sentence come = true.  But, the word "reactive" does
    not occur in = draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
    No help there.  I did find some = redefinition of "reactive" in
    draft-hamid-seamoby-ct-fwk-00.txt, = but that document was, I believe,
    not the result of design team = discussions.  In fact, I have some
    other comments on the latter = document, but for now I would just like
    to suggest that it should not be = taken as relevant to the current
    discussion about reactive context = transfers.

    That puts me back to square one.  = From that standpoint, I would like
    to suggest that the context transfer = problem statement needs to
    very clearly define the following = concepts:

    - Network-initiated context transfer, = for which the access network
      tells the mobile where to = go

    - Mobile-initiated context transfer, = for which the mobile tells the
      network where it wants to = go

    - Predictive context transfer, for = which either the mobile or the
      network initiates context = transfer BEFORE leaving the previous
      access router

    - Reactive context transfer, for which = either the mobile or the network
      initiates context transfer = AFTER the mobile arrives (establishes
      a link) at the new access = router.


    I like the word "predictive" = for several reasons:

    - It has exactly the right meaning, = and even connotes that caution
      is necessary because not all = predictions come true

    - In contrast to some other = alternatives one often hears, it is
      a word that one can find in = the dictionary.

    Regards,
    Charlie P.

------_=_NextPart_001_01C0F5C8.C1E4B730-- From owner-seamoby@diameter.org Fri Jun 15 14:46: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 OAA22608 for ; Fri, 15 Jun 2001 14:46:10 -0400 (EDT) Received: (qmail 9718 invoked by alias); 15 Jun 2001 18:17:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9712 invoked by uid 200); 15 Jun 2001 18:17:19 -0000 Received: (qmail 9700 invoked by uid 500); 15 Jun 2001 18:17:15 -0000 Date: Fri, 15 Jun 2001 11:17:15 -0700 From: Pat Calhoun To: "Charles E. Perkins" Cc: Gary Kenward , "'seamoby'" Subject: Re: [seamoby] Reactive context transfer Message-ID: <20010615111715.X17928@charizard.diameter.org> Mail-Followup-To: "Charles E. Perkins" , Gary Kenward , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> <3B2A4FCF.ABB497A@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2A4FCF.ABB497A@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 15, 2001 at 11:11:27AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk Charlie, Based on your comment below, it doesn't sounds like you are stating that a CT MN->AR message is needed, but rather that a L2 trigger that would cause CT MAY be generated by the mobile. If this is true, then I believe that we are *all* in agreement, and if so, may I ask what in the spec could be changed to reflect this agreement? PatC On Fri, Jun 15, 2001 at 11:11:27AM -0700, Charles E. Perkins wrote: > > Hello Gary, > > > Gary Kenward wrote: > > > For us, it is unacceptable that CT should be dependent upon > > some layer 3 messaging from the MN. Over the air transit latencies > > are just too great, and we don' see the value. I think here we > > simply must agree that we have different views of the world. > > Maybe we're not so far apart after all. Of course I agree that > we should have the possibility to do context transfer without > requiring the mobile node to trigger the process. I'm just > holding out for the possibility that the mobile node CAN trigger > the process in some circumstances. For instance, it would probably > be just fine over 802.11, even if it's not advisable over some > cellular media. > > > This whole issue was discussed at great length, and it was > > clear then that there was no "right" approach. We decided then > > that we would abstract out the initiating event - some called > > it a trigger - and that would allow for different networks and > > different vendors to define the approach they like the best. > > Exactly. Thus, I claim we aren't so far apart. But, some of the > allowable choices should include allowing the mobile node to > initiate the process of context transfer. > > > Who triggers context transfer is not relevant, unless we believe > > we are going to build the trigger into CTP as a signalling message. > > There was a long debate, and it was decided very early on that > > it was not necessary to build this into CTP. That does not > > mean that this approach is excluded from the mobility solution, nor > > does it mean that an MN message could not trigger CT indirectly. It > > simply means that CTP will not include an MN to AR message. > > Again, just because context transfer CAN be accomplished without > a trigger from the mobile node in SOME circumstances, does not mean > that the mobile node should be disallowed from supplying the trigger > in OTHER circumstances. Thus, I agree with the second and third > sentences, but it seems pretty clear that we can ALLOW such a > trigger indication without dragging down the rest of the protocol. > Thus I am asking for reconsideration of the 4th sentence, and I > don't see any downside at all. > > > You can refer to the archives if you question this, in particular, > > the conference call meeting minutes. > > That's raising the bar pretty high for my participation in this > particular discussion. Would it be O.K. to ask that you respond > just to my points in this e-mail? > > > What you are proposing is to return to the discussions of six months ago. > > This would be unacceptable to me, for sure, and I suspect others engaged > > with this process would also be very frustrated. > > Well, from the e-mail I've seen so far, it looks like there may be > frustrations on both sides. Moreover, to accomodate those who wish > to allow mobile-node triggering, I don't think would cause any > discomfort to those who want to have network-initiated transfers. > So why not? > > Regards, > Charlie P. From owner-seamoby@diameter.org Fri Jun 15 14:55:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23201 for ; Fri, 15 Jun 2001 14:55:48 -0400 (EDT) Received: (qmail 12086 invoked by alias); 15 Jun 2001 18:42:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12080 invoked by uid 200); 15 Jun 2001 18:42:29 -0000 Received: (qmail 12064 invoked from network); 15 Jun 2001 18:42:22 -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; 15 Jun 2001 18:42:22 -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 f5FIqC018948 for ; Fri, 15 Jun 2001 14:52:12 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Jun 2001 14:52:02 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:52:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D2F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 14:52:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5CC.434765E0" 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_01C0F5CC.434765E0 Content-Type: text/plain; charset="iso-8859-1" Charlie: I'm never one to oppose providing for optional solutions, as long as the cost is justifiable. I think we are together on this. Let's get to the protocol design and take it from there. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 2:11 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: Re: [seamoby] Reactive context transfer > > > > Hello Gary, > > > Gary Kenward wrote: > > > For us, it is unacceptable that CT should be dependent upon > > some layer 3 messaging from the MN. Over the air transit latencies > > are just too great, and we don' see the value. I think here we > > simply must agree that we have different views of the world. > > Maybe we're not so far apart after all. Of course I agree that > we should have the possibility to do context transfer without > requiring the mobile node to trigger the process. I'm just > holding out for the possibility that the mobile node CAN trigger > the process in some circumstances. For instance, it would probably > be just fine over 802.11, even if it's not advisable over some > cellular media. > > > This whole issue was discussed at great length, and it was > > clear then that there was no "right" approach. We decided then > > that we would abstract out the initiating event - some called > > it a trigger - and that would allow for different networks and > > different vendors to define the approach they like the best. > > Exactly. Thus, I claim we aren't so far apart. But, some of the > allowable choices should include allowing the mobile node to > initiate the process of context transfer. > > > Who triggers context transfer is not relevant, unless we believe > > we are going to build the trigger into CTP as a signalling message. > > There was a long debate, and it was decided very early on that > > it was not necessary to build this into CTP. That does not > > mean that this approach is excluded from the mobility solution, nor > > does it mean that an MN message could not trigger CT indirectly. It > > simply means that CTP will not include an MN to AR message. > > Again, just because context transfer CAN be accomplished without > a trigger from the mobile node in SOME circumstances, does not mean > that the mobile node should be disallowed from supplying the trigger > in OTHER circumstances. Thus, I agree with the second and third > sentences, but it seems pretty clear that we can ALLOW such a > trigger indication without dragging down the rest of the protocol. > Thus I am asking for reconsideration of the 4th sentence, and I > don't see any downside at all. > > > You can refer to the archives if you question this, in particular, > > the conference call meeting minutes. > > That's raising the bar pretty high for my participation in this > particular discussion. Would it be O.K. to ask that you respond > just to my points in this e-mail? > > > What you are proposing is to return to the discussions of > six months ago. > > This would be unacceptable to me, for sure, and I suspect > others engaged > > with this process would also be very frustrated. > > Well, from the e-mail I've seen so far, it looks like there may be > frustrations on both sides. Moreover, to accomodate those who wish > to allow mobile-node triggering, I don't think would cause any > discomfort to those who want to have network-initiated transfers. > So why not? > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F5CC.434765E0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer

Charlie:

  I'm never one to oppose providing for optional solutions,
as long as the cost is justifiable. I think we are together
on this. Let's get to the protocol design and take it from there.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 2:11 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Reactive context transfer
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> >  For us, it is unacceptable that CT should be dependent upon
> > some layer 3 messaging from the MN. Over the air transit latencies
> > are just too great, and we don' see the value. I think here we
> > simply must agree that we have different views of the world.
>
> Maybe we're not so far apart after all.  Of course I agree that
> we should have the possibility to do context transfer without
> requiring the mobile node to trigger the process.  I'm just
> holding out for the possibility that the mobile node CAN trigger
> the process in some circumstances.  For instance, it would probably
> be just fine over 802.11, even if it's not advisable over some
> cellular media.
>
> >  This whole issue was discussed at great length, and it was
> > clear then that there was no "right" approach. We decided then
> > that we would abstract out the initiating event - some called
> > it a trigger - and that would allow for different networks and
> > different vendors to define the approach they like the best.
>
> Exactly.  Thus, I claim we aren't so far apart.  But, some of the
> allowable choices should include allowing the mobile node to
> initiate the process of context transfer.
>
> >  Who triggers context transfer is not relevant, unless we believe
> > we are going to build the trigger into CTP as a signalling message.
> > There was a long debate, and it was decided very early on that
> > it was not necessary to build this into CTP. That does not
> > mean that this approach is excluded from the mobility solution, nor
> > does it mean that an MN message could not trigger CT indirectly. It
> > simply means that CTP will not include an MN to AR message.
>
> Again, just because context transfer CAN be accomplished without
> a trigger from the mobile node in SOME circumstances, does not mean
> that the mobile node should be disallowed from supplying the trigger
> in OTHER circumstances.  Thus, I agree with the second and third
> sentences, but it seems pretty clear that we can ALLOW such a
> trigger indication without dragging down the rest of the protocol.
> Thus I am asking for reconsideration of the 4th sentence, and I
> don't see any downside at all.
>
> > You can refer to the archives if you question this, in particular,
> > the conference call meeting minutes.
>
> That's raising the bar pretty high for my participation in this
> particular discussion.  Would it be O.K. to ask that you respond
> just to my points in this e-mail?
>
> > What you are proposing is to return to the discussions of
> six months ago.
> > This would be unacceptable to me, for sure, and I suspect
> others engaged
> > with this process would also be very frustrated.
>
> Well, from the e-mail I've seen so far, it looks like there may be
> frustrations on both sides.  Moreover, to accomodate those who wish
> to allow mobile-node triggering, I don't think would cause any
> discomfort to those who want to have network-initiated transfers.
> So why not?
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F5CC.434765E0-- From owner-seamoby@diameter.org Fri Jun 15 15:07: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 PAA23895 for ; Fri, 15 Jun 2001 15:07:32 -0400 (EDT) Received: (qmail 12575 invoked by alias); 15 Jun 2001 18:49:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12569 invoked by uid 200); 15 Jun 2001 18:49:14 -0000 Received: (qmail 12564 invoked from network); 15 Jun 2001 18:49:12 -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; 15 Jun 2001 18:49:12 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FIx9023512 for ; Fri, 15 Jun 2001 14:59:09 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 15 Jun 2001 14:59:04 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:59:06 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D30@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Fri, 15 Jun 2001 14:59:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5CD.40C691F0" 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_01C0F5CD.40C691F0 Content-Type: text/plain; charset="iso-8859-1" How can I clarify this: the decision was not to "exclude" MN triggering, the decision was to exclude layer 3 signalling from the MN as part of CTP. There needs to be a trigger event (this I believe we all also agreed upon). Some of us believe that the most effective source for this trigger event is from the link layer (this is the only way you can actually be proactive, as far as I know). However, there should not be any design restriction in CTP preventing this trigger event from being generated from a different source, and signalled via IP. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, June 15, 2001 1:30 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > Authorization ... > > > > Hello Gary, > > > Gary Kenward wrote: > > > > > > > Kulwinder: > > > > I don't agree with your observation. We did discuss how > CT was to be > > > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > > > Rajeev: I don't believe that we ever said there would be no explicit > signaling from the MN! > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives > the option to the MN to indicate how the feature contexts be handled. > > I would have strong objection to this. > > > > > > The definition of reactive CT (read the problem > statement)has to do > > with > > the order/timing of events, not with where the initiating > event comes > > from. > > Rajeev: I don't remember going through reactive CT or proactive CT > during problem statement phase at all. Nevertheless, where is the > definition of reactive CT that says a MN cannot initiate signaling ? > > Regards, > > -Rajeev > > > > > > > > Gary > > > > > -----Original Message----- > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > Sent: Thursday, June 14, 2001 6:30 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > Calhoun'; Phillip > > > Neumiller > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > Kulwinder > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > To: Phillip Neumiller > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > Charlie > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > wrote: > > > > > > There are companies that build products (WRQ's reflection > > comes > > > > > > to mind) that freeze the state of the IP stack > (gracefully in > > > > > > the application sense), until the flow of IP traffic can > > resume. > > > > > > This is sort of an ultra-slow handover. I see no > > > reason why THIS > > > > > > can not be made seamless with CT. Why should CT not be > > capable > > > > > > of accomodating this Pat? > > > > > > > > > > Sure, they could, but what is seamless in this sense? The user > > has > > > > > no service for some time, so what is an extra couple of > > > > seconds while > > > > > signalling occurs over the air to update the local ARs state?? > > The > > > > > user would probably not even notice. > > > > > > > > > > Actually, you seem to imply something that I am not sure that > > I've > > > > > been thinking about that much, which is the mobile > updating the > > > > > AR's state. This, btw, can be problematic, since the > > > mobile doesn't > > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > > malicious mobile could send bogus (mal-formed) CT > packets in an > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > ball of wax. As I said earlier the assumption was that the > > > > CT happens > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > security > > > > > problems exists until the MN is "properly introduced" to > > > the newAR. > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > can certainly > > > > authenticate to the newAR. The MN can just show up at the > > > new AR and > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > the security > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > to newAR but > > > > not as part of CT, and for sure not before CT completition, > > > > especially, if > > > > the intention of CT was to transfer MN's > > > > for-AAA-Security-needed context. > > > > > > > > I don't think reactive context transfer was meant to be > > > > initiated by MN and > > > > definitely not after "MN's introduction itself to newAR". > > > > > > Of course it was intended. Read the Archive. If the MN is > > switching > > > between wireless and wired, _as_stated_in_our_charter_, there > > > is no other > > > way other than MN initiated CT. > > > > > > What do you expect will happen when an MN loses connectivity > > > between ARs and > > > just shows up at the newAR? Do you _really_ expect the > > > End-User to drive > > > back during Rush Hour to the oldAR and try again? > > > > > > > What does this > > > > introduction mean in context of "context transfer" anyway. If > > > > CT is supposed > > > > to happen between ARs, where does this introduction come in? > > > > Unless you are > > > > talking about an L2 connectivity signal or even an L2 > > > > authentication (which > > > > is not very fast!!!). > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > (proper > > > > introduction) > > > > based on transferred credential after CT is complete. > > > > > > How does the newAR even know that the MN has arrived if the > > > MN does not > > > annouce itself? Why should the newAR waste time doing a CT > > > for an MN that > > > is not authorized? Sounds like an opportunity for a DOS > > > attack. Authorize > > > first. Then do CT. Especially for an MN that has arrived > > > unannouced at the > > > newAR due to a service disruption will moving between ARs. > > > > > > - Kulwinder. > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > trust to the > > > > newAR. > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > But, certainly we must consider the case of an MN just > > > > showing up at the > > > > newAR. The newAR is then faced with finding out where the > > > MN was last > > > > attached and invalidating the oldSA. The MN has to present a > > > > credential to > > > > the newAR that the oldAR will accept as valid. > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > CT-is-an-optimization > > > > territory. MN does a lot of negotiations for establishing > > > the context > > > > anyway. > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > Node are the > > > > same :( > > > > "MN>> means I am talking :) > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > PatC > > > > > > > > > > > > > > ------_=_NextPart_001_01C0F5CD.40C691F0 Content-Type: text/html; charset="iso-8859-1" RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...

How can I clarify this: the decision was not to "exclude"
MN triggering, the decision was to exclude layer 3 signalling
from the MN as part of CTP.

There needs to be a trigger event (this I believe we all also
agreed upon). Some of us believe that the most effective source
for this trigger event is from the link layer (this is the only
way you can actually be proactive, as far as I know). However,
there should not be any design restriction in CTP preventing this
trigger event from being generated from a different source, and
signalled via IP.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, June 15, 2001 1:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication &
> Authorization ...
>
>
>
> Hello Gary,
>
>
> Gary Kenward wrote:
>
> >
> >
> > Kulwinder:
> >
> >   I don't agree with your observation. We did discuss how
> CT was to be
> >
> > initiated, and agreed that there would be no explicit
> signalling from
> > the MN (not at least as far as CT was concerned).
> >
>
> Rajeev: I don't believe that we ever said there would be no explicit
> signaling from the MN!
> In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives
> the option to the MN to indicate how the feature contexts be handled.
>
> I would have strong objection to this.
>
>
> >
> >   The definition of reactive CT (read the problem
> statement)has to do
> > with
> > the order/timing of events, not with where the initiating
> event comes
> > from.
>
> Rajeev: I don't remember going through reactive CT or proactive CT
> during problem statement phase at all. Nevertheless, where is the
> definition of reactive CT that says a MN cannot initiate signaling ?
>
> Regards,
>
> -Rajeev
>
>
> >
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > Sent: Thursday, June 14, 2001 6:30 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat
> > > Calhoun'; Phillip
> > > Neumiller
> > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem statement
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > Sent: Thursday, June 14, 2001 6:02 PM
> > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat
> > > > Calhoun'; Phillip
> > > > Neumiller
> > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > > Sent: Thursday, June 14, 2001 4:46 PM
> > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller
> > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> > > > wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > > Sent: Thursday, June 14, 2001 5:09 PM
> > > > > To: 'Pat Calhoun'; Phillip Neumiller
> > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins;
> > > > Kulwinder
> > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > Sent: Wednesday, June 13, 2001 8:29 AM
> > > > > To: Phillip Neumiller
> > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross;
> > Charlie
> > > > > Perkins; Kulwinder Atwal; 'seamoby';
> > > > > wirelessinternet@internet.motlabs.com
> > > > > Subject: Re: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller
> > wrote:
> > > > > > There are companies that build products (WRQ's reflection
> > comes
> > > > > > to mind) that freeze the state of the IP stack
> (gracefully in
> > > > > > the application sense), until the flow of IP traffic can
> > resume.
> > > > > > This is sort of an ultra-slow handover.  I see no
> > > reason why THIS
> > > > > > can not be made seamless with CT.  Why should CT not be
> > capable
> > > > > > of accomodating this Pat?
> > > > >
> > > > > Sure, they could, but what is seamless in this sense? The user
> > has
> > > > > no service for some time, so what is an extra couple of
> > > > seconds while
> > > > > signalling occurs over the air to update the local ARs state??
> > The
> > > > > user would probably not even notice.
> > > > >
> > > > > Actually, you seem to imply something that I am not sure that
> > I've
> > > > > been thinking about that much, which is the mobile
> updating the
> > > > > AR's state. This, btw, can be problematic, since the
> > > mobile doesn't
> > > > > necessarily share an SA with the AR (hence DoS attacks), and a
> > > > > malicious mobile could send bogus (mal-formed) CT
> packets in an
> > > > > attempt to crash (or cause mis-behaving) ARs.
> > > > >
> > > > > Something to think about in the DoS space.
> > > > >
> > > > > MN>> Yes, involving the MN is CT is definitely a whole other
> > > > > ball of wax. As I said earlier the assumption was that the
> > > > CT happens
> > > > > AR to AR and I was exploring the DoSs for that case.
> > > >
> > > >
> > > > > The MN is not authenticated to the newAR, so all kinds of
> > security
> > > > > problems exists until the MN is "properly introduced" to
> > > the newAR.
> > > >
> > > > What do you mean "properly introduced" to the newAR.  The MN
> > > > can certainly
> > > > authenticate to the newAR.  The MN can just show up at the
> > > new AR and
> > > > introduce itself.  It called "Reactive" Context Transfer.
> > > >
> > > > MN>>> Kulwinder, by "properly introduced", I meant to skip
> > > > the security
> > > > details between MN and newAR. Yes, MN can authenticate itself
> > > > to newAR but
> > > > not as part of CT, and for sure not before CT completition,
> > > > especially, if
> > > > the intention of CT was to transfer MN's
> > > > for-AAA-Security-needed context.
> > > >
> > > > I don't think reactive context transfer was meant to be
> > > > initiated by MN and
> > > > definitely not after "MN's introduction itself to newAR".
> > >
> > > Of course it was intended.  Read the Archive.  If the MN is
> > switching
> > > between wireless and wired, _as_stated_in_our_charter_, there
> > > is no other
> > > way other than MN initiated CT.
> > >
> > > What do you expect will happen when an MN loses connectivity
> > > between ARs and
> > > just shows up at the newAR?  Do you _really_ expect the
> > > End-User to drive
> > > back during Rush Hour to the oldAR and try again?
> > >
> > > > What does this
> > > > introduction mean in context of "context transfer" anyway. If
> > > > CT is supposed
> > > > to happen between ARs, where does this introduction come in?
> > > > Unless you are
> > > > talking about an L2 connectivity signal or even an L2
> > > > authentication (which
> > > > is not very fast!!!).
> > > > The scenario is an AR-AR CT, then an MN-newAR authentication
> > (proper
> > > > introduction)
> > > > based on transferred credential after CT is complete.
> > >
> > > How does the newAR even know that the MN has arrived if the
> > > MN does not
> > > annouce itself?  Why should the newAR waste time doing a CT
> > > for an MN that
> > > is not authorized?  Sounds like an opportunity for a DOS
> > > attack.  Authorize
> > > first.  Then do CT.  Especially for an MN that has arrived
> > > unannouced at the
> > > newAR due to a service disruption will moving between ARs.
> > >
> > > - Kulwinder.
> > >
> > > >
> > > > The preferred case, of course, is when the oldAR transfers
> > > > trust to the
> > > > newAR.
> > > >
> > > > MN>> Of course. That is why I mentioned "properly introduced"
> > > >
> > > > But, certainly we must consider the case of an MN just
> > > > showing up at the
> > > > newAR.  The newAR is then faced with finding out where the
> > > MN was last
> > > > attached and invalidating the oldSA.  The MN has to present a
> > > > credential to
> > > > the newAR that the oldAR will accept as valid.
> > > >
> > > > MN>> Yes, but that is not where CT helps, you are out of the
> > > > CT-is-an-optimization
> > > > territory. MN does a lot of negotiations for establishing
> > > the context
> > > > anyway.
> > > >
> > > > BTW, I just noticed that my initials and acronym for Mobile
> > > > Node are the
> > > > same :(
> > > > "MN>> means I am talking :)
> > > >
> > > > Madjid
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Madjid
> > > > >
> > > > > PatC
> > > > >
> > > >
> > >
>
>

------_=_NextPart_001_01C0F5CD.40C691F0-- From owner-seamoby@diameter.org Fri Jun 15 15:19: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 PAA24444 for ; Fri, 15 Jun 2001 15:19:12 -0400 (EDT) Received: (qmail 12608 invoked by alias); 15 Jun 2001 18:49:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12602 invoked by uid 200); 15 Jun 2001 18:49:35 -0000 Received: (qmail 12595 invoked from network); 15 Jun 2001 18:49:30 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:49:30 -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 LAA17486; Fri, 15 Jun 2001 11:59:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FIxb629681; Fri, 15 Jun 2001 11:59:37 -0700 X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdUqIcO1; Fri, 15 Jun 2001 11:59:36 PDT Message-ID: <3B2A5B19.656875C4@iprg.nokia.com> Date: Fri, 15 Jun 2001 11:59:37 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'Kulwinder Atwal'" , Gary Kenward , "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Ajoy, whereas use of link-layer triggers is very useful, it is not something we can rely upon to be present everywhere (as you correctly point out for Inter-technology handovers). I don't think we ever said we disallow link layer triggers. We must not say that that's our solution. At the IP layer, we need to define IP messages. I think we pretty much agree. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > I think it is possible to receive link layer trigger at the new > access router which can be used to initiate context transfer. > This will be mostly useful in case of some intra-technology > handovers. In case MN moves across different technologies, yes > some sort of MN trigger is useful. Having said that is it a > good idea to limit the scope of CT protocol? I think we > should allow both the options. > regards, > ajoy > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Friday, June 15, 2001 12:50 PM > To: 'Rajeev Koodli'; Gary Kenward > Cc: 'seamoby' > Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > I would strongly object as well. > > No MN involvement is technology specific and implementation specific. > > The End-User needs the ability to decide when to switch between different > link-layers: wireless and wired. There is NO way for the network to know > this is about to happen. > > Infact, there was much dicussion in support of this as a requirement. We > need to add some new text. > > - Kulwinder. > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Friday, June 15, 2001 1:30 PM > > To: Gary Kenward > > Cc: 'seamoby' > > Subject: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & > > Authorization ... > > > > > > > > Hello Gary, > > > > > > Gary Kenward wrote: > > > > > > > > > > > Kulwinder: > > > > > > I don't agree with your observation. We did discuss how > > CT was to be > > > > > > initiated, and agreed that there would be no explicit > > signalling from > > > the MN (not at least as far as CT was concerned). > > > > > > > Rajeev: I don't believe that we ever said there would be no explicit > > signaling from the MN! > > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives > > the option to the MN to indicate how the feature contexts be handled. > > > > I would have strong objection to this. > > > > > > > > > > The definition of reactive CT (read the problem > > statement)has to do > > > with > > > the order/timing of events, not with where the initiating > > event comes > > > from. > > > > Rajeev: I don't remember going through reactive CT or proactive CT > > during problem statement phase at all. Nevertheless, where is the > > definition of reactive CT that says a MN cannot initiate signaling ? > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > Sent: Thursday, June 14, 2001 6:30 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > > Calhoun'; Phillip > > > > > Neumiller > > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > > Kulwinder > > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > > To: Phillip Neumiller > > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > > Charlie > > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > > wirelessinternet@internet.motlabs.com > > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > > wrote: > > > > > > > There are companies that build products (WRQ's reflection > > > comes > > > > > > > to mind) that freeze the state of the IP stack > > (gracefully in > > > > > > > the application sense), until the flow of IP traffic can > > > resume. > > > > > > > This is sort of an ultra-slow handover. I see no > > > > reason why THIS > > > > > > > can not be made seamless with CT. Why should CT not be > > > capable > > > > > > > of accomodating this Pat? > > > > > > > > > > > > Sure, they could, but what is seamless in this sense? The user > > > has > > > > > > no service for some time, so what is an extra couple of > > > > > seconds while > > > > > > signalling occurs over the air to update the local ARs state?? > > > The > > > > > > user would probably not even notice. > > > > > > > > > > > > Actually, you seem to imply something that I am not sure that > > > I've > > > > > > been thinking about that much, which is the mobile > > updating the > > > > > > AR's state. This, btw, can be problematic, since the > > > > mobile doesn't > > > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > > > malicious mobile could send bogus (mal-formed) CT > > packets in an > > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > > ball of wax. As I said earlier the assumption was that the > > > > > CT happens > > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > > security > > > > > > problems exists until the MN is "properly introduced" to > > > > the newAR. > > > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > > can certainly > > > > > authenticate to the newAR. The MN can just show up at the > > > > new AR and > > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > > the security > > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > > to newAR but > > > > > not as part of CT, and for sure not before CT completition, > > > > > especially, if > > > > > the intention of CT was to transfer MN's > > > > > for-AAA-Security-needed context. > > > > > > > > > > I don't think reactive context transfer was meant to be > > > > > initiated by MN and > > > > > definitely not after "MN's introduction itself to newAR". > > > > > > > > Of course it was intended. Read the Archive. If the MN is > > > switching > > > > between wireless and wired, _as_stated_in_our_charter_, there > > > > is no other > > > > way other than MN initiated CT. > > > > > > > > What do you expect will happen when an MN loses connectivity > > > > between ARs and > > > > just shows up at the newAR? Do you _really_ expect the > > > > End-User to drive > > > > back during Rush Hour to the oldAR and try again? > > > > > > > > > What does this > > > > > introduction mean in context of "context transfer" anyway. If > > > > > CT is supposed > > > > > to happen between ARs, where does this introduction come in? > > > > > Unless you are > > > > > talking about an L2 connectivity signal or even an L2 > > > > > authentication (which > > > > > is not very fast!!!). > > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > > (proper > > > > > introduction) > > > > > based on transferred credential after CT is complete. > > > > > > > > How does the newAR even know that the MN has arrived if the > > > > MN does not > > > > annouce itself? Why should the newAR waste time doing a CT > > > > for an MN that > > > > is not authorized? Sounds like an opportunity for a DOS > > > > attack. Authorize > > > > first. Then do CT. Especially for an MN that has arrived > > > > unannouced at the > > > > newAR due to a service disruption will moving between ARs. > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > > trust to the > > > > > newAR. > > > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > > > But, certainly we must consider the case of an MN just > > > > > showing up at the > > > > > newAR. The newAR is then faced with finding out where the > > > > MN was last > > > > > attached and invalidating the oldSA. The MN has to present a > > > > > credential to > > > > > the newAR that the oldAR will accept as valid. > > > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > > CT-is-an-optimization > > > > > territory. MN does a lot of negotiations for establishing > > > > the context > > > > > anyway. > > > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > > Node are the > > > > > same :( > > > > > "MN>> means I am talking :) > > > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Fri Jun 15 15: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 PAA24764 for ; Fri, 15 Jun 2001 15:24:27 -0400 (EDT) Received: (qmail 12656 invoked by alias); 15 Jun 2001 18:50:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12649 invoked by uid 200); 15 Jun 2001 18:50:30 -0000 Received: (qmail 12642 invoked from network); 15 Jun 2001 18:50:26 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:50:26 -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 MAA17743; Fri, 15 Jun 2001 12:00:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FJ0Vm31648; Fri, 15 Jun 2001 12:00:31 -0700 X-mProtect: Fri, 15 Jun 2001 12:00:31 -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 smtpdhqXRh7; Fri, 15 Jun 2001 12:00:30 PDT Message-ID: <3B2A5B4E.CD286A70@iprg.nokia.com> Date: Fri, 15 Jun 2001 12:00:30 -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: Hamid Syed CC: "'seamoby'" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C1CD0E9@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid, > Hamid Syed wrote: > I guess we need to understand the boundaries of context transfer and the > actual handover. Yes, in fact I believe that maybe the word "handover" needs precise definition with respect to the process of context transfer (I was going to say "in the context of ..." but that would be bad :-). > The first two options you listed are handover scenarios where the decision is > made where the mobile is going to handover. I am confused how does it relates > to context transfer? I can easily imagine four cases: - Network initiated predictive context transfer - Network initiated reactive context transfer - Mobile initiated predictive context transfer - Mobile initiated reactive context transfer I am certain that all four cases can be handled by the same context transfer protocol messages. I am myself confused about how to answer your question, because it seems clear to me that these terms are in fact relevant to context transfer. > The predictive context transfer is the same as the proactive context transfer > where context is made available to the new AR before a handover of occurs. Agreed, except that I am suggesting the use of a different word. > Your reactive context transfer definition is more like a "break-before-make" > scenario. I do not know how context could be useful if the transfer happens > after the handover completion. I can think of very many examples. As one example, multicast group membership MIGHT be established at the new access router AFTER the basic handover. But I also want to clearly distinguish betwen "reactive" and "break-before-make". These is not at all the same things. The latter is pretty much confined to discussion below layer-3, at least for connectionless protocols like IP. The former only just has to do with when the context transfer can get started. Just as one example, of probably dozens, what if the context transfer request started immediately after link-establishment in a make-before-break system? This could easily happen, and in cooperation with Mobile IP or stateless address autoconfiguration it might reduce the amount of time for the mobile node to get situated on the new network. In fact, with make-before-break, maybe one would always want to use reactive context transfer instead of predictive. With make-before-break, there's nothing left to predict! > What will happen to the traffic which has > already been handed over to the AR and the context processing is not yet done? > particularly with the contexyt information that is calculated on a per packet > arrival basis. You probably have a specific case in mind, that I can't exactly guess at. However, in general, the way that traffic is handled with incomplete context transfer is going to be a problem, regardless of whether the transfer is requested predictively or reactively. > For example metering?. How metering context could be useful if > the meter value at the new AR has already passed. Here I am lost. What does it mean for a meter value to be passed? Why does it matter whether the new access router or the previous access router is running the meter? > I believe the reactive > context transfer is also a make-before-break scenario with context transfer > and the handover should occur simulataneously. Ofcourse, context has to reach > the new AR before it becomes useless there. I'm sort-of lost here, too, unfortunately. I am sure we can agree that context information sometimes has freshness requirements, but I don't see how predictive vs. reactive affects that statement. Of course, with predictive transfers, it will be easier to meet the freshness requirement. Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 15:28: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 PAA24960 for ; Fri, 15 Jun 2001 15:28:01 -0400 (EDT) Received: (qmail 12922 invoked by alias); 15 Jun 2001 18:59:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12916 invoked by uid 200); 15 Jun 2001 18:59:09 -0000 Received: (qmail 12907 invoked from network); 15 Jun 2001 18:59:04 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 18:59:04 -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 MAA18287; Fri, 15 Jun 2001 12:09:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FJ93E07821; Fri, 15 Jun 2001 12:09:03 -0700 X-mProtect: Fri, 15 Jun 2001 12:09:03 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdGWMSzq; Fri, 15 Jun 2001 12:09:02 PDT Message-ID: <3B2A5D4D.CC80ED85@iprg.nokia.com> Date: Fri, 15 Jun 2001 12:09:01 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: "Charles E. Perkins" , Gary Kenward , "'seamoby'" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> <3B2A4FCF.ABB497A@iprg.nokia.com> <20010615111715.X17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > Charlie, > > Based on your comment below, it doesn't sounds like you are stating that > a CT MN->AR message is needed, but rather that a L2 trigger that would > cause CT MAY be generated by the mobile. > > Rajeev: I am sorry, I don't know how we can say that we can rely on a L2 trigger from the MN to cause CT. This could work on some links but not on others. It has got to be an IP message, for us. > If this is true, then I believe that we are *all* in agreement, and if > so, may I ask what in the spec could be changed to reflect this agreement? > > PatC > On Fri, Jun 15, 2001 at 11:11:27AM -0700, Charles E. Perkins wrote: > > > > Hello Gary, > > > > > Gary Kenward wrote: > > > > > For us, it is unacceptable that CT should be dependent upon > > > some layer 3 messaging from the MN. Over the air transit latencies > > > are just too great, and we don' see the value. I think here we > > > simply must agree that we have different views of the world. > > > > Maybe we're not so far apart after all. Of course I agree that > > we should have the possibility to do context transfer without > > requiring the mobile node to trigger the process. I'm just > > holding out for the possibility that the mobile node CAN trigger > > the process in some circumstances. For instance, it would probably > > be just fine over 802.11, even if it's not advisable over some > > cellular media. > > > > > This whole issue was discussed at great length, and it was > > > clear then that there was no "right" approach. We decided then > > > that we would abstract out the initiating event - some called > > > it a trigger - and that would allow for different networks and > > > different vendors to define the approach they like the best. > > > > Exactly. Thus, I claim we aren't so far apart. But, some of the > > allowable choices should include allowing the mobile node to > > initiate the process of context transfer. > > > > > Who triggers context transfer is not relevant, unless we believe > > > we are going to build the trigger into CTP as a signalling message. > > > There was a long debate, and it was decided very early on that > > > it was not necessary to build this into CTP. That does not > > > mean that this approach is excluded from the mobility solution, nor > > > does it mean that an MN message could not trigger CT indirectly. It > > > simply means that CTP will not include an MN to AR message. > > > > Again, just because context transfer CAN be accomplished without > > a trigger from the mobile node in SOME circumstances, does not mean > > that the mobile node should be disallowed from supplying the trigger > > in OTHER circumstances. Thus, I agree with the second and third > > sentences, but it seems pretty clear that we can ALLOW such a > > trigger indication without dragging down the rest of the protocol. > > Thus I am asking for reconsideration of the 4th sentence, and I > > don't see any downside at all. > > > > > You can refer to the archives if you question this, in particular, > > > the conference call meeting minutes. > > > > That's raising the bar pretty high for my participation in this > > particular discussion. Would it be O.K. to ask that you respond > > just to my points in this e-mail? > > > > > What you are proposing is to return to the discussions of six months ago. > > > This would be unacceptable to me, for sure, and I suspect others engaged > > > with this process would also be very frustrated. > > > > Well, from the e-mail I've seen so far, it looks like there may be > > frustrations on both sides. Moreover, to accomodate those who wish > > to allow mobile-node triggering, I don't think would cause any > > discomfort to those who want to have network-initiated transfers. > > So why not? > > > > Regards, > > Charlie P. From owner-seamoby@diameter.org Fri Jun 15 15:39: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 PAA25568 for ; Fri, 15 Jun 2001 15:38:43 -0400 (EDT) Received: (qmail 14053 invoked by alias); 15 Jun 2001 19:15:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14045 invoked by uid 200); 15 Jun 2001 19:15:57 -0000 Received: (qmail 14028 invoked from network); 15 Jun 2001 19:15:51 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 19:15:51 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 15:26:00 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F7FFE@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Gary Kenward'" , "'Rajeev Koodli'" Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Fri, 15 Jun 2001 15:25:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5D0.FE0BC200" 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_01C0F5D0.FE0BC200 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, June 15, 2001 2:59 PM To: 'Rajeev Koodli' Cc: 'seamoby' Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... How can I clarify this: the decision was not to "exclude" MN triggering, the decision was to exclude layer 3 signalling from the MN as part of CTP. There needs to be a trigger event (this I believe we all also agreed upon). Some of us believe that the most effective source for this trigger event is from the link layer (this is the only way you can actually be proactive, as far as I know). With an inter-technology Context Transfer it will most likely be the MN that is aware of which ARs are: - Nearby - Of a compatible technology type (wired LAN, wireless, ...) - Preferred and, are likey to permit authorization. The MN (End-User) needs a way to send a packet to the current AR to initiate CT. Consider a device used as a cordless phone at home and as a cell outside of the home. -Kulwinder. However, there should not be any design restriction in CTP preventing this trigger event from being generated from a different source, and signalled via IP. Gary > -----Original Message----- > From: Rajeev Koodli [ mailto:rajeev@iprg.nokia.com ] > Sent: Friday, June 15, 2001 1:30 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > Authorization ... > > > > Hello Gary, > > > Gary Kenward wrote: > > > > > > > Kulwinder: > > > > I don't agree with your observation. We did discuss how > CT was to be > > > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > > > Rajeev: I don't believe that we ever said there would be no explicit > signaling from the MN! > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives > the option to the MN to indicate how the feature contexts be handled. > > I would have strong objection to this. > > > > > > The definition of reactive CT (read the problem > statement)has to do > > with > > the order/timing of events, not with where the initiating > event comes > > from. > > Rajeev: I don't remember going through reactive CT or proactive CT > during problem statement phase at all. Nevertheless, where is the > definition of reactive CT that says a MN cannot initiate signaling ? > > Regards, > > -Rajeev > > > > > > > > Gary > > > > > -----Original Message----- > > > From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com ] > > > Sent: Thursday, June 14, 2001 6:30 PM > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > Calhoun'; Phillip > > > Neumiller > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > "in-the-large" > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [ mailto:Madjid.Nakhjiri@motorola.com ] > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com ] > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [ mailto:Madjid.Nakhjiri@motorola.com ] > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > Kulwinder > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun [ mailto:pcalhoun@diameter.org ] > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > To: Phillip Neumiller > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > Charlie > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > wrote: > > > > > > There are companies that build products (WRQ's reflection > > comes > > > > > > to mind) that freeze the state of the IP stack > (gracefully in > > > > > > the application sense), until the flow of IP traffic can > > resume. > > > > > > This is sort of an ultra-slow handover. I see no > > > reason why THIS > > > > > > can not be made seamless with CT. Why should CT not be > > capable > > > > > > of accomodating this Pat? > > > > > > > > > > Sure, they could, but what is seamless in this sense? The user > > has > > > > > no service for some time, so what is an extra couple of > > > > seconds while > > > > > signalling occurs over the air to update the local ARs state?? > > The > > > > > user would probably not even notice. > > > > > > > > > > Actually, you seem to imply something that I am not sure that > > I've > > > > > been thinking about that much, which is the mobile > updating the > > > > > AR's state. This, btw, can be problematic, since the > > > mobile doesn't > > > > > necessarily share an SA with the AR (hence DoS attacks), and a > > > > > malicious mobile could send bogus (mal-formed) CT > packets in an > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > ball of wax. As I said earlier the assumption was that the > > > > CT happens > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > security > > > > > problems exists until the MN is "properly introduced" to > > > the newAR. > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > can certainly > > > > authenticate to the newAR. The MN can just show up at the > > > new AR and > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > the security > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > to newAR but > > > > not as part of CT, and for sure not before CT completition, > > > > especially, if > > > > the intention of CT was to transfer MN's > > > > for-AAA-Security-needed context. > > > > > > > > I don't think reactive context transfer was meant to be > > > > initiated by MN and > > > > definitely not after "MN's introduction itself to newAR". > > > > > > Of course it was intended. Read the Archive. If the MN is > > switching > > > between wireless and wired, _as_stated_in_our_charter_, there > > > is no other > > > way other than MN initiated CT. > > > > > > What do you expect will happen when an MN loses connectivity > > > between ARs and > > > just shows up at the newAR? Do you _really_ expect the > > > End-User to drive > > > back during Rush Hour to the oldAR and try again? > > > > > > > What does this > > > > introduction mean in context of "context transfer" anyway. If > > > > CT is supposed > > > > to happen between ARs, where does this introduction come in? > > > > Unless you are > > > > talking about an L2 connectivity signal or even an L2 > > > > authentication (which > > > > is not very fast!!!). > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > (proper > > > > introduction) > > > > based on transferred credential after CT is complete. > > > > > > How does the newAR even know that the MN has arrived if the > > > MN does not > > > annouce itself? Why should the newAR waste time doing a CT > > > for an MN that > > > is not authorized? Sounds like an opportunity for a DOS > > > attack. Authorize > > > first. Then do CT. Especially for an MN that has arrived > > > unannouced at the > > > newAR due to a service disruption will moving between ARs. > > > > > > - Kulwinder. > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > trust to the > > > > newAR. > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > But, certainly we must consider the case of an MN just > > > > showing up at the > > > > newAR. The newAR is then faced with finding out where the > > > MN was last > > > > attached and invalidating the oldSA. The MN has to present a > > > > credential to > > > > the newAR that the oldAR will accept as valid. > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > CT-is-an-optimization > > > > territory. MN does a lot of negotiations for establishing > > > the context > > > > anyway. > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > Node are the > > > > same :( > > > > "MN>> means I am talking :) > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > PatC > > > > > > > > > > > > > > ------_=_NextPart_001_01C0F5D0.FE0BC200 Content-Type: text/html; charset="iso-8859-1" RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, June 15, 2001 2:59 PM
To: 'Rajeev Koodli'
Cc: 'seamoby'
Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...

How can I clarify this: the decision was not to "exclude"
MN triggering, the decision was to exclude layer 3 signalling
from the MN as part of CTP.

There needs to be a trigger event (this I believe we all also
agreed upon). Some of us believe that the most effective source
for this trigger event is from the link layer (this is the only
way you can actually be proactive, as far as I know). 

With an inter-technology Context Transfer it will most likely be the MN that is aware of which ARs are:

- Nearby

- Of a compatible technology type (wired LAN, wireless, ...)

- Preferred

and, are likey to permit authorization.

The MN (End-User) needs a way to send a packet to the current AR to initiate CT. 

Consider a device used as a cordless phone at home and as a cell outside of the home.

-Kulwinder.

 

  However,
there should not be any design restriction in CTP preventing this
trigger event from being generated from a different source, and
signalled via IP.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, June 15, 2001 1:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication &
> Authorization ...
>
>
>
> Hello Gary,
>
>
> Gary Kenward wrote:
>
> >
> >
> > Kulwinder:
> >
> >   I don't agree with your observation. We did discuss how
> CT was to be
> >
> > initiated, and agreed that there would be no explicit
> signalling from
> > the MN (not at least as far as CT was concerned).
> >
>
> Rajeev: I don't believe that we ever said there would be no explicit
> signaling from the MN!
> In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives
> the option to the MN to indicate how the feature contexts be handled.
>
> I would have strong objection to this.
>
>
> >
> >   The definition of reactive CT (read the problem
> statement)has to do
> > with
> > the order/timing of events, not with where the initiating
> event comes
> > from.
>
> Rajeev: I don't remember going through reactive CT or proactive CT
> during problem statement phase at all. Nevertheless, where is the
> definition of reactive CT that says a MN cannot initiate signaling ?
>
> Regards,
>
> -Rajeev
>
>
> >
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > Sent: Thursday, June 14, 2001 6:30 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat
> > > Calhoun'; Phillip
> > > Neumiller
> > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem statement
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > Sent: Thursday, June 14, 2001 6:02 PM
> > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat
> > > > Calhoun'; Phillip
> > > > Neumiller
> > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > > Sent: Thursday, June 14, 2001 4:46 PM
> > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller
> > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> > > > wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > > Sent: Thursday, June 14, 2001 5:09 PM
> > > > > To: 'Pat Calhoun'; Phillip Neumiller
> > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins;
> > > > Kulwinder
> > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > Sent: Wednesday, June 13, 2001 8:29 AM
> > > > > To: Phillip Neumiller
> > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross;
> > Charlie
> > > > > Perkins; Kulwinder Atwal; 'seamoby';
> > > > > wirelessinternet@internet.motlabs.com
> > > > > Subject: Re: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller
> > wrote:
> > > > > > There are companies that build products (WRQ's reflection
> > comes
> > > > > > to mind) that freeze the state of the IP stack
> (gracefully in
> > > > > > the application sense), until the flow of IP traffic can
> > resume.
> > > > > > This is sort of an ultra-slow handover.  I see no
> > > reason why THIS
> > > > > > can not be made seamless with CT.  Why should CT not be
> > capable
> > > > > > of accomodating this Pat?
> > > > >
> > > > > Sure, they could, but what is seamless in this sense? The user
> > has
> > > > > no service for some time, so what is an extra couple of
> > > > seconds while
> > > > > signalling occurs over the air to update the local ARs state??
> > The
> > > > > user would probably not even notice.
> > > > >
> > > > > Actually, you seem to imply something that I am not sure that
> > I've
> > > > > been thinking about that much, which is the mobile
> updating the
> > > > > AR's state. This, btw, can be problematic, since the
> > > mobile doesn't
> > > > > necessarily share an SA with the AR (hence DoS attacks), and a
> > > > > malicious mobile could send bogus (mal-formed) CT
> packets in an
> > > > > attempt to crash (or cause mis-behaving) ARs.
> > > > >
> > > > > Something to think about in the DoS space.
> > > > >
> > > > > MN>> Yes, involving the MN is CT is definitely a whole other
> > > > > ball of wax. As I said earlier the assumption was that the
> > > > CT happens
> > > > > AR to AR and I was exploring the DoSs for that case.
> > > >
> > > >
> > > > > The MN is not authenticated to the newAR, so all kinds of
> > security
> > > > > problems exists until the MN is "properly introduced" to
> > > the newAR.
> > > >
> > > > What do you mean "properly introduced" to the newAR.  The MN
> > > > can certainly
> > > > authenticate to the newAR.  The MN can just show up at the
> > > new AR and
> > > > introduce itself.  It called "Reactive" Context Transfer.
> > > >
> > > > MN>>> Kulwinder, by "properly introduced", I meant to skip
> > > > the security
> > > > details between MN and newAR. Yes, MN can authenticate itself
> > > > to newAR but
> > > > not as part of CT, and for sure not before CT completition,
> > > > especially, if
> > > > the intention of CT was to transfer MN's
> > > > for-AAA-Security-needed context.
> > > >
> > > > I don't think reactive context transfer was meant to be
> > > > initiated by MN and
> > > > definitely not after "MN's introduction itself to newAR".
> > >
> > > Of course it was intended.  Read the Archive.  If the MN is
> > switching
> > > between wireless and wired, _as_stated_in_our_charter_, there
> > > is no other
> > > way other than MN initiated CT.
> > >
> > > What do you expect will happen when an MN loses connectivity
> > > between ARs and
> > > just shows up at the newAR?  Do you _really_ expect the
> > > End-User to drive
> > > back during Rush Hour to the oldAR and try again?
> > >
> > > > What does this
> > > > introduction mean in context of "context transfer" anyway. If
> > > > CT is supposed
> > > > to happen between ARs, where does this introduction come in?
> > > > Unless you are
> > > > talking about an L2 connectivity signal or even an L2
> > > > authentication (which
> > > > is not very fast!!!).
> > > > The scenario is an AR-AR CT, then an MN-newAR authentication
> > (proper
> > > > introduction)
> > > > based on transferred credential after CT is complete.
> > >
> > > How does the newAR even know that the MN has arrived if the
> > > MN does not
> > > annouce itself?  Why should the newAR waste time doing a CT
> > > for an MN that
> > > is not authorized?  Sounds like an opportunity for a DOS
> > > attack.  Authorize
> > > first.  Then do CT.  Especially for an MN that has arrived
> > > unannouced at the
> > > newAR due to a service disruption will moving between ARs.
> > >
> > > - Kulwinder.
> > >
> > > >
> > > > The preferred case, of course, is when the oldAR transfers
> > > > trust to the
> > > > newAR.
> > > >
> > > > MN>> Of course. That is why I mentioned "properly introduced"
> > > >
> > > > But, certainly we must consider the case of an MN just
> > > > showing up at the
> > > > newAR.  The newAR is then faced with finding out where the
> > > MN was last
> > > > attached and invalidating the oldSA.  The MN has to present a
> > > > credential to
> > > > the newAR that the oldAR will accept as valid.
> > > >
> > > > MN>> Yes, but that is not where CT helps, you are out of the
> > > > CT-is-an-optimization
> > > > territory. MN does a lot of negotiations for establishing
> > > the context
> > > > anyway.
> > > >
> > > > BTW, I just noticed that my initials and acronym for Mobile
> > > > Node are the
> > > > same :(
> > > > "MN>> means I am talking :)
> > > >
> > > > Madjid
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Madjid
> > > > >
> > > > > PatC
> > > > >
> > > >
> > >
>
>

------_=_NextPart_001_01C0F5D0.FE0BC200-- From owner-seamoby@diameter.org Fri Jun 15 15:50: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 PAA26315 for ; Fri, 15 Jun 2001 15:50:13 -0400 (EDT) Received: (qmail 15038 invoked by alias); 15 Jun 2001 19:36:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15031 invoked by uid 200); 15 Jun 2001 19:36:07 -0000 Received: (qmail 15020 invoked from network); 15 Jun 2001 19:36:01 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 19:36:01 -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 MAA20855; Fri, 15 Jun 2001 12:44:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FJi5b11206; Fri, 15 Jun 2001 12:44:05 -0700 X-mProtect: Fri, 15 Jun 2001 12:44:05 -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 smtpdrJ3Aei; Fri, 15 Jun 2001 12:44:04 PDT Message-ID: <3B2A6585.23082902@iprg.nokia.com> Date: Fri, 15 Jun 2001 12:44:05 -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: Pat Calhoun CC: Rajeev Koodli , Gary Kenward , "'seamoby'" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> <3B2A4FCF.ABB497A@iprg.nokia.com> <20010615111715.X17928@charizard.diameter.org> <3B2A5D4D.CC80ED85@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pat, Apparently, > Pat Calhoun wrote: .... something! and, then .... > If this is true, then I believe that we are *all* in agreement, and if > so, may I ask what in the spec could be changed to reflect this agreement? > > PatC I see that you have sent some e-mail on this subject, and I reckon I am in agreement with you, but I didn't see your original e-mail. Maybe it's stuck on some spool somewhere funny. I got this from Rajeev's reply. Just to be clear, I think there should be an _optional_ network-layer (or above) message to trigger context transfer, which can be sent by the mobile node in cases where deemed necessary. Of course, for systems which support a layer-2 trigger (and the necessary inter-module communication), the layer-3 message might be unnecessary. Pointing out the obvious, for systems that don't need the layer-3 trigger, the information that it would have provided needs to be sent within some part of the network-initiated control messages. Of course we don't know what information is involved yet, but it would presumably have to do with identifying the appropriate microflows for which context needs to be transferred, along with information about how to verify that the appropriate mobile node is targetted to receive the part of the context information that it might need (e.g. for header compression). Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 16:25:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28224 for ; Fri, 15 Jun 2001 16:25:42 -0400 (EDT) Received: (qmail 15974 invoked by alias); 15 Jun 2001 20:10:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15968 invoked by uid 200); 15 Jun 2001 20:10:49 -0000 Received: (qmail 15963 invoked from network); 15 Jun 2001 20:10:47 -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; 15 Jun 2001 20:10:47 -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 f5FKKk012022 for ; Fri, 15 Jun 2001 16:20:46 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Jun 2001 16:20:41 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 16:20:42 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D33@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Kulwinder Atwal'" , "'Charles E. Perkins'" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 16:20:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5D8.A66FA6D0" 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_01C0F5D8.A66FA6D0 Content-Type: text/plain; charset="iso-8859-1" Actually, it turns out that consensus cannot be determined at the dt level, only at the wg level - which requires Pat. Based upon this, every "decision" made during the last six months can be re-opened. I hope Pat has lot's of energy. Gary -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Friday, June 15, 2001 2:26 PM To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: [seamoby] Reactive context transfer -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Friday, June 15, 2001 1:58 PM To: 'Charles E. Perkins' Cc: 'seamoby' Subject: RE: [seamoby] Reactive context transfer Charlie: For us, it is unacceptable that CT should be dependent upon some layer 3 messaging from the MN. Over the air transit latencies are just too great, and we don' see the value. I think here we simply must agree that we have different views of the world. This is implementation specific. This whole issue was discussed at great length, and it was clear then that there was no "right" approach. We decided then that we would abstract out the initiating event - some called it a trigger - and that would allow for different networks and different vendors to define the approach they like the best. Since I was the one who proposed triggers. My recollection is quite different. The intent was that we would not know where the trigger packet came from, but at no time did I ever suggest it was out of scope. In fact, I explicitly stated that it could be MN or Network initiated as did Vijay. Who triggers context transfer is not relevant, unless we believe we are going to build the trigger into CTP as a signalling message. There was a long debate, and it was decided very early on that it was not necessary to build this into CTP. That does not mean that this approach is excluded from the mobility solution, nor does it mean that an MN message could not trigger CT indirectly. It simply means that CTP will not include an MN to AR message. You can refer to the archives if you question this, in particular, the conference call meeting minutes. IETF rules do not allow concensus from meetings. ONLY mailing lists concenus is valid. At the moment, I would suggest strongly that we retain that decision. It allows both camps to work on their preferred solution. More importantly, it would allow us to move forward. We cannot move forward until this is resolved. - Kulwinder. What you are proposing is to return to the discussions of six months ago. This would be unacceptable to me, for sure, and I suspect others engaged with this process would also be very frustrated. Gary > -----Original Message----- > From: Charles E. Perkins [ mailto:charliep@IPRG.nokia.com ] > Sent: Friday, June 15, 2001 1:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: [seamoby] Reactive context transfer > > > > Hello Gary, > > > Gary Kenward wrote: > > > ....... We did discuss how CT was to be > > initiated, and agreed that there would be no explicit > signalling from > > the MN (not at least as far as CT was concerned). > > I would consider this as wholly unacceptable, except that in your > next paragraph you state: > > > The definition of reactive CT (read the problem > statement)has to do with > > the order/timing of events, not with where the initiating > event comes from. > > So then I started to wonder about how one might define "reactive" to > make the previous sentence come true. But, the word "reactive" does > not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt. > No help there. I did find some redefinition of "reactive" in > draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe, > not the result of design team discussions. In fact, I have some > other comments on the latter document, but for now I would just like > to suggest that it should not be taken as relevant to the current > discussion about reactive context transfers. > > That puts me back to square one. From that standpoint, I would like > to suggest that the context transfer problem statement needs to > very clearly define the following concepts: > > - Network-initiated context transfer, for which the access network > tells the mobile where to go > > - Mobile-initiated context transfer, for which the mobile tells the > network where it wants to go > > - Predictive context transfer, for which either the mobile or the > network initiates context transfer BEFORE leaving the previous > access router > > - Reactive context transfer, for which either the mobile or > the network > initiates context transfer AFTER the mobile arrives (establishes > a link) at the new access router. > > > I like the word "predictive" for several reasons: > > - It has exactly the right meaning, and even connotes that caution > is necessary because not all predictions come true > > - In contrast to some other alternatives one often hears, it is > a word that one can find in the dictionary. > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F5D8.A66FA6D0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer
Actually, it turns out that consensus cannot be determined at the dt
level, only at the wg level - which requires Pat.
 
Based upon this, every "decision" made during the last six months can
be re-opened. I hope Pat has lot's of energy.
 
Gary
-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Friday, June 15, 2001 2:26 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: [seamoby] Reactive context transfer

 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, June 15, 2001 1:58 PM
To: 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: [seamoby] Reactive context transfer

Charlie:

 For us, it is unacceptable that CT should be dependent upon
some layer 3 messaging from the MN. Over the air transit latencies
are just too great, and we don' see the value. I think here we
simply must agree that we have different views of the world.  

This is implementation specific. 

 This whole issue was discussed at great length, and it was
clear then that there was no "right" approach. We decided then
that we would abstract out the initiating event - some called
it a trigger - and that would allow for different networks and
different vendors to define the approach they like the best.  

Since I was the one who proposed triggers.  My recollection is quite different.

The intent was that we would not know where the trigger packet came from, but at no time did I ever suggest it was out of scope.

In fact, I explicitly stated that it could be MN or Network initiated as did Vijay. 

 Who triggers context transfer is not relevant, unless we believe
we are going to build the trigger into CTP as a signalling message.
There was a long debate, and it was decided very early on that
it was not necessary to build this into CTP. That does not
mean that this approach is excluded from the mobility solution, nor
does it mean that an MN message could not trigger CT indirectly. It
simply means that CTP will not include an MN to AR message.

 You can refer to the archives if you question this, in particular,
the conference call meeting minutes.  

IETF rules do not allow concensus from meetings.  ONLY mailing lists concenus is valid. 

 At the moment, I would suggest strongly that we retain that decision.
It allows both camps to work on their preferred solution. More importantly,
it would allow us to move forward. 

We cannot move forward until this is resolved.

- Kulwinder. 

 What you are proposing is to return to the discussions of six months ago.
This would be unacceptable to me, for sure, and I suspect others engaged
with this process would also be very frustrated.

Gary


> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: [seamoby] Reactive context transfer
>
>
>
> Hello Gary,
>
> > Gary Kenward wrote:
>
> >        .......                   We did discuss how CT was to be
> > initiated, and agreed that there would be no explicit
> signalling from
> > the MN (not at least as far as CT was concerned).
>
> I would consider this as wholly unacceptable, except that in your
> next paragraph you state:
>
> >   The definition of reactive CT (read the problem
> statement)has to do with
> > the order/timing of events, not with where the initiating
> event comes from.
>
> So then I started to wonder about how one might define "reactive" to
> make the previous sentence come true.  But, the word "reactive" does
> not occur in draft-ietf-seamoby-context-transfer-problem-stat-01.txt.
> No help there.  I did find some redefinition of "reactive" in
> draft-hamid-seamoby-ct-fwk-00.txt, but that document was, I believe,
> not the result of design team discussions.  In fact, I have some
> other comments on the latter document, but for now I would just like
> to suggest that it should not be taken as relevant to the current
> discussion about reactive context transfers.
>
> That puts me back to square one.  From that standpoint, I would like
> to suggest that the context transfer problem statement needs to
> very clearly define the following concepts:
>
> - Network-initiated context transfer, for which the access network
>   tells the mobile where to go
>
> - Mobile-initiated context transfer, for which the mobile tells the
>   network where it wants to go
>
> - Predictive context transfer, for which either the mobile or the
>   network initiates context transfer BEFORE leaving the previous
>   access router
>
> - Reactive context transfer, for which either the mobile or
> the network
>   initiates context transfer AFTER the mobile arrives (establishes
>   a link) at the new access router.
>
>
> I like the word "predictive" for several reasons:
>
> - It has exactly the right meaning, and even connotes that caution
>   is necessary because not all predictions come true
>
> - In contrast to some other alternatives one often hears, it is
>   a word that one can find in the dictionary.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F5D8.A66FA6D0-- From owner-seamoby@diameter.org Fri Jun 15 16:34:55 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 QAA28677 for ; Fri, 15 Jun 2001 16:34:40 -0400 (EDT) Received: (qmail 16255 invoked by alias); 15 Jun 2001 20:16:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16248 invoked by uid 200); 15 Jun 2001 20:16:15 -0000 Received: (qmail 16237 invoked from network); 15 Jun 2001 20:16:10 -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; 15 Jun 2001 20:16:10 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FKQ4014471 for ; Fri, 15 Jun 2001 16:26:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 15 Jun 2001 16:26:03 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 16:26:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D35@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , "Hamid Syed" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 16:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5D9.64EB6270" 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_01C0F5D9.64EB6270 Content-Type: text/plain; charset="iso-8859-1" Charlie: Will the mobile actually initiate a ct or will it initiate a handover? Or are you expecting to do both? Do you expect to complete MN initiated CT in less then 60ms? If not, how will ct in this context provide seamless handover for VoIP? Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 3:01 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: 'seamoby' > Subject: Re: [seamoby] Reactive context transfer > > > > Hello Hamid, > > > Hamid Syed wrote: > > > I guess we need to understand the boundaries of context > transfer and the > > actual handover. > > Yes, in fact I believe that maybe the word "handover" needs precise > definition with respect to the process of context transfer (I > was going > to say "in the context of ..." but that would be bad :-). > > > The first two options you listed are handover scenarios > where the decision is > > made where the mobile is going to handover. I am confused > how does it relates > > to context transfer? > > I can easily imagine four cases: > - Network initiated predictive context transfer > - Network initiated reactive context transfer > - Mobile initiated predictive context transfer > - Mobile initiated reactive context transfer > > I am certain that all four cases can be handled by the same > context transfer protocol messages. > > I am myself confused about how to answer your question, > because it seems > clear to me that these terms are in fact relevant to context transfer. > > > The predictive context transfer is the same as the > proactive context transfer > > where context is made available to the new AR before a > handover of occurs. > > Agreed, except that I am suggesting the use of a different word. > > > Your reactive context transfer definition is more like a > "break-before-make" > > scenario. I do not know how context could be useful if the > transfer happens > > after the handover completion. > > I can think of very many examples. As one example, multicast group > membership MIGHT be established at the new access router AFTER the > basic handover. > > But I also want to clearly distinguish betwen "reactive" and > "break-before-make". > These is not at all the same things. The latter is pretty > much confined > to discussion below layer-3, at least for connectionless > protocols like IP. > The former only just has to do with when the context transfer can get > started. > > Just as one example, of probably dozens, what if the context transfer > request started immediately after link-establishment in a > make-before-break > system? This could easily happen, and in cooperation with > Mobile IP or > stateless address autoconfiguration it might reduce the amount of time > for the mobile node to get situated on the new network. > > In fact, with make-before-break, maybe one would always want > to use reactive context transfer instead of predictive. > With make-before-break, there's nothing left to predict! > > > What will happen to the > traffic which has > > already been handed over to the AR and the context > processing is not yet done? > > particularly with the contexyt information that is > calculated on a per packet > > arrival basis. > > You probably have a specific case in mind, that I can't > exactly guess at. > However, in general, the way that traffic is handled with > incomplete context > transfer is going to be a problem, regardless of whether the > transfer is > requested predictively or reactively. > > > For example metering?. How metering > context could be useful if > > the meter value at the new AR has already passed. > > Here I am lost. What does it mean for a meter value to be passed? > > Why does it matter whether the new access router or the > previous access > router is running the meter? > > > I believe > the reactive > > context transfer is also a make-before-break scenario with > context transfer > > and the handover should occur simulataneously. Ofcourse, > context has to reach > > the new AR before it becomes useless there. > > I'm sort-of lost here, too, unfortunately. I am sure we can > agree that > context information sometimes has freshness requirements, but I don't > see how predictive vs. reactive affects that statement. Of > course, with > predictive transfers, it will be easier to meet the freshness > requirement. > > Regards, > Charlie P. > ------_=_NextPart_001_01C0F5D9.64EB6270 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer

Charlie:

 Will the mobile actually initiate a ct or will it initiate a
handover? Or are you expecting to do both? Do you expect to complete
MN initiated CT in less then 60ms? If not, how will ct in this context
provide seamless handover for VoIP?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 3:01 PM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Reactive context transfer
>
>
>
> Hello Hamid,
>
> > Hamid Syed wrote:
>
> > I guess we need to understand the boundaries of context
> transfer and the
> > actual handover.
>
> Yes, in fact I believe that maybe the word "handover" needs precise
> definition with respect to the process of context transfer (I
> was going
> to say "in the context of ..." but that would be bad :-).
>
> > The first two options you listed are handover scenarios
> where the decision is
> > made where the mobile is going to handover. I am confused
> how does it relates
> > to context transfer?
>
> I can easily imagine four cases:
> - Network initiated predictive context transfer
> - Network initiated reactive context transfer
> - Mobile initiated predictive context transfer
> - Mobile initiated reactive context transfer
>
> I am certain that all four cases can be handled by the same
> context transfer protocol messages.
>
> I am myself confused about how to answer your question,
> because it seems
> clear to me that these terms are in fact relevant to context transfer.
>
> > The predictive context transfer is the same as the
> proactive context transfer
> > where context is made available to the new AR before a
> handover of occurs.
>
> Agreed, except that I am suggesting the use of a different word.
>
> > Your reactive context transfer definition is more like a
> "break-before-make"
> > scenario. I do not know how context could be useful if the
> transfer happens
> > after the handover completion.
>
> I can think of very many examples.  As one example, multicast group
> membership MIGHT be established at the new access router AFTER the
> basic handover.
>
> But I also want to clearly distinguish betwen "reactive" and
> "break-before-make".
> These is not at all the same things.  The latter is pretty
> much confined
> to discussion below layer-3, at least for connectionless
> protocols like IP.
> The former only just has to do with when the context transfer can get
> started.
>
> Just as one example, of probably dozens, what if the context transfer
> request started immediately after link-establishment in a
> make-before-break
> system?  This could easily happen, and in cooperation with
> Mobile IP or
> stateless address autoconfiguration it might reduce the amount of time
> for the mobile node to get situated on the new network.
>
> In fact, with make-before-break, maybe one would always want
> to use reactive context transfer instead of predictive.
> With make-before-break, there's nothing left to predict!
>
> >                                  What will happen to the
> traffic which has
> > already been handed over to the AR and the context
> processing is not yet done?
> > particularly with the contexyt information that is
> calculated on a per packet
> > arrival basis.
>
> You probably have a specific case in mind, that I can't
> exactly guess at.
> However, in general, the way that traffic is handled with
> incomplete context
> transfer is going to be a problem, regardless of whether the
> transfer is
> requested predictively or reactively.
>
> >                   For example metering?. How metering
> context could be useful if
> > the meter value at the new AR has already passed.
>
> Here I am lost.  What does it mean for a meter value to be passed?
>
> Why does it matter whether the new access router or the
> previous access
> router is running the meter?
>
> >                                                  I believe
> the reactive
> > context transfer is also a make-before-break scenario with
> context transfer
> > and the handover should occur simulataneously. Ofcourse,
> context has to reach
> > the new AR before it becomes useless there.
>
> I'm sort-of lost here, too, unfortunately.  I am sure we can
> agree that
> context information sometimes has freshness requirements, but I don't
> see how predictive vs. reactive affects that statement.  Of
> course, with
> predictive transfers, it will be easier to meet the freshness
> requirement.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C0F5D9.64EB6270-- From owner-seamoby@diameter.org Fri Jun 15 17:00: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 RAA29535 for ; Fri, 15 Jun 2001 17:00:19 -0400 (EDT) Received: (qmail 17082 invoked by alias); 15 Jun 2001 20:48:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17076 invoked by uid 200); 15 Jun 2001 20:48:36 -0000 Received: (qmail 17071 invoked from network); 15 Jun 2001 20:48:33 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 20:48:33 -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 NAA26156; Fri, 15 Jun 2001 13:58:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FKwij08590; Fri, 15 Jun 2001 13:58:44 -0700 X-mProtect: Fri, 15 Jun 2001 13:58:44 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdM13iSR; Fri, 15 Jun 2001 13:58:42 PDT Message-ID: <3B2A772F.8525E00E@iprg.nokia.com> Date: Fri, 15 Jun 2001 13:59:27 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "\[seamoby\] Working Group mailing list" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D35@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, Gary Kenward wrote: > > > Charlie: > > Will the mobile actually initiate a ct or will it initiate a > handover? Or are you expecting to do both? It seems to me that quite often, if the mobile is going to initiate a handover, it will request that the context features should be transferred at the same time. However, I do not suggest that we should make such a restriction. Is it necessary to be explicit? > Do you expect to complete > MN initiated CT in less then 60ms? If not, how will ct in this context > > provide seamless handover for VoIP? I would hope that any system built to support VoIP would complete a context transfer within 60ms. Perhaps systems built that require mobile-initiated context transfers will take longer than others, but still fit within the time requirements. It would depend on many factors. Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 15 17:07:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29630 for ; Fri, 15 Jun 2001 17:07:53 -0400 (EDT) Received: (qmail 17560 invoked by alias); 15 Jun 2001 20:56:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17554 invoked by uid 200); 15 Jun 2001 20:56:11 -0000 Received: (qmail 17549 invoked from network); 15 Jun 2001 20:56:10 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 20:56:10 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 17:06:21 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8000@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Charlie Perkins'" , Gary Kenward Cc: "\[seamoby\] Working Group mailing list" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 17:06:12 -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: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 4:59 PM > To: Gary Kenward > Cc: [seamoby] Working Group mailing list > Subject: Re: [seamoby] Reactive context transfer > > > > Hello Gary, > Gary Kenward wrote: > > > > > > > Charlie: > > > > Will the mobile actually initiate a ct or will it initiate a > > handover? Or are you expecting to do both? > > It seems to me that quite often, if the mobile is going to > initiate a handover, it will request that the context features > should be transferred at the same time. However, I do > not suggest that we should make such a restriction. > Is it necessary to be explicit? > > > > > > Do you expect to complete > > MN initiated CT in less then 60ms? If not, how will ct in > this context > > > > provide seamless handover for VoIP? > > I would hope that any system built to support VoIP would complete > a context transfer within 60ms. Perhaps systems built that require > mobile-initiated context transfers will take longer than others, but > still fit within the time requirements. It would depend on many > factors. Also, a bifurcated flow lasting less than half a dozen packets is an option for systems with less than ideal signalling delay. - Kulwinder. > > Regards, > Charlie P. > > From owner-seamoby@diameter.org Fri Jun 15 17:11: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 RAA29716 for ; Fri, 15 Jun 2001 17:11:38 -0400 (EDT) Received: (qmail 17955 invoked by alias); 15 Jun 2001 20:59:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17946 invoked by uid 200); 15 Jun 2001 20:58:54 -0000 Received: (qmail 17910 invoked from network); 15 Jun 2001 20:58:40 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 20:58:40 -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 OAA26924; Fri, 15 Jun 2001 14:08:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FL8nP23390; Fri, 15 Jun 2001 14:08:49 -0700 X-mProtect: Fri, 15 Jun 2001 14:08:49 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd8XF0jM; Fri, 15 Jun 2001 14:08:46 PDT Message-ID: <3B2A798B.6FC6AB81@iprg.nokia.com> Date: Fri, 15 Jun 2001 14:09:31 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'seamoby'" Subject: Re: [seamoby] Reactive context transfer References: <9FBD322B7824D511B36900508BF93C9C9F5D33@zcard031.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------C67BA11B7252DAA134AAA904" Sender: owner-seamoby@diameter.org Precedence: bulk --------------C67BA11B7252DAA134AAA904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello folks, I don't want to fan the flames, but I have to pipe up and speak here. Gary Kenward wrote: > Actually, it turns out that consensus cannot be determined at the > dtlevel, only at the wg level - which requires Pat. > Based upon this, every "decision" made during the last six months > canbe re-opened. I hope Pat has lot's of energy.Gary In the first place, according to my understanding, Pat should play an equal role in the consensus as other working group members. The working group chair can make determinations about what the consensus of the group is, and try to see whether or not the milestones are likely to be met by following the processes of the moment. However, it is possible for the working group consensus to take shape in a way that may be different than the desires of the working-group chair(s) Of course, the foregoing is only my opinion and someone else who knows the rules better might be able to make some clarifications. But I'll bet it's not too far wrong.. As for the problem of re-opening previous decisions, that should only happen if the previous decisions cannot stand up to working-group scrutiny. I don't see that happening, and it seems to me that the current discussion (about reactive signaling) has only taken up a few days. Of course there were lots of discussions preceding the current one -- but I reckon you weren't counting those. Regards, Charlie P. --------------C67BA11B7252DAA134AAA904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello folks,

I don't want to fan the flames, but I have to pipe up and
speak here.

Gary Kenward wrote:

 Actually, it turns out that consensus cannot be determined at the dtlevel, only at the wg level - which requires Pat. 
 Based upon this, every "decision" made during the last six months canbe re-opened. I hope Pat has lot's of energy.Gary


In the first place, according to my understanding, Pat should
play an equal role in the consensus as other working group
members.  The working group chair can make determinations
about what the consensus of the group is, and  try to
see whether or not the milestones are likely to be met by
following the processes of the moment.  However, it is possible
for the working group consensus to take shape in a way that
may be different than the desires of the working-group chair(s)

Of course, the foregoing is only my opinion and someone else
who knows the rules better might be able to make some
clarifications.  But I'll bet it's not too far wrong..

As for the problem of re-opening previous decisions, that
should only happen if the previous decisions cannot stand up
to working-group scrutiny.  I don't see that happening, and
it seems to me that the current discussion (about reactive
signaling) has only taken up a few days.  Of course there
were lots of discussions preceding the current one -- but I
reckon you weren't counting those.

Regards,
Charlie P.
  --------------C67BA11B7252DAA134AAA904-- From owner-seamoby@diameter.org Fri Jun 15 17:41: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 RAA00095 for ; Fri, 15 Jun 2001 17:41:01 -0400 (EDT) Received: (qmail 18583 invoked by alias); 15 Jun 2001 21:27:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18577 invoked by uid 200); 15 Jun 2001 21:27:18 -0000 Received: (qmail 18572 invoked from network); 15 Jun 2001 21:27:16 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 21:27:16 -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 PAA16351; Fri, 15 Jun 2001 15:37:56 -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 OAA23251; Fri, 15 Jun 2001 14:37:56 -0700 (PDT) Message-Id: <200106152137.OAA23251@heliopolis.eng.sun.com> Date: Fri, 15 Jun 2001 14:37:56 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... To: ASINGH1@motorola.com, rajeev@IPRG.nokia.com Cc: kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HNtUhMTwKpbqxdNivxIbfA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Rajeev, I don't think we can require L3 triggering in all cases. We need to make sure that an MN not need to do L3 triggering, otherwise, as Gary points out, performance will suffer. If there's an L2 trigger, it should be used preferentially. jak >Delivered-To: seamoby-list@charizard.diameter.org >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon Valley Messaging Protection >Date: Fri, 15 Jun 2001 11:59:37 -0700 >From: Rajeev Koodli >To: Singh Ajoy-ASINGH1 >CC: "'Kulwinder Atwal'" , Gary Kenward , "'seamoby'" >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... > > >Hello Ajoy, > >whereas use of link-layer triggers is very useful, it is not something we >can rely upon to be present everywhere (as you correctly point out for >Inter-technology handovers). I don't think we ever said we disallow link >layer triggers. We must not say that that's our solution. At the IP layer, >we need to define IP messages. I think we pretty much agree. > >Regards, > >-Rajeev > > >Singh Ajoy-ASINGH1 wrote: > >> I think it is possible to receive link layer trigger at the new >> access router which can be used to initiate context transfer. >> This will be mostly useful in case of some intra-technology >> handovers. In case MN moves across different technologies, yes >> some sort of MN trigger is useful. Having said that is it a >> good idea to limit the scope of CT protocol? I think we >> should allow both the options. >> regards, >> ajoy >> >> -----Original Message----- >> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> Sent: Friday, June 15, 2001 12:50 PM >> To: 'Rajeev Koodli'; Gary Kenward >> Cc: 'seamoby' >> Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: >> Authentication & Authorization ... >> >> I would strongly object as well. >> >> No MN involvement is technology specific and implementation specific. >> >> The End-User needs the ability to decide when to switch between different >> link-layers: wireless and wired. There is NO way for the network to know >> this is about to happen. >> >> Infact, there was much dicussion in support of this as a requirement. We >> need to add some new text. >> >> - Kulwinder. >> >> > -----Original Message----- >> > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] >> > Sent: Friday, June 15, 2001 1:30 PM >> > To: Gary Kenward >> > Cc: 'seamoby' >> > Subject: Reactive CT definition: Was Re: [seamoby] RE: >> > Authentication & >> > Authorization ... >> > >> > >> > >> > Hello Gary, >> > >> > >> > Gary Kenward wrote: >> > >> > > >> > > >> > > Kulwinder: >> > > >> > > I don't agree with your observation. We did discuss how >> > CT was to be >> > > >> > > initiated, and agreed that there would be no explicit >> > signalling from >> > > the MN (not at least as far as CT was concerned). >> > > >> > >> > Rajeev: I don't believe that we ever said there would be no explicit >> > signaling from the MN! >> > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives >> > the option to the MN to indicate how the feature contexts be handled. >> > >> > I would have strong objection to this. >> > >> > >> > > >> > > The definition of reactive CT (read the problem >> > statement)has to do >> > > with >> > > the order/timing of events, not with where the initiating >> > event comes >> > > from. >> > >> > Rajeev: I don't remember going through reactive CT or proactive CT >> > during problem statement phase at all. Nevertheless, where is the >> > definition of reactive CT that says a MN cannot initiate signaling ? >> > >> > Regards, >> > >> > -Rajeev >> > >> > >> > > >> > > >> > > Gary >> > > >> > > > -----Original Message----- >> > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> > > > Sent: Thursday, June 14, 2001 6:30 PM >> > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat >> > > > Calhoun'; Phillip >> > > > Neumiller >> > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > "in-the-large" >> > > > w as Re: [seamob y] ct problem statement >> > > > >> > > > >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Nakhjiri Madjid-MNAKHJI1 >> > > [mailto:Madjid.Nakhjiri@motorola.com] >> > > > > Sent: Thursday, June 14, 2001 6:02 PM >> > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat >> > > > > Calhoun'; Phillip >> > > > > Neumiller >> > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > "in-the-large" >> > > > > w as Re: [seamob y] ct problem statement >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > -----Original Message----- >> > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> > > > > Sent: Thursday, June 14, 2001 4:46 PM >> > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller >> > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; >> > > > > wirelessinternet@internet.motlabs.com >> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > "in-the-large" >> > > > > w as Re: [seamob y] ct problem statement >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Nakhjiri Madjid-MNAKHJI1 >> > > > [mailto:Madjid.Nakhjiri@motorola.com] >> > > > > > Sent: Thursday, June 14, 2001 5:09 PM >> > > > > > To: 'Pat Calhoun'; Phillip Neumiller >> > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; >> > > > > Kulwinder >> > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > > "in-the-large" >> > > > > > w as Re: [seamob y] ct problem statement >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > -----Original Message----- >> > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] >> > > > > > Sent: Wednesday, June 13, 2001 8:29 AM >> > > > > > To: Phillip Neumiller >> > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; >> > > Charlie >> > > > > > Perkins; Kulwinder Atwal; 'seamoby'; >> > > > > > wirelessinternet@internet.motlabs.com >> > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization >> > > > > > "in-the-large" >> > > > > > w as Re: [seamob y] ct problem statement >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller >> > > wrote: >> > > > > > > There are companies that build products (WRQ's reflection >> > > comes >> > > > > > > to mind) that freeze the state of the IP stack >> > (gracefully in >> > > > > > > the application sense), until the flow of IP traffic can >> > > resume. >> > > > > > > This is sort of an ultra-slow handover. I see no >> > > > reason why THIS >> > > > > > > can not be made seamless with CT. Why should CT not be >> > > capable >> > > > > > > of accomodating this Pat? >> > > > > > >> > > > > > Sure, they could, but what is seamless in this sense? The user >> > > has >> > > > > > no service for some time, so what is an extra couple of >> > > > > seconds while >> > > > > > signalling occurs over the air to update the local ARs state?? >> > > The >> > > > > > user would probably not even notice. >> > > > > > >> > > > > > Actually, you seem to imply something that I am not sure that >> > > I've >> > > > > > been thinking about that much, which is the mobile >> > updating the >> > > > > > AR's state. This, btw, can be problematic, since the >> > > > mobile doesn't >> > > > > > necessarily share an SA with the AR (hence DoS attacks), and a >> > > > > > malicious mobile could send bogus (mal-formed) CT >> > packets in an >> > > > > > attempt to crash (or cause mis-behaving) ARs. >> > > > > > >> > > > > > Something to think about in the DoS space. >> > > > > > >> > > > > > MN>> Yes, involving the MN is CT is definitely a whole other >> > > > > > ball of wax. As I said earlier the assumption was that the >> > > > > CT happens >> > > > > > AR to AR and I was exploring the DoSs for that case. >> > > > > >> > > > > >> > > > > > The MN is not authenticated to the newAR, so all kinds of >> > > security >> > > > > > problems exists until the MN is "properly introduced" to >> > > > the newAR. >> > > > > >> > > > > What do you mean "properly introduced" to the newAR. The MN >> > > > > can certainly >> > > > > authenticate to the newAR. The MN can just show up at the >> > > > new AR and >> > > > > introduce itself. It called "Reactive" Context Transfer. >> > > > > >> > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip >> > > > > the security >> > > > > details between MN and newAR. Yes, MN can authenticate itself >> > > > > to newAR but >> > > > > not as part of CT, and for sure not before CT completition, >> > > > > especially, if >> > > > > the intention of CT was to transfer MN's >> > > > > for-AAA-Security-needed context. >> > > > > >> > > > > I don't think reactive context transfer was meant to be >> > > > > initiated by MN and >> > > > > definitely not after "MN's introduction itself to newAR". >> > > > >> > > > Of course it was intended. Read the Archive. If the MN is >> > > switching >> > > > between wireless and wired, _as_stated_in_our_charter_, there >> > > > is no other >> > > > way other than MN initiated CT. >> > > > >> > > > What do you expect will happen when an MN loses connectivity >> > > > between ARs and >> > > > just shows up at the newAR? Do you _really_ expect the >> > > > End-User to drive >> > > > back during Rush Hour to the oldAR and try again? >> > > > >> > > > > What does this >> > > > > introduction mean in context of "context transfer" anyway. If >> > > > > CT is supposed >> > > > > to happen between ARs, where does this introduction come in? >> > > > > Unless you are >> > > > > talking about an L2 connectivity signal or even an L2 >> > > > > authentication (which >> > > > > is not very fast!!!). >> > > > > The scenario is an AR-AR CT, then an MN-newAR authentication >> > > (proper >> > > > > introduction) >> > > > > based on transferred credential after CT is complete. >> > > > >> > > > How does the newAR even know that the MN has arrived if the >> > > > MN does not >> > > > annouce itself? Why should the newAR waste time doing a CT >> > > > for an MN that >> > > > is not authorized? Sounds like an opportunity for a DOS >> > > > attack. Authorize >> > > > first. Then do CT. Especially for an MN that has arrived >> > > > unannouced at the >> > > > newAR due to a service disruption will moving between ARs. >> > > > >> > > > - Kulwinder. >> > > > >> > > > > >> > > > > The preferred case, of course, is when the oldAR transfers >> > > > > trust to the >> > > > > newAR. >> > > > > >> > > > > MN>> Of course. That is why I mentioned "properly introduced" >> > > > > >> > > > > But, certainly we must consider the case of an MN just >> > > > > showing up at the >> > > > > newAR. The newAR is then faced with finding out where the >> > > > MN was last >> > > > > attached and invalidating the oldSA. The MN has to present a >> > > > > credential to >> > > > > the newAR that the oldAR will accept as valid. >> > > > > >> > > > > MN>> Yes, but that is not where CT helps, you are out of the >> > > > > CT-is-an-optimization >> > > > > territory. MN does a lot of negotiations for establishing >> > > > the context >> > > > > anyway. >> > > > > >> > > > > BTW, I just noticed that my initials and acronym for Mobile >> > > > > Node are the >> > > > > same :( >> > > > > "MN>> means I am talking :) >> > > > > >> > > > > Madjid >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > >> > > > > > Madjid >> > > > > > >> > > > > > PatC >> > > > > > >> > > > > >> > > > >> > > From owner-seamoby@diameter.org Fri Jun 15 17:46: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 RAA00193 for ; Fri, 15 Jun 2001 17:46:36 -0400 (EDT) Received: (qmail 18828 invoked by alias); 15 Jun 2001 21:30:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18822 invoked by uid 200); 15 Jun 2001 21:30:45 -0000 Received: (qmail 18809 invoked from network); 15 Jun 2001 21:30:41 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 21:30:41 -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 PAA18477; Fri, 15 Jun 2001 15:41:14 -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 OAA23398; Fri, 15 Jun 2001 14:41:15 -0700 (PDT) Message-Id: <200106152141.OAA23398@heliopolis.eng.sun.com> Date: Fri, 15 Jun 2001 14:41:15 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: [seamoby] Reactive context transfer To: pcalhoun@diameter.org, rajeev@IPRG.nokia.com Cc: charliep@IPRG.nokia.com, gkenward@nortelnetworks.com, seamoby@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +bRaCCrjWPhWdtTXqfAFQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Rajeev, How many bytes is the message you have in mind? Add that up to the bytes I sent out for FMIPv6 handover, divide by the link speed, and you get yet more latency. It is simply not acceptable to run up radio link latencies if we expect to get good real time performance on 3G protocols. On WLAN, with better aggregate performance, you can do it. We *must* have the alternative of triggering the context transfer at L2. jak >Delivered-To: seamoby-list@charizard.diameter.org >X-mProtect: Fri, 15 Jun 2001 12:09:03 -0700 Nokia Silicon Valley Messaging Protection >Date: Fri, 15 Jun 2001 12:09:01 -0700 >From: Rajeev Koodli >To: Pat Calhoun >CC: "Charles E. Perkins" , Gary Kenward , "'seamoby'" >Subject: Re: [seamoby] Reactive context transfer > >Pat Calhoun wrote: > >> Charlie, >> >> Based on your comment below, it doesn't sounds like you are stating that >> a CT MN->AR message is needed, but rather that a L2 trigger that would >> cause CT MAY be generated by the mobile. >> >> > >Rajeev: I am sorry, I don't know how we can say that we can rely on a L2 trigger >from the MN to cause CT. This could work on some links but not on others. It has >got to be an IP message, for us. > > > >> If this is true, then I believe that we are *all* in agreement, and if >> so, may I ask what in the spec could be changed to reflect this agreement? >> >> PatC >> On Fri, Jun 15, 2001 at 11:11:27AM -0700, Charles E. Perkins wrote: >> > >> > Hello Gary, >> > >> > > Gary Kenward wrote: >> > >> > > For us, it is unacceptable that CT should be dependent upon >> > > some layer 3 messaging from the MN. Over the air transit latencies >> > > are just too great, and we don' see the value. I think here we >> > > simply must agree that we have different views of the world. >> > >> > Maybe we're not so far apart after all. Of course I agree that >> > we should have the possibility to do context transfer without >> > requiring the mobile node to trigger the process. I'm just >> > holding out for the possibility that the mobile node CAN trigger >> > the process in some circumstances. For instance, it would probably >> > be just fine over 802.11, even if it's not advisable over some >> > cellular media. >> > >> > > This whole issue was discussed at great length, and it was >> > > clear then that there was no "right" approach. We decided then >> > > that we would abstract out the initiating event - some called >> > > it a trigger - and that would allow for different networks and >> > > different vendors to define the approach they like the best. >> > >> > Exactly. Thus, I claim we aren't so far apart. But, some of the >> > allowable choices should include allowing the mobile node to >> > initiate the process of context transfer. >> > >> > > Who triggers context transfer is not relevant, unless we believe >> > > we are going to build the trigger into CTP as a signalling message. >> > > There was a long debate, and it was decided very early on that >> > > it was not necessary to build this into CTP. That does not >> > > mean that this approach is excluded from the mobility solution, nor >> > > does it mean that an MN message could not trigger CT indirectly. It >> > > simply means that CTP will not include an MN to AR message. >> > >> > Again, just because context transfer CAN be accomplished without >> > a trigger from the mobile node in SOME circumstances, does not mean >> > that the mobile node should be disallowed from supplying the trigger >> > in OTHER circumstances. Thus, I agree with the second and third >> > sentences, but it seems pretty clear that we can ALLOW such a >> > trigger indication without dragging down the rest of the protocol. >> > Thus I am asking for reconsideration of the 4th sentence, and I >> > don't see any downside at all. >> > >> > > You can refer to the archives if you question this, in particular, >> > > the conference call meeting minutes. >> > >> > That's raising the bar pretty high for my participation in this >> > particular discussion. Would it be O.K. to ask that you respond >> > just to my points in this e-mail? >> > >> > > What you are proposing is to return to the discussions of six months ago. >> > > This would be unacceptable to me, for sure, and I suspect others engaged >> > > with this process would also be very frustrated. >> > >> > Well, from the e-mail I've seen so far, it looks like there may be >> > frustrations on both sides. Moreover, to accomodate those who wish >> > to allow mobile-node triggering, I don't think would cause any >> > discomfort to those who want to have network-initiated transfers. >> > So why not? >> > >> > Regards, >> > Charlie P. > From owner-seamoby@diameter.org Fri Jun 15 18:11: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 SAA00675 for ; Fri, 15 Jun 2001 18:11:24 -0400 (EDT) Received: (qmail 19849 invoked by alias); 15 Jun 2001 21:59:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19842 invoked by uid 200); 15 Jun 2001 21:59:14 -0000 Received: (qmail 19834 invoked from network); 15 Jun 2001 21:59:07 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 21:59:07 -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 PAA01549; Fri, 15 Jun 2001 15:09:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5FM9Hx25103; Fri, 15 Jun 2001 15:09:17 -0700 X-mProtect: Fri, 15 Jun 2001 15:09:17 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdrkv7cp; Fri, 15 Jun 2001 15:09:15 PDT Message-ID: <3B2A87B3.5361E3A0@iprg.nokia.com> Date: Fri, 15 Jun 2001 15:09:56 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: pcalhoun@diameter.org, rajeev@IPRG.nokia.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer References: <200106152141.OAA23398@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 Hello Jim, I can't totally speak for Rajeev, but I'm pretty sure that no such restriction was suggested. In my discussions with Rajeev, our conclusion was that we wanted the possibility for a layer-3 trigger, not the requirement for it. We should be able to run the protocol predictively or reactively, and triggered from layer 3 or from layer 2, and initiated by the network or by the mobile node. This is doable, and very desirable to have the same protocol messages for the various cases insofar as it is possible to do so. Regards, Charlie P. James Kempf wrote: > Rajeev, > > How many bytes is the message you have in mind? Add that up to > the bytes I sent out for FMIPv6 handover, divide by the link speed, > and you get yet more latency. > > It is simply not acceptable to run up radio link latencies if we > expect to get good real time performance on 3G protocols. > > On WLAN, with better aggregate performance, you can do it. > > We *must* have the alternative of triggering the context transfer > at L2. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >X-mProtect: Fri, 15 Jun 2001 12:09:03 -0700 Nokia Silicon Valley Messaging > Protection > >Date: Fri, 15 Jun 2001 12:09:01 -0700 > >From: Rajeev Koodli > >To: Pat Calhoun > >CC: "Charles E. Perkins" , Gary Kenward > , "'seamoby'" > >Subject: Re: [seamoby] Reactive context transfer > > > >Pat Calhoun wrote: > > > >> Charlie, > >> > >> Based on your comment below, it doesn't sounds like you are stating that > >> a CT MN->AR message is needed, but rather that a L2 trigger that would > >> cause CT MAY be generated by the mobile. > >> > >> > > > >Rajeev: I am sorry, I don't know how we can say that we can rely on a L2 > trigger > >from the MN to cause CT. This could work on some links but not on others. It > has > >got to be an IP message, for us. > > > > > > > >> If this is true, then I believe that we are *all* in agreement, and if > >> so, may I ask what in the spec could be changed to reflect this agreement? > >> > >> PatC > >> On Fri, Jun 15, 2001 at 11:11:27AM -0700, Charles E. Perkins wrote: > >> > > >> > Hello Gary, > >> > > >> > > Gary Kenward wrote: > >> > > >> > > For us, it is unacceptable that CT should be dependent upon > >> > > some layer 3 messaging from the MN. Over the air transit latencies > >> > > are just too great, and we don' see the value. I think here we > >> > > simply must agree that we have different views of the world. > >> > > >> > Maybe we're not so far apart after all. Of course I agree that > >> > we should have the possibility to do context transfer without > >> > requiring the mobile node to trigger the process. I'm just > >> > holding out for the possibility that the mobile node CAN trigger > >> > the process in some circumstances. For instance, it would probably > >> > be just fine over 802.11, even if it's not advisable over some > >> > cellular media. > >> > > >> > > This whole issue was discussed at great length, and it was > >> > > clear then that there was no "right" approach. We decided then > >> > > that we would abstract out the initiating event - some called > >> > > it a trigger - and that would allow for different networks and > >> > > different vendors to define the approach they like the best. > >> > > >> > Exactly. Thus, I claim we aren't so far apart. But, some of the > >> > allowable choices should include allowing the mobile node to > >> > initiate the process of context transfer. > >> > > >> > > Who triggers context transfer is not relevant, unless we believe > >> > > we are going to build the trigger into CTP as a signalling message. > >> > > There was a long debate, and it was decided very early on that > >> > > it was not necessary to build this into CTP. That does not > >> > > mean that this approach is excluded from the mobility solution, nor > >> > > does it mean that an MN message could not trigger CT indirectly. It > >> > > simply means that CTP will not include an MN to AR message. > >> > > >> > Again, just because context transfer CAN be accomplished without > >> > a trigger from the mobile node in SOME circumstances, does not mean > >> > that the mobile node should be disallowed from supplying the trigger > >> > in OTHER circumstances. Thus, I agree with the second and third > >> > sentences, but it seems pretty clear that we can ALLOW such a > >> > trigger indication without dragging down the rest of the protocol. > >> > Thus I am asking for reconsideration of the 4th sentence, and I > >> > don't see any downside at all. > >> > > >> > > You can refer to the archives if you question this, in particular, > >> > > the conference call meeting minutes. > >> > > >> > That's raising the bar pretty high for my participation in this > >> > particular discussion. Would it be O.K. to ask that you respond > >> > just to my points in this e-mail? > >> > > >> > > What you are proposing is to return to the discussions of six months ago. > >> > > This would be unacceptable to me, for sure, and I suspect others engaged > >> > > with this process would also be very frustrated. > >> > > >> > Well, from the e-mail I've seen so far, it looks like there may be > >> > frustrations on both sides. Moreover, to accomodate those who wish > >> > to allow mobile-node triggering, I don't think would cause any > >> > discomfort to those who want to have network-initiated transfers. > >> > So why not? > >> > > >> > Regards, > >> > Charlie P. > > From owner-seamoby@diameter.org Fri Jun 15 18:47: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 SAA01195 for ; Fri, 15 Jun 2001 18:47:26 -0400 (EDT) Received: (qmail 20438 invoked by alias); 15 Jun 2001 22:33:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20432 invoked by uid 200); 15 Jun 2001 22:33:34 -0000 Received: (qmail 20427 invoked from network); 15 Jun 2001 22:33:33 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jun 2001 22:33:33 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA15065 for ; Fri, 15 Jun 2001 15:44:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA26460 for ; Fri, 15 Jun 2001 15:37:33 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 17:44:12 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Singh Ajoy-ASINGH1 , rajeev@IPRG.nokia.com Cc: kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Fri, 15 Jun 2001 17:44:12 -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 After going through some of emails exchanged by different people, I also think latency of L3 message may be too high. Possibly this can bit the purpose of context transfer. Perhaps we should prefer layer 2 trigger over any layer 3 message. regards, ajoy -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Friday, June 15, 2001 4:38 PM To: Ajoy Singh-ASINGH1; rajeev@IPRG.nokia.com Cc: kulwinder.atwal@zucotto.com; gkenward@nortelnetworks.com; seamoby@diameter.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Rajeev, I don't think we can require L3 triggering in all cases. We need to make sure that an MN not need to do L3 triggering, otherwise, as Gary points out, performance will suffer. If there's an L2 trigger, it should be used preferentially. jak >Delivered-To: seamoby-list@charizard.diameter.org >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon Valley Messaging Protection >Date: Fri, 15 Jun 2001 11:59:37 -0700 >From: Rajeev Koodli >To: Singh Ajoy-ASINGH1 >CC: "'Kulwinder Atwal'" , Gary Kenward , "'seamoby'" >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... > > >Hello Ajoy, > >whereas use of link-layer triggers is very useful, it is not something we >can rely upon to be present everywhere (as you correctly point out for >Inter-technology handovers). I don't think we ever said we disallow link >layer triggers. We must not say that that's our solution. At the IP layer, >we need to define IP messages. I think we pretty much agree. > >Regards, > >-Rajeev > > >Singh Ajoy-ASINGH1 wrote: > >> I think it is possible to receive link layer trigger at the new >> access router which can be used to initiate context transfer. >> This will be mostly useful in case of some intra-technology >> handovers. In case MN moves across different technologies, yes >> some sort of MN trigger is useful. Having said that is it a >> good idea to limit the scope of CT protocol? I think we >> should allow both the options. >> regards, >> ajoy >> >> -----Original Message----- >> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> Sent: Friday, June 15, 2001 12:50 PM >> To: 'Rajeev Koodli'; Gary Kenward >> Cc: 'seamoby' >> Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: >> Authentication & Authorization ... >> >> I would strongly object as well. >> >> No MN involvement is technology specific and implementation specific. >> >> The End-User needs the ability to decide when to switch between different >> link-layers: wireless and wired. There is NO way for the network to know >> this is about to happen. >> >> Infact, there was much dicussion in support of this as a requirement. We >> need to add some new text. >> >> - Kulwinder. >> >> > -----Original Message----- >> > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] >> > Sent: Friday, June 15, 2001 1:30 PM >> > To: Gary Kenward >> > Cc: 'seamoby' >> > Subject: Reactive CT definition: Was Re: [seamoby] RE: >> > Authentication & >> > Authorization ... >> > >> > >> > >> > Hello Gary, >> > >> > >> > Gary Kenward wrote: >> > >> > > >> > > >> > > Kulwinder: >> > > >> > > I don't agree with your observation. We did discuss how >> > CT was to be >> > > >> > > initiated, and agreed that there would be no explicit >> > signalling from >> > > the MN (not at least as far as CT was concerned). >> > > >> > >> > Rajeev: I don't believe that we ever said there would be no explicit >> > signaling from the MN! >> > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives >> > the option to the MN to indicate how the feature contexts be handled. >> > >> > I would have strong objection to this. >> > >> > >> > > >> > > The definition of reactive CT (read the problem >> > statement)has to do >> > > with >> > > the order/timing of events, not with where the initiating >> > event comes >> > > from. >> > >> > Rajeev: I don't remember going through reactive CT or proactive CT >> > during problem statement phase at all. Nevertheless, where is the >> > definition of reactive CT that says a MN cannot initiate signaling ? >> > >> > Regards, >> > >> > -Rajeev >> > >> > >> > > >> > > >> > > Gary >> > > >> > > > -----Original Message----- >> > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> > > > Sent: Thursday, June 14, 2001 6:30 PM >> > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat >> > > > Calhoun'; Phillip >> > > > Neumiller >> > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > "in-the-large" >> > > > w as Re: [seamob y] ct problem statement >> > > > >> > > > >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Nakhjiri Madjid-MNAKHJI1 >> > > [mailto:Madjid.Nakhjiri@motorola.com] >> > > > > Sent: Thursday, June 14, 2001 6:02 PM >> > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat >> > > > > Calhoun'; Phillip >> > > > > Neumiller >> > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > "in-the-large" >> > > > > w as Re: [seamob y] ct problem statement >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > -----Original Message----- >> > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] >> > > > > Sent: Thursday, June 14, 2001 4:46 PM >> > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller >> > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; >> > > > > wirelessinternet@internet.motlabs.com >> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > "in-the-large" >> > > > > w as Re: [seamob y] ct problem statement >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Nakhjiri Madjid-MNAKHJI1 >> > > > [mailto:Madjid.Nakhjiri@motorola.com] >> > > > > > Sent: Thursday, June 14, 2001 5:09 PM >> > > > > > To: 'Pat Calhoun'; Phillip Neumiller >> > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; >> > > > > Kulwinder >> > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com >> > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization >> > > > > > "in-the-large" >> > > > > > w as Re: [seamob y] ct problem statement >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > -----Original Message----- >> > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] >> > > > > > Sent: Wednesday, June 13, 2001 8:29 AM >> > > > > > To: Phillip Neumiller >> > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; >> > > Charlie >> > > > > > Perkins; Kulwinder Atwal; 'seamoby'; >> > > > > > wirelessinternet@internet.motlabs.com >> > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization >> > > > > > "in-the-large" >> > > > > > w as Re: [seamob y] ct problem statement >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller >> > > wrote: >> > > > > > > There are companies that build products (WRQ's reflection >> > > comes >> > > > > > > to mind) that freeze the state of the IP stack >> > (gracefully in >> > > > > > > the application sense), until the flow of IP traffic can >> > > resume. >> > > > > > > This is sort of an ultra-slow handover. I see no >> > > > reason why THIS >> > > > > > > can not be made seamless with CT. Why should CT not be >> > > capable >> > > > > > > of accomodating this Pat? >> > > > > > >> > > > > > Sure, they could, but what is seamless in this sense? The user >> > > has >> > > > > > no service for some time, so what is an extra couple of >> > > > > seconds while >> > > > > > signalling occurs over the air to update the local ARs state?? >> > > The >> > > > > > user would probably not even notice. >> > > > > > >> > > > > > Actually, you seem to imply something that I am not sure that >> > > I've >> > > > > > been thinking about that much, which is the mobile >> > updating the >> > > > > > AR's state. This, btw, can be problematic, since the >> > > > mobile doesn't >> > > > > > necessarily share an SA with the AR (hence DoS attacks), and a >> > > > > > malicious mobile could send bogus (mal-formed) CT >> > packets in an >> > > > > > attempt to crash (or cause mis-behaving) ARs. >> > > > > > >> > > > > > Something to think about in the DoS space. >> > > > > > >> > > > > > MN>> Yes, involving the MN is CT is definitely a whole other >> > > > > > ball of wax. As I said earlier the assumption was that the >> > > > > CT happens >> > > > > > AR to AR and I was exploring the DoSs for that case. >> > > > > >> > > > > >> > > > > > The MN is not authenticated to the newAR, so all kinds of >> > > security >> > > > > > problems exists until the MN is "properly introduced" to >> > > > the newAR. >> > > > > >> > > > > What do you mean "properly introduced" to the newAR. The MN >> > > > > can certainly >> > > > > authenticate to the newAR. The MN can just show up at the >> > > > new AR and >> > > > > introduce itself. It called "Reactive" Context Transfer. >> > > > > >> > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip >> > > > > the security >> > > > > details between MN and newAR. Yes, MN can authenticate itself >> > > > > to newAR but >> > > > > not as part of CT, and for sure not before CT completition, >> > > > > especially, if >> > > > > the intention of CT was to transfer MN's >> > > > > for-AAA-Security-needed context. >> > > > > >> > > > > I don't think reactive context transfer was meant to be >> > > > > initiated by MN and >> > > > > definitely not after "MN's introduction itself to newAR". >> > > > >> > > > Of course it was intended. Read the Archive. If the MN is >> > > switching >> > > > between wireless and wired, _as_stated_in_our_charter_, there >> > > > is no other >> > > > way other than MN initiated CT. >> > > > >> > > > What do you expect will happen when an MN loses connectivity >> > > > between ARs and >> > > > just shows up at the newAR? Do you _really_ expect the >> > > > End-User to drive >> > > > back during Rush Hour to the oldAR and try again? >> > > > >> > > > > What does this >> > > > > introduction mean in context of "context transfer" anyway. If >> > > > > CT is supposed >> > > > > to happen between ARs, where does this introduction come in? >> > > > > Unless you are >> > > > > talking about an L2 connectivity signal or even an L2 >> > > > > authentication (which >> > > > > is not very fast!!!). >> > > > > The scenario is an AR-AR CT, then an MN-newAR authentication >> > > (proper >> > > > > introduction) >> > > > > based on transferred credential after CT is complete. >> > > > >> > > > How does the newAR even know that the MN has arrived if the >> > > > MN does not >> > > > annouce itself? Why should the newAR waste time doing a CT >> > > > for an MN that >> > > > is not authorized? Sounds like an opportunity for a DOS >> > > > attack. Authorize >> > > > first. Then do CT. Especially for an MN that has arrived >> > > > unannouced at the >> > > > newAR due to a service disruption will moving between ARs. >> > > > >> > > > - Kulwinder. >> > > > >> > > > > >> > > > > The preferred case, of course, is when the oldAR transfers >> > > > > trust to the >> > > > > newAR. >> > > > > >> > > > > MN>> Of course. That is why I mentioned "properly introduced" >> > > > > >> > > > > But, certainly we must consider the case of an MN just >> > > > > showing up at the >> > > > > newAR. The newAR is then faced with finding out where the >> > > > MN was last >> > > > > attached and invalidating the oldSA. The MN has to present a >> > > > > credential to >> > > > > the newAR that the oldAR will accept as valid. >> > > > > >> > > > > MN>> Yes, but that is not where CT helps, you are out of the >> > > > > CT-is-an-optimization >> > > > > territory. MN does a lot of negotiations for establishing >> > > > the context >> > > > > anyway. >> > > > > >> > > > > BTW, I just noticed that my initials and acronym for Mobile >> > > > > Node are the >> > > > > same :( >> > > > > "MN>> means I am talking :) >> > > > > >> > > > > Madjid >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > >> > > > > > Madjid >> > > > > > >> > > > > > PatC >> > > > > > >> > > > > >> > > > >> > > From owner-seamoby@diameter.org Fri Jun 15 19:00:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01378 for ; Fri, 15 Jun 2001 19:00:45 -0400 (EDT) Received: (qmail 21044 invoked by alias); 15 Jun 2001 22:48:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21038 invoked by uid 200); 15 Jun 2001 22:48:29 -0000 Received: (qmail 21033 invoked from network); 15 Jun 2001 22:48:27 -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; 15 Jun 2001 22:48:27 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FMwQ024645 for ; Fri, 15 Jun 2001 18:58:26 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 15 Jun 2001 18:58:36 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 18:58:37 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D3A@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: "\[seamoby\] Working Group mailing list" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 18:58:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5EE.B54BD000" 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_01C0F5EE.B54BD000 Content-Type: text/plain; charset="iso-8859-1" Hello again. > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 15, 2001 4:59 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: [seamoby] Working Group mailing list > Subject: Re: [seamoby] Reactive context transfer > > > > Hello Gary, > Gary Kenward wrote: > > > > > > > Charlie: > > > > Will the mobile actually initiate a ct or will it initiate a > > handover? Or are you expecting to do both? > > It seems to me that quite often, if the mobile is going to > initiate a handover, it will request that the context features > should be transferred at the same time. However, I do > not suggest that we should make such a restriction. > Is it necessary to be explicit? Only for proactive CT. Although, I'm not sure of how, at the IP layer, a mobile would know that it is about to handover, but hasn't yet (of course, it's simply a matter of providing the right event from the link layer I suppose). > > > > > > Do you expect to complete > > MN initiated CT in less then 60ms? If not, how will ct in > this context > > > > provide seamless handover for VoIP? > > I would hope that any system built to support VoIP would complete > a context transfer within 60ms. Perhaps systems built that require > mobile-initiated context transfers will take longer than others, but > still fit within the time requirements. It would depend on many > factors. Ok, we agree. Then what is your understanding of the 3G radio channel transfer delay for a single IP frame? Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C0F5EE.B54BD000 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer

Hello again.

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 15, 2001 4:59 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [seamoby] Working Group mailing list
> Subject: Re: [seamoby] Reactive context transfer
>
>
>
> Hello Gary,
> Gary Kenward wrote:
>
> >
> >
> > Charlie:
> >
> >  Will the mobile actually initiate a ct or will it initiate a
> > handover? Or are you expecting to do both?
>
> It seems to me that quite often, if the mobile is going to
> initiate a handover, it will request that the context features
> should be transferred at the same time.  However, I do
> not suggest that we should make such a restriction.
> Is it necessary to be explicit?

Only for proactive CT. Although, I'm not sure of how, at the IP
layer, a mobile would know that it is about to handover, but hasn't
yet (of course, it's simply a matter of providing the right event
from the link layer I suppose).

>
>
>
>
> > Do you expect to complete
> > MN initiated CT in less then 60ms? If not, how will ct in
> this context
> >
> > provide seamless handover for VoIP?
>
> I would hope that any system built to support VoIP would complete
> a context transfer within 60ms.  Perhaps systems built that require
> mobile-initiated context transfers will take longer than others, but
> still fit within the time requirements.  It would depend on many
> factors.

Ok, we agree. Then what is your understanding of the 3G radio channel
transfer delay for a single IP frame?

Gary
>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C0F5EE.B54BD000-- From owner-seamoby@diameter.org Fri Jun 15 19:04: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 TAA01416 for ; Fri, 15 Jun 2001 19:04:44 -0400 (EDT) Received: (qmail 21183 invoked by alias); 15 Jun 2001 22:49:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21176 invoked by uid 200); 15 Jun 2001 22:49:30 -0000 Received: (qmail 21163 invoked from network); 15 Jun 2001 22:49:25 -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; 15 Jun 2001 22:49:25 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FMxN025281 for ; Fri, 15 Jun 2001 18:59:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 15 Jun 2001 18:59:28 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 18:59:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D3B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: "'seamoby'" Subject: RE: [seamoby] Reactive context transfer Date: Fri, 15 Jun 2001 18:59:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F5EE.D50E0020" 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_01C0F5EE.D50E0020 Content-Type: text/plain; charset="iso-8859-1" I've lost count ;^{ -----Original Message----- From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] Sent: Friday, June 15, 2001 5:10 PM To: Kenward, Gary [WDLN2:AN10:EXCH] Cc: 'seamoby' Subject: Re: [seamoby] Reactive context transfer Hello folks, I don't want to fan the flames, but I have to pipe up and speak here. Gary Kenward wrote: Actually, it turns out that consensus cannot be determined at the dtlevel, only at the wg level - which requires Pat. Based upon this, every "decision" made during the last six months canbe re-opened. I hope Pat has lot's of energy.Gary In the first place, according to my understanding, Pat should play an equal role in the consensus as other working group members. The working group chair can make determinations about what the consensus of the group is, and try to see whether or not the milestones are likely to be met by following the processes of the moment. However, it is possible for the working group consensus to take shape in a way that may be different than the desires of the working-group chair(s) Of course, the foregoing is only my opinion and someone else who knows the rules better might be able to make some clarifications. But I'll bet it's not too far wrong.. As for the problem of re-opening previous decisions, that should only happen if the previous decisions cannot stand up to working-group scrutiny. I don't see that happening, and it seems to me that the current discussion (about reactive signaling) has only taken up a few days. Of course there were lots of discussions preceding the current one -- but I reckon you weren't counting those. Regards, Charlie P. ------_=_NextPart_001_01C0F5EE.D50E0020 Content-Type: text/html; charset="iso-8859-1"
I've lost count ;^{
-----Original Message-----
From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Friday, June 15, 2001 5:10 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Re: [seamoby] Reactive context transfer

 
Hello folks,

I don't want to fan the flames, but I have to pipe up and
speak here.

Gary Kenward wrote:

 Actually, it turns out that consensus cannot be determined at the dtlevel, only at the wg level - which requires Pat. 
 Based upon this, every "decision" made during the last six months canbe re-opened. I hope Pat has lot's of energy.Gary


In the first place, according to my understanding, Pat should
play an equal role in the consensus as other working group
members.  The working group chair can make determinations
about what the consensus of the group is, and  try to
see whether or not the milestones are likely to be met by
following the processes of the moment.  However, it is possible
for the working group consensus to take shape in a way that
may be different than the desires of the working-group chair(s)

Of course, the foregoing is only my opinion and someone else
who knows the rules better might be able to make some
clarifications.  But I'll bet it's not too far wrong..

As for the problem of re-opening previous decisions, that
should only happen if the previous decisions cannot stand up
to working-group scrutiny.  I don't see that happening, and
it seems to me that the current discussion (about reactive
signaling) has only taken up a few days.  Of course there
were lots of discussions preceding the current one -- but I
reckon you weren't counting those.

Regards,
Charlie P.
 

------_=_NextPart_001_01C0F5EE.D50E0020-- From owner-seamoby@diameter.org Mon Jun 18 02:22: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 CAA28406 for ; Mon, 18 Jun 2001 02:22:01 -0400 (EDT) Received: (qmail 31680 invoked by alias); 18 Jun 2001 06:10:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31674 invoked by uid 200); 18 Jun 2001 06:10:42 -0000 Cc: recipient list not shown: ; Received: (qmail 31669 invoked from network); 18 Jun 2001 06:10:37 -0000 Received: from unknown (HELO xoffice.intern.scientek.co.id) (202.148.3.227) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 06:10:37 -0000 Received: from q4L995UK6 ([64.86.192.70]) by xoffice.intern.scientek.co.id (8.9.3/8.9.3) with SMTP id KAA04197; Mon, 18 Jun 2001 10:45:13 +0700 From: PEjUnOSMq@yahoo.com DATE: 17 Jun 01 8:44:15 PM Message-ID: <8PCx2z6To3VTFw7iY> Content-Type: text/html SUBJECT: Targeted Direct Email Advertising Sender: owner-seamoby@diameter.org Precedence: bulk We will put your product or service instantly into the hands of millions of prospects! =============================================================== "Many business people are finding out that they can now advertise in ways that they never could have afforded in the past. The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY =============================================================== Since 1996, Bulk Email Network has provided bulk email marketing to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. You will have instant guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. We guarantee the lowest prices or your service is free! Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business! 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $9,980 [Week 1]: $69,860 [Month 1]: $279,440 Now you know why you receive so many email advertisements... Best Regards, Jennifer O’Conner, Bulk Email Network Marketing Dept. Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below). To Remove Yourself From This List: Please email to: bulkemailnetwork@myrealbox.com with the email address that you would like removed and the word REMOVE in the subject heading. From owner-seamoby@diameter.org Mon Jun 18 10:26: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 KAA08740 for ; Mon, 18 Jun 2001 10:26:14 -0400 (EDT) Received: (qmail 2630 invoked by alias); 18 Jun 2001 14:14:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2624 invoked by uid 200); 18 Jun 2001 14:14:37 -0000 Received: (qmail 2613 invoked by uid 500); 18 Jun 2001 14:14:35 -0000 Date: Mon, 18 Jun 2001 07:14:34 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Pat Calhoun , "Charles E. Perkins" , Gary Kenward , "'seamoby'" Subject: Re: [seamoby] Reactive context transfer Message-ID: <20010618071434.U17928@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Pat Calhoun , "Charles E. Perkins" , Gary Kenward , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5D2B@zcard031.ca.nortel.com> <3B2A4FCF.ABB497A@iprg.nokia.com> <20010615111715.X17928@charizard.diameter.org> <3B2A5D4D.CC80ED85@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2A5D4D.CC80ED85@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Fri, Jun 15, 2001 at 12:09:01PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 15, 2001 at 12:09:01PM -0700, Rajeev Koodli wrote: > Pat Calhoun wrote: > > > Charlie, > > > > Based on your comment below, it doesn't sounds like you are stating that > > a CT MN->AR message is needed, but rather that a L2 trigger that would > > cause CT MAY be generated by the mobile. > > > > > > Rajeev: I am sorry, I don't know how we can say that we can rely on a L2 trigger > from the MN to cause CT. This could work on some links but not on others. It has > got to be an IP message, for us. ... and a Mobile IP message from the MN to the attendant is not sufficient (e.g. Binding Update)? Does it really need to be a CT protocol message? PatC From owner-seamoby@diameter.org Mon Jun 18 14:14: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 OAA15472 for ; Mon, 18 Jun 2001 14:14:36 -0400 (EDT) Received: (qmail 6183 invoked by alias); 18 Jun 2001 18:03:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6177 invoked by uid 200); 18 Jun 2001 18:03:15 -0000 Received: (qmail 6169 invoked by uid 500); 18 Jun 2001 18:03:13 -0000 Date: Mon, 18 Jun 2001 11:03:13 -0700 From: Pat Calhoun To: seamoby@diameter.org Cc: pcalhoun@diameter.org Subject: [seamoby] How to proceed with Context Transfer Message-ID: <20010618110312.T17928@charizard.diameter.org> Mail-Followup-To: seamoby@diameter.org, pcalhoun@diameter.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, As you may know, Gary is in the process of submitting the first version of the requirements specification out to the secretariat. Of course, we all understand that there are existing discussions which may require changes to the requirements spec, and these can be present in a follow on revision. Since the first version of the spec is being released, I believe that the CT design team has completed its intended goal. So, I'd like to conclude the design team, and would *really* like to thank Gary for doing a great job. I'm sure that to those of you that have participated know, there have been some trying times, and dealing with these, while remaining objective, is difficult. Through all of this, Gary has come up with the first version of the spec, which is very good. Furthermore, Gary did a fantastic job with the Problem Statement. So, I hope that you'll all join me in thanking Gary for his hard work in the past few months. Thanks Gary! I will keep the design team list up and running for a few more days, but ask that people redirect the mails over to the main list. The archives, of course, will still be available. Now that the first revision will be made available, I see that there are still some issues that remain to be resolved. So, I'd like to borrow from a process that the AAA WG has been using for some time now in resolving Diameter issues. The process is that one opens an issue, by sending an e-mail to the list with [Issue] in the subject, and by filling out the set of fields that you can find in the diameter issues web page (http://www.diameter.org/issues.html). I will be creating a similar web page for seamoby context transfer. When submitting an issue, a number will be assigned, and all discussions on that issue should include Issue nn: (where nn is the number assigned by me). Submitted issues SHOULD include proposed text, if possible. Again, the main idea here is to try to better track the set of pending issues, ensure that proposed text is not lost and help me determine consensus, when necessary. The web page that I will create to track all issues will be at http://www.diameter.org/seamoby-ct-issues.html (it isn't there yet, so hold on :) Thanks, PatC From owner-seamoby@diameter.org Mon Jun 18 14:32: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 OAA16114 for ; Mon, 18 Jun 2001 14:32:57 -0400 (EDT) Received: (qmail 6692 invoked by alias); 18 Jun 2001 18:21:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6686 invoked by uid 200); 18 Jun 2001 18:21:23 -0000 Received: (qmail 6681 invoked from network); 18 Jun 2001 18:21:22 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 18:21:22 -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 LAA08625; Mon, 18 Jun 2001 11:31:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5IIVgX23699; Mon, 18 Jun 2001 11:31:42 -0700 X-mProtect: Mon, 18 Jun 2001 11:31:42 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdPkOLGp; Mon, 18 Jun 2001 11:31:41 PDT Message-ID: <3B2E490D.628801BA@iprg.nokia.com> Date: Mon, 18 Jun 2001 11:31:41 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: ASINGH1@motorola.com, kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <200106152137.OAA23251@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 Hello James, James Kempf wrote: > Rajeev, > > I don't think we can require L3 triggering in all cases. We need > Rajeev: Unfortunately, I think we cannot require that the MN do L2 triggering in all cases as well. > to make sure that an MN not need to do L3 triggering, otherwise, > as Gary points out, performance will suffer. Rajeev: yes in some links, may be (or no impact) in others. > If there's an L2 trigger, > it should be used preferentially. Rajeev: certainly. It is one thing to say that if there is a L2 trigger, it should be used preferentially, but another thing to say that we disallow using L3 messages to trigger CT. We should have the possibility of MN requesting CT. Regards, -Rajeev > > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon Valley Messaging > Protection > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > >From: Rajeev Koodli > >To: Singh Ajoy-ASINGH1 > >CC: "'Kulwinder Atwal'" , Gary Kenward > , "'seamoby'" > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & > Authorization ... > > > > > >Hello Ajoy, > > > >whereas use of link-layer triggers is very useful, it is not something we > >can rely upon to be present everywhere (as you correctly point out for > >Inter-technology handovers). I don't think we ever said we disallow link > >layer triggers. We must not say that that's our solution. At the IP layer, > >we need to define IP messages. I think we pretty much agree. > > > >Regards, > > > >-Rajeev > > > > > >Singh Ajoy-ASINGH1 wrote: > > > >> I think it is possible to receive link layer trigger at the new > >> access router which can be used to initiate context transfer. > >> This will be mostly useful in case of some intra-technology > >> handovers. In case MN moves across different technologies, yes > >> some sort of MN trigger is useful. Having said that is it a > >> good idea to limit the scope of CT protocol? I think we > >> should allow both the options. > >> regards, > >> ajoy > >> [snip, snip] From owner-seamoby@diameter.org Mon Jun 18 14:35: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 OAA16281 for ; Mon, 18 Jun 2001 14:35:12 -0400 (EDT) Received: (qmail 7164 invoked by alias); 18 Jun 2001 18:24:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7158 invoked by uid 200); 18 Jun 2001 18:24:03 -0000 Received: (qmail 7153 invoked from network); 18 Jun 2001 18:24:02 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 18:24:02 -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 LAA08802; Mon, 18 Jun 2001 11:34:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5IIYLK27626; Mon, 18 Jun 2001 11:34:21 -0700 X-mProtect: Mon, 18 Jun 2001 11:34:21 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBcJBHS; Mon, 18 Jun 2001 11:34:20 PDT Message-ID: <3B2E49AC.8E40EB7@iprg.nokia.com> Date: Mon, 18 Jun 2001 11:34:20 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: "'James Kempf'" , kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we are close to agreement. If L2 triggers exist, they should be used preferably. That does not mean that we don't define IP message from MN to request CT. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > After going through some of emails exchanged by different > people, I also think latency of L3 message may be too high. > Possibly this can bit the purpose of context transfer. Perhaps > we should prefer layer 2 trigger over any layer 3 message. > regards, > ajoy > > From owner-seamoby@diameter.org Mon Jun 18 14:37: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 OAA16313 for ; Mon, 18 Jun 2001 14:37:06 -0400 (EDT) Received: (qmail 7459 invoked by alias); 18 Jun 2001 18:25:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7453 invoked by uid 200); 18 Jun 2001 18:25:02 -0000 Received: (qmail 7443 invoked by uid 500); 18 Jun 2001 18:25:01 -0000 Date: Mon, 18 Jun 2001 11:25:01 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Singh Ajoy-ASINGH1 , "'James Kempf'" , kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Message-ID: <20010618112501.U17928@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Singh Ajoy-ASINGH1 , 'James Kempf' , kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org References: <3B2E49AC.8E40EB7@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2E49AC.8E40EB7@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Mon, Jun 18, 2001 at 11:34:20AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 18, 2001 at 11:34:20AM -0700, Rajeev Koodli wrote: > > I think we are close to agreement. If L2 triggers exist, they should be used > preferably. That does not mean that we don't define IP message from MN to > request CT. I think that the question is what is the L3 message? Does CT have to provide such a message, or is this out of scope of CT? PatC > > Regards, > > -Rajeev > > > Singh Ajoy-ASINGH1 wrote: > > > After going through some of emails exchanged by different > > people, I also think latency of L3 message may be too high. > > Possibly this can bit the purpose of context transfer. Perhaps > > we should prefer layer 2 trigger over any layer 3 message. > > regards, > > ajoy > > > > From owner-seamoby@diameter.org Mon Jun 18 14: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 OAA16545 for ; Mon, 18 Jun 2001 14:49:02 -0400 (EDT) Received: (qmail 8206 invoked by alias); 18 Jun 2001 18:37:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8199 invoked by uid 200); 18 Jun 2001 18:37:25 -0000 Received: (qmail 8159 invoked from network); 18 Jun 2001 18:37:21 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 18:37:21 -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 LAA09662; Mon, 18 Jun 2001 11:47:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5IIlf812467; Mon, 18 Jun 2001 11:47:41 -0700 X-mProtect: Mon, 18 Jun 2001 11:47:41 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdSwLtpp; Mon, 18 Jun 2001 11:47:40 PDT Message-ID: <3B2E4CCC.63E7CC9@iprg.nokia.com> Date: Mon, 18 Jun 2001 11:47:40 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Singh Ajoy-ASINGH1 , "'James Kempf'" , kulwinder.atwal@zucotto.com, gkenward@nortelnetworks.com, seamoby@diameter.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <3B2E49AC.8E40EB7@iprg.nokia.com> <20010618112501.U17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Mon, Jun 18, 2001 at 11:34:20AM -0700, Rajeev Koodli wrote: > > > > I think we are close to agreement. If L2 triggers exist, they should be used > > preferably. That does not mean that we don't define IP message from MN to > > request CT. > > I think that the question is what is the L3 message? Does CT have to provide > such a message, or is this out of scope of CT? > Rajeev: We have to provide this message, since we allow for the MN to request CT. Regards, -Rajeev > > PatC > > > > Regards, > > > > -Rajeev > > > > > > Singh Ajoy-ASINGH1 wrote: > > > > > After going through some of emails exchanged by different > > > people, I also think latency of L3 message may be too high. > > > Possibly this can bit the purpose of context transfer. Perhaps > > > we should prefer layer 2 trigger over any layer 3 message. > > > regards, > > > ajoy > > > > > > From owner-seamoby@diameter.org Mon Jun 18 15:10:23 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17238 for ; Mon, 18 Jun 2001 15:10:22 -0400 (EDT) Received: (qmail 8854 invoked by alias); 18 Jun 2001 18:59:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8848 invoked by uid 200); 18 Jun 2001 18:59:07 -0000 Received: (qmail 8840 invoked from network); 18 Jun 2001 18:59:06 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 18:59:06 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 15:09:25 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F801F@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Pat Calhoun Cc: Singh Ajoy-ASINGH1 , "'James Kempf'" , Kulwinder Atwal , gkenward@nortelnetworks.com, seamoby@diameter.org Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Mon, 18 Jun 2001 15:09:25 -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: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Monday, June 18, 2001 2:48 PM > To: Pat Calhoun > Cc: Singh Ajoy-ASINGH1; 'James Kempf'; kulwinder.atwal@zucotto.com; > gkenward@nortelnetworks.com; seamoby@diameter.org > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > > Pat Calhoun wrote: > > > On Mon, Jun 18, 2001 at 11:34:20AM -0700, Rajeev Koodli wrote: > > > > > > I think we are close to agreement. If L2 triggers exist, > they should be used > > > preferably. That does not mean that we don't define IP > message from MN to > > > request CT. > > > > I think that the question is what is the L3 message? Does > CT have to provide > > such a message, or is this out of scope of CT? > > > > Rajeev: We have to provide this message, since we allow for > the MN to request CT. I strongly agree. The request message can be identical to the one from the newAR, when the newAR recieves the MN without the currentAR's knowledge (MN just shows up at newAR after a loss in connectivity). The important thing is to seperate the signalling messages from the actual transfer of context. - Kulwinder. > > Regards, > > -Rajeev > > > > > > PatC > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > Singh Ajoy-ASINGH1 wrote: > > > > > > > After going through some of emails exchanged by different > > > > people, I also think latency of L3 message may be too high. > > > > Possibly this can bit the purpose of context transfer. Perhaps > > > > we should prefer layer 2 trigger over any layer 3 message. > > > > regards, > > > > ajoy > > > > > > > > > From owner-seamoby@diameter.org Mon Jun 18 16:58: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 QAA20847 for ; Mon, 18 Jun 2001 16:57:41 -0400 (EDT) Received: (qmail 9894 invoked by alias); 18 Jun 2001 20:39:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9888 invoked by uid 200); 18 Jun 2001 20:39:11 -0000 Received: (qmail 9879 invoked from network); 18 Jun 2001 20:39:08 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 20:39:08 -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 NAA18886; Mon, 18 Jun 2001 13:49:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5IKnQo30808; Mon, 18 Jun 2001 13:49:26 -0700 X-mProtect: Mon, 18 Jun 2001 13:49:26 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBUT7PV; Mon, 18 Jun 2001 13:49:24 PDT Message-ID: <3B2E6954.CFAC2480@iprg.nokia.com> Date: Mon, 18 Jun 2001 13:49:25 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C9F5D30@zcard031.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------BBDE967868364E283FAE9F72" Sender: owner-seamoby@diameter.org Precedence: bulk --------------BBDE967868364E283FAE9F72 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For what it is worth.. Gary Kenward wrote: > > > How can I clarify this: the decision was not to "exclude" > MN triggering, the decision was to exclude layer 3 signalling > from the MN as part of CTP. > Rajeev: That's the point. The MN may request CT using an IP message. > > There needs to be a trigger event (this I believe we all also > agreed upon). Some of us believe that the most effective source > for this trigger event is from the link layer (this is the only > way you can actually be proactive, as far as I know). However, > there should not be any design restriction in CTP preventing this > trigger event from being generated from a different source, and > signalled via IP. > Rajeev: When the link layer trigger is there, it should be used. Assuming that it will always be there is parochial. At the IP layer, we should provide this message. Regards, -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Friday, June 15, 2001 1:30 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: 'seamoby' > > Subject: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & > > Authorization ... > > > > > > > > Hello Gary, > > > > > > Gary Kenward wrote: > > > > > > > > > > > Kulwinder: > > > > > > I don't agree with your observation. We did discuss how > > CT was to be > > > > > > initiated, and agreed that there would be no explicit > > signalling from > > > the MN (not at least as far as CT was concerned). > > > > > > > Rajeev: I don't believe that we ever said there would be no explicit > > > signaling from the MN! > > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), > gives > > the option to the MN to indicate how the feature contexts be > handled. > > > > I would have strong objection to this. > > > > > > > > > > The definition of reactive CT (read the problem > > statement)has to do > > > with > > > the order/timing of events, not with where the initiating > > event comes > > > from. > > > > Rajeev: I don't remember going through reactive CT or proactive CT > > during problem statement phase at all. Nevertheless, where is the > > definition of reactive CT that says a MN cannot initiate signaling ? > > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > Sent: Thursday, June 14, 2001 6:30 PM > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > > Calhoun'; Phillip > > > > Neumiller > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > "in-the-large" > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > > Calhoun'; Phillip > > > > > Neumiller > > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip > Neumiller > > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > > wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > > Kulwinder > > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > > To: Phillip Neumiller > > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > > Charlie > > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > > wirelessinternet@internet.motlabs.com > > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > > wrote: > > > > > > > There are companies that build products (WRQ's reflection > > > comes > > > > > > > to mind) that freeze the state of the IP stack > > (gracefully in > > > > > > > the application sense), until the flow of IP traffic can > > > resume. > > > > > > > This is sort of an ultra-slow handover. I see no > > > > reason why THIS > > > > > > > can not be made seamless with CT. Why should CT not be > > > capable > > > > > > > of accomodating this Pat? > > > > > > > > > > > > Sure, they could, but what is seamless in this sense? The > user > > > has > > > > > > no service for some time, so what is an extra couple of > > > > > seconds while > > > > > > signalling occurs over the air to update the local ARs > state?? > > > The > > > > > > user would probably not even notice. > > > > > > > > > > > > Actually, you seem to imply something that I am not sure > that > > > I've > > > > > > been thinking about that much, which is the mobile > > updating the > > > > > > AR's state. This, btw, can be problematic, since the > > > > mobile doesn't > > > > > > necessarily share an SA with the AR (hence DoS attacks), and > a > > > > > > malicious mobile could send bogus (mal-formed) CT > > packets in an > > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > > > ball of wax. As I said earlier the assumption was that the > > > > > CT happens > > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > > security > > > > > > problems exists until the MN is "properly introduced" to > > > > the newAR. > > > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > > can certainly > > > > > authenticate to the newAR. The MN can just show up at the > > > > new AR and > > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > > the security > > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > > to newAR but > > > > > not as part of CT, and for sure not before CT completition, > > > > > especially, if > > > > > the intention of CT was to transfer MN's > > > > > for-AAA-Security-needed context. > > > > > > > > > > I don't think reactive context transfer was meant to be > > > > > initiated by MN and > > > > > definitely not after "MN's introduction itself to newAR". > > > > > > > > Of course it was intended. Read the Archive. If the MN is > > > switching > > > > between wireless and wired, _as_stated_in_our_charter_, there > > > > is no other > > > > way other than MN initiated CT. > > > > > > > > What do you expect will happen when an MN loses connectivity > > > > between ARs and > > > > just shows up at the newAR? Do you _really_ expect the > > > > End-User to drive > > > > back during Rush Hour to the oldAR and try again? > > > > > > > > > What does this > > > > > introduction mean in context of "context transfer" anyway. If > > > > > CT is supposed > > > > > to happen between ARs, where does this introduction come in? > > > > > Unless you are > > > > > talking about an L2 connectivity signal or even an L2 > > > > > authentication (which > > > > > is not very fast!!!). > > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > > (proper > > > > > introduction) > > > > > based on transferred credential after CT is complete. > > > > > > > > How does the newAR even know that the MN has arrived if the > > > > MN does not > > > > annouce itself? Why should the newAR waste time doing a CT > > > > for an MN that > > > > is not authorized? Sounds like an opportunity for a DOS > > > > attack. Authorize > > > > first. Then do CT. Especially for an MN that has arrived > > > > unannouced at the > > > > newAR due to a service disruption will moving between ARs. > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > > trust to the > > > > > newAR. > > > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > > > But, certainly we must consider the case of an MN just > > > > > showing up at the > > > > > newAR. The newAR is then faced with finding out where the > > > > MN was last > > > > > attached and invalidating the oldSA. The MN has to present a > > > > > credential to > > > > > the newAR that the oldAR will accept as valid. > > > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > > CT-is-an-optimization > > > > > territory. MN does a lot of negotiations for establishing > > > > the context > > > > > anyway. > > > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > > Node are the > > > > > same :( > > > > > "MN>> means I am talking :) > > > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > --------------BBDE967868364E283FAE9F72 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
For what it is worth..

Gary Kenward wrote:

 

How can I clarify this: the decision was not to "exclude"
MN triggering, the decision was to exclude layer 3 signalling
from the MN as part of CTP.
 

Rajeev: That's the point. The MN may request CT using an IP message.
 
There needs to be a trigger event (this I believe we all also
agreed upon). Some of us believe that the most effective source
for this trigger event is from the link layer (this is the only
way you can actually be proactive, as far as I know). However,
there should not be any design restriction in CTP preventing this
trigger event from being generated from a different source, and
signalled via IP.
 
Rajeev: When the link layer trigger is there, it should be used. Assuming that it will always be there is parochial.
At the IP layer, we should provide this message.
 

Regards,

-Rajeev
 

 
Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, June 15, 2001 1:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication &
> Authorization ...
>
>
>
> Hello Gary,
>
>
> Gary Kenward wrote:
>
> >
> >
> > Kulwinder:
> >
> >   I don't agree with your observation. We did discuss how
> CT was to be
> >
> > initiated, and agreed that there would be no explicit
> signalling from
> > the MN (not at least as far as CT was concerned).
> >
>
> Rajeev: I don't believe that we ever said there would be no explicit
> signaling from the MN!
> In fact, requirement 4.8 (which BTW, must be at least a SHOULD), gives
> the option to the MN to indicate how the feature contexts be handled.
>
> I would have strong objection to this.
>
>
> >
> >   The definition of reactive CT (read the problem
> statement)has to do
> > with
> > the order/timing of events, not with where the initiating
> event comes
> > from.
>
> Rajeev: I don't remember going through reactive CT or proactive CT
> during problem statement phase at all. Nevertheless, where is the
> definition of reactive CT that says a MN cannot initiate signaling ?
>
> Regards,
>
> -Rajeev
>
>
> >
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > Sent: Thursday, June 14, 2001 6:30 PM
> > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat
> > > Calhoun'; Phillip
> > > Neumiller
> > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > "in-the-large"
> > > w as Re: [seamob y] ct problem statement
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > Sent: Thursday, June 14, 2001 6:02 PM
> > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat
> > > > Calhoun'; Phillip
> > > > Neumiller
> > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> > > > Sent: Thursday, June 14, 2001 4:46 PM
> > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller
> > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> > > > wirelessinternet@internet.motlabs.com
> > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > "in-the-large"
> > > > w as Re: [seamob y] ct problem statement
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Nakhjiri Madjid-MNAKHJI1
> > > [mailto:Madjid.Nakhjiri@motorola.com]
> > > > > Sent: Thursday, June 14, 2001 5:09 PM
> > > > > To: 'Pat Calhoun'; Phillip Neumiller
> > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins;
> > > > Kulwinder
> > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com
> > > > > Subject: RE: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > Sent: Wednesday, June 13, 2001 8:29 AM
> > > > > To: Phillip Neumiller
> > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross;
> > Charlie
> > > > > Perkins; Kulwinder Atwal; 'seamoby';
> > > > > wirelessinternet@internet.motlabs.com
> > > > > Subject: Re: [seamoby] RE: Authentication & Authorization
> > > > > "in-the-large"
> > > > > w as Re: [seamob y] ct problem statement
> > > > >
> > > > >
> > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller
> > wrote:
> > > > > > There are companies that build products (WRQ's reflection
> > comes
> > > > > > to mind) that freeze the state of the IP stack
> (gracefully in
> > > > > > the application sense), until the flow of IP traffic can
> > resume.
> > > > > > This is sort of an ultra-slow handover.  I see no
> > > reason why THIS
> > > > > > can not be made seamless with CT.  Why should CT not be
> > capable
> > > > > > of accomodating this Pat?
> > > > >
> > > > > Sure, they could, but what is seamless in this sense? The user
> > has
> > > > > no service for some time, so what is an extra couple of
> > > > seconds while
> > > > > signalling occurs over the air to update the local ARs state??
> > The
> > > > > user would probably not even notice.
> > > > >
> > > > > Actually, you seem to imply something that I am not sure that
> > I've
> > > > > been thinking about that much, which is the mobile
> updating the
> > > > > AR's state. This, btw, can be problematic, since the
> > > mobile doesn't
> > > > > necessarily share an SA with the AR (hence DoS attacks), and a
> > > > > malicious mobile could send bogus (mal-formed) CT
> packets in an
> > > > > attempt to crash (or cause mis-behaving) ARs.
> > > > >
> > > > > Something to think about in the DoS space.
> > > > >
> > > > > MN>> Yes, involving the MN is CT is definitely a whole other
> > > > > ball of wax. As I said earlier the assumption was that the
> > > > CT happens
> > > > > AR to AR and I was exploring the DoSs for that case.
> > > >
> > > >
> > > > > The MN is not authenticated to the newAR, so all kinds of
> > security
> > > > > problems exists until the MN is "properly introduced" to
> > > the newAR.
> > > >
> > > > What do you mean "properly introduced" to the newAR.  The MN
> > > > can certainly
> > > > authenticate to the newAR.  The MN can just show up at the
> > > new AR and
> > > > introduce itself.  It called "Reactive" Context Transfer.
> > > >
> > > > MN>>> Kulwinder, by "properly introduced", I meant to skip
> > > > the security
> > > > details between MN and newAR. Yes, MN can authenticate itself
> > > > to newAR but
> > > > not as part of CT, and for sure not before CT completition,
> > > > especially, if
> > > > the intention of CT was to transfer MN's
> > > > for-AAA-Security-needed context.
> > > >
> > > > I don't think reactive context transfer was meant to be
> > > > initiated by MN and
> > > > definitely not after "MN's introduction itself to newAR".
> > >
> > > Of course it was intended.  Read the Archive.  If the MN is
> > switching
> > > between wireless and wired, _as_stated_in_our_charter_, there
> > > is no other
> > > way other than MN initiated CT.
> > >
> > > What do you expect will happen when an MN loses connectivity
> > > between ARs and
> > > just shows up at the newAR?  Do you _really_ expect the
> > > End-User to drive
> > > back during Rush Hour to the oldAR and try again?
> > >
> > > > What does this
> > > > introduction mean in context of "context transfer" anyway. If
> > > > CT is supposed
> > > > to happen between ARs, where does this introduction come in?
> > > > Unless you are
> > > > talking about an L2 connectivity signal or even an L2
> > > > authentication (which
> > > > is not very fast!!!).
> > > > The scenario is an AR-AR CT, then an MN-newAR authentication
> > (proper
> > > > introduction)
> > > > based on transferred credential after CT is complete.
> > >
> > > How does the newAR even know that the MN has arrived if the
> > > MN does not
> > > annouce itself?  Why should the newAR waste time doing a CT
> > > for an MN that
> > > is not authorized?  Sounds like an opportunity for a DOS
> > > attack.  Authorize
> > > first.  Then do CT.  Especially for an MN that has arrived
> > > unannouced at the
> > > newAR due to a service disruption will moving between ARs.
> > >
> > > - Kulwinder.
> > >
> > > >
> > > > The preferred case, of course, is when the oldAR transfers
> > > > trust to the
> > > > newAR.
> > > >
> > > > MN>> Of course. That is why I mentioned "properly introduced"
> > > >
> > > > But, certainly we must consider the case of an MN just
> > > > showing up at the
> > > > newAR.  The newAR is then faced with finding out where the
> > > MN was last
> > > > attached and invalidating the oldSA.  The MN has to present a
> > > > credential to
> > > > the newAR that the oldAR will accept as valid.
> > > >
> > > > MN>> Yes, but that is not where CT helps, you are out of the
> > > > CT-is-an-optimization
> > > > territory. MN does a lot of negotiations for establishing
> > > the context
> > > > anyway.
> > > >
> > > > BTW, I just noticed that my initials and acronym for Mobile
> > > > Node are the
> > > > same :(
> > > > "MN>> means I am talking :)
> > > >
> > > > Madjid
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Madjid
> > > > >
> > > > > PatC
> > > > >
> > > >
> > >
>
>

--------------BBDE967868364E283FAE9F72-- From owner-seamoby@diameter.org Mon Jun 18 17:08: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 RAA21234 for ; Mon, 18 Jun 2001 17:08:34 -0400 (EDT) Received: (qmail 10198 invoked by alias); 18 Jun 2001 20:46:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10192 invoked by uid 200); 18 Jun 2001 20:46:32 -0000 Received: (qmail 10182 invoked from network); 18 Jun 2001 20:46:27 -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; 18 Jun 2001 20:46:27 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5IKuI023058 for ; Mon, 18 Jun 2001 16:56:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 18 Jun 2001 16:56:15 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 16:56:17 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: seamoby@diameter.org Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Mon, 18 Jun 2001 16:56:13 -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 Rajeev: The current requirements in no way prohibit signalling from the MN. Myself and others have re-iterated this many times on the list. o the trigger arrives at an AR at L3; the source is not specified, and considered out of scope for CT. o CT must provide the mechanisms to allow per microflow enable/disable; the control protocols are not specified and considered out of scope for CT. Nothing you have said contradicts the above requirements. The only issue seems to be that you and others want an explicit requirement so that the design task for these protocols are explicitly part of CT. This would mean not only that we will have to add MN signalling, but also signalling from other sources, including L2 (?). Sounds like a lot of effort to me, and the solutions could unnecessarily constrain CT. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Monday, June 18, 2001 2:32 PM > To: James Kempf > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > [WDLN2:AN10:EXCH]; seamoby@diameter.org > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > > > Hello James, > > James Kempf wrote: > > > Rajeev, > > > > I don't think we can require L3 triggering in all cases. We need > > > > Rajeev: Unfortunately, I think we cannot require that the MN > do L2 triggering > in all cases as well. > > > to make sure that an MN not need to do L3 triggering, otherwise, > > as Gary points out, performance will suffer. > > Rajeev: yes in some links, may be (or no impact) in others. > > > > If there's an L2 trigger, > > it should be used preferentially. > > Rajeev: certainly. It is one thing to say that if there is a > L2 trigger, it > should be used preferentially, but another thing to say that > we disallow using > L3 messages to trigger CT. We should have the possibility of > MN requesting CT. > > Regards, > > -Rajeev > > > > > > > > jak > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > Valley Messaging > > Protection > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > >From: Rajeev Koodli > > >To: Singh Ajoy-ASINGH1 > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > , "'seamoby'" > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > > Authorization ... > > > > > > > > >Hello Ajoy, > > > > > >whereas use of link-layer triggers is very useful, it is > not something we > > >can rely upon to be present everywhere (as you correctly > point out for > > >Inter-technology handovers). I don't think we ever said we > disallow link > > >layer triggers. We must not say that that's our solution. > At the IP layer, > > >we need to define IP messages. I think we pretty much agree. > > > > > >Regards, > > > > > >-Rajeev > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > >> I think it is possible to receive link layer trigger at the new > > >> access router which can be used to initiate context transfer. > > >> This will be mostly useful in case of some intra-technology > > >> handovers. In case MN moves across different technologies, yes > > >> some sort of MN trigger is useful. Having said that is it a > > >> good idea to limit the scope of CT protocol? I think we > > >> should allow both the options. > > >> regards, > > >> ajoy > > >> > > [snip, snip] > > From owner-seamoby@diameter.org Mon Jun 18 17:13: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 RAA21429 for ; Mon, 18 Jun 2001 17:13:37 -0400 (EDT) Received: (qmail 10213 invoked by alias); 18 Jun 2001 20:46:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10207 invoked by uid 200); 18 Jun 2001 20:46:34 -0000 Received: (qmail 10181 invoked from network); 18 Jun 2001 20:46:27 -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; 18 Jun 2001 20:46:27 -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 f5IKuK023068 for ; Mon, 18 Jun 2001 16:56:20 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 18 Jun 2001 16:56:14 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 16:56:17 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Cc: seamoby@diameter.org Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Mon, 18 Jun 2001 16:56:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F839.1C568370" 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_01C0F839.1C568370 Content-Type: text/plain; charset="iso-8859-1" Rajeev: The current requirements in no way prohibit signalling from the MN. Myself and others have re-iterated this many times on the list. o the trigger arrives at an AR at L3; the source is not specified, and considered out of scope for CT. o CT must provide the mechanisms to allow per microflow enable/disable; the control protocols are not specified and considered out of scope for CT. Nothing you have said contradicts the above requirements. The only issue seems to be that you and others want an explicit requirement so that the design task for these protocols are explicitly part of CT. This would mean not only that we will have to add MN signalling, but also signalling from other sources, including L2 (?). Sounds like a lot of effort to me, and the solutions could unnecessarily constrain CT. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Monday, June 18, 2001 2:32 PM > To: James Kempf > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > [WDLN2:AN10:EXCH]; seamoby@diameter.org > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > > > Hello James, > > James Kempf wrote: > > > Rajeev, > > > > I don't think we can require L3 triggering in all cases. We need > > > > Rajeev: Unfortunately, I think we cannot require that the MN > do L2 triggering > in all cases as well. > > > to make sure that an MN not need to do L3 triggering, otherwise, > > as Gary points out, performance will suffer. > > Rajeev: yes in some links, may be (or no impact) in others. > > > > If there's an L2 trigger, > > it should be used preferentially. > > Rajeev: certainly. It is one thing to say that if there is a > L2 trigger, it > should be used preferentially, but another thing to say that > we disallow using > L3 messages to trigger CT. We should have the possibility of > MN requesting CT. > > Regards, > > -Rajeev > > > > > > > > jak > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > Valley Messaging > > Protection > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > >From: Rajeev Koodli > > >To: Singh Ajoy-ASINGH1 > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > , "'seamoby'" > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & > > Authorization ... > > > > > > > > >Hello Ajoy, > > > > > >whereas use of link-layer triggers is very useful, it is > not something we > > >can rely upon to be present everywhere (as you correctly > point out for > > >Inter-technology handovers). I don't think we ever said we > disallow link > > >layer triggers. We must not say that that's our solution. > At the IP layer, > > >we need to define IP messages. I think we pretty much agree. > > > > > >Regards, > > > > > >-Rajeev > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > >> I think it is possible to receive link layer trigger at the new > > >> access router which can be used to initiate context transfer. > > >> This will be mostly useful in case of some intra-technology > > >> handovers. In case MN moves across different technologies, yes > > >> some sort of MN trigger is useful. Having said that is it a > > >> good idea to limit the scope of CT protocol? I think we > > >> should allow both the options. > > >> regards, > > >> ajoy > > >> > > [snip, snip] > > ------_=_NextPart_001_01C0F839.1C568370 Content-Type: text/html; charset="iso-8859-1" RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ...

Rajeev:

  The current requirements in no way prohibit signalling from the MN.
Myself and others have re-iterated this many times on the list.

  o the trigger arrives at an AR at L3; the source is not specified,
    and considered out of scope for CT.

  o CT must provide the mechanisms to allow per microflow enable/disable;
    the control protocols are not specified and considered out of scope for CT.

  Nothing you have said contradicts the above requirements. The only issue
seems to be that you and others want an explicit requirement so that the design
task for these protocols are explicitly part of CT. This would mean not only that
we will have to add MN signalling, but also signalling from other sources, including
L2 (?). Sounds like a lot of effort to me, and the solutions could unnecessarily
constrain CT.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Monday, June 18, 2001 2:32 PM
> To: James Kempf
> Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary
> [WDLN2:AN10:EXCH]; seamoby@diameter.org
> Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication & Authorization ...
>
>
>
> Hello James,
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I don't think we can require L3 triggering in all cases. We need
> >
>
> Rajeev: Unfortunately, I think we cannot require that the MN
> do L2 triggering
> in all cases as well.
>
> > to make sure that an MN not need to do L3 triggering, otherwise,
> > as Gary points out, performance will suffer.
>
> Rajeev: yes in some links, may be (or no impact) in others.
>
>
> > If there's an L2 trigger,
> > it should be used preferentially.
>
> Rajeev: certainly. It is one thing to say that if there is a
> L2 trigger, it
> should be used preferentially, but another thing to say that
> we disallow using
> L3 messages to trigger CT. We should have the possibility of
> MN requesting CT.
>
> Regards,
>
> -Rajeev
>
>
> >
> >
> >                 jak
> >
> > >Delivered-To: seamoby-list@charizard.diameter.org
> > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon
> Valley Messaging
> > Protection
> > >Date: Fri, 15 Jun 2001 11:59:37 -0700
> > >From: Rajeev Koodli <rajeev@IPRG.nokia.com>
> > >To: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
> > >CC: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, Gary Kenward
> > <gkenward@nortelnetworks.com>, "'seamoby'" <seamoby@diameter.org>
> > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE:
> Authentication &
> > Authorization ...
> > >
> > >
> > >Hello Ajoy,
> > >
> > >whereas use of link-layer triggers is very useful, it is
> not something we
> > >can rely upon to be present everywhere (as you correctly
> point out for
> > >Inter-technology handovers). I don't think we ever said we
> disallow link
> > >layer triggers. We must not say that that's our solution.
> At the IP layer,
> > >we need to define IP messages. I think we pretty much agree.
> > >
> > >Regards,
> > >
> > >-Rajeev
> > >
> > >
> > >Singh Ajoy-ASINGH1 wrote:
> > >
> > >> I think it is possible to receive link layer trigger at the new
> > >> access router which can be used to initiate context transfer.
> > >> This will be mostly useful in case of some intra-technology
> > >> handovers. In case MN moves across different technologies, yes
> > >> some sort of MN trigger is useful. Having said that is it a
> > >> good idea to limit the scope of CT protocol? I think we
> > >> should allow both the options.
> > >> regards,
> > >> ajoy
> > >>
>
> [snip, snip]
>
>

------_=_NextPart_001_01C0F839.1C568370-- From owner-seamoby@diameter.org Mon Jun 18 17:19: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 RAA21512 for ; Mon, 18 Jun 2001 17:19:32 -0400 (EDT) Received: (qmail 10413 invoked by alias); 18 Jun 2001 20:51:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10407 invoked by uid 200); 18 Jun 2001 20:51:58 -0000 Received: (qmail 10402 invoked by uid 500); 18 Jun 2001 20:51:57 -0000 Date: Mon, 18 Jun 2001 13:51:57 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Message-ID: <20010618135157.Z17928@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5D49@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: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Mon, Jun 18, 2001 at 04:56:13PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk Rajeev, I believe I've already asked for this, but let me try again. Could you please provide me with an example of when this would be necessary? Some justification would be useful in my mind. PatC On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote: > Rajeev: > > The current requirements in no way prohibit signalling from the MN. > Myself and others have re-iterated this many times on the list. > > o the trigger arrives at an AR at L3; the source is not specified, > and considered out of scope for CT. > > o CT must provide the mechanisms to allow per microflow enable/disable; > the control protocols are not specified and considered out of scope for > CT. > > Nothing you have said contradicts the above requirements. The only issue > seems to be that you and others want an explicit requirement so that the > design > task for these protocols are explicitly part of CT. This would mean not only > that > we will have to add MN signalling, but also signalling from other sources, > including > L2 (?). Sounds like a lot of effort to me, and the solutions could > unnecessarily > constrain CT. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Monday, June 18, 2001 2:32 PM > > To: James Kempf > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & Authorization ... > > > > > > > > Hello James, > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > do L2 triggering > > in all cases as well. > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > as Gary points out, performance will suffer. > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > If there's an L2 trigger, > > > it should be used preferentially. > > > > Rajeev: certainly. It is one thing to say that if there is a > > L2 trigger, it > > should be used preferentially, but another thing to say that > > we disallow using > > L3 messages to trigger CT. We should have the possibility of > > MN requesting CT. > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > jak > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > Valley Messaging > > > Protection > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > >From: Rajeev Koodli > > > >To: Singh Ajoy-ASINGH1 > > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > > , "'seamoby'" > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & > > > Authorization ... > > > > > > > > > > > >Hello Ajoy, > > > > > > > >whereas use of link-layer triggers is very useful, it is > > not something we > > > >can rely upon to be present everywhere (as you correctly > > point out for > > > >Inter-technology handovers). I don't think we ever said we > > disallow link > > > >layer triggers. We must not say that that's our solution. > > At the IP layer, > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > >> access router which can be used to initiate context transfer. > > > >> This will be mostly useful in case of some intra-technology > > > >> handovers. In case MN moves across different technologies, yes > > > >> some sort of MN trigger is useful. Having said that is it a > > > >> good idea to limit the scope of CT protocol? I think we > > > >> should allow both the options. > > > >> regards, > > > >> ajoy > > > >> > > > > [snip, snip] > > > > From owner-seamoby@diameter.org Mon Jun 18 17:23: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 RAA21577 for ; Mon, 18 Jun 2001 17:23:14 -0400 (EDT) Received: (qmail 10569 invoked by alias); 18 Jun 2001 20:55:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10561 invoked by uid 200); 18 Jun 2001 20:55:46 -0000 Received: (qmail 10548 invoked from network); 18 Jun 2001 20:55:40 -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; 18 Jun 2001 20:55:40 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5IL5g024276 for ; Mon, 18 Jun 2001 17:05:42 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 18 Jun 2001 17:05:35 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 17:05:36 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D4B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'seamoby'" Cc: "'seamoby-context'" Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context transfe r] Date: Mon, 18 Jun 2001 17:05:30 -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 Phil: It's not my decision. I'm just expressing my point of view. If you were expecting to convince me to change the requirements, that isn't going to happen. I'm just the editor. You might be able to convince me, but you have to convince the wg, not just me. Pat's put into place a formal process for identifying issues. I suggest you follow that procedure and see what the wg says. One thought: if you can capture all the MANET specific requirements and post them, perhaps, after the usual discussion and consensus, we can include them as MANET specific requirements. This would satisfy me, as I don't want to forget the all-wireless solution, but I would like to keep the discussions separate. Does this make sense? Regards, Gary -----Original Message----- From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Monday, June 18, 2001 4:56 PM To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context transfe r] Gary, I guess at this point I am just flustered. It appears that I am unable to make my points (at least in a reasonable amount of time). So I will just say that the requirements are fine, except for the fact that they don't even begin to address MANET-ish architecture issues at this time. I don't want to impede progress, so please feel free to ignore this thread and continue on with the submission. Thanks, Phil -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Monday, June 18, 2001 4:49 PM To: seamoby-context@cdma-2000.org Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context transfe r] The real problem here, Phil, is the mixing of MANET requirements with access network requirements. In an access network scenario, there are *many* reasons to keep the complexity and overhead within the access network. The major one being the availability of bandwidth, and the typically lower latencies within the access network. The cost (in terms of $$$, size, power) of putting a function at the MN for an access network scenario is, in general, always greater then the cost of putting the same function in the network itself. Now, for an all-wireless network, you have no choice, and so MRs must CT across wireless channels. I would still tend to believe that it would be worthwhile to keep the MH separate from the MR functionality (at the very least, for the sake of generality), and it is always better to keep complexity and cost to a minimum at the MH (I've worked for device manufacturers too). Does this help? Gary > -----Original Message----- > From: Phillip Neumiller [ mailto:PNeumiller@MeshNetworks.com ] > Sent: Monday, June 18, 2001 3:15 PM > To: 'Kulwinder Atwal'; Phillip Neumiller; 'Pat Calhoun' > Cc: Syed, Hamid [WDLN2:AN22:EXCH]; Kenward, Gary [WDLN2:AN10:EXCH]; > Rajeev Koodli; charliep@IPRG.nokia.com; seamoby-context@cdma-2000.org > Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context > transfe r] > > > Then why does Gary believe it is not possible? I am confused. > Seems that Kulwinder and Gary are contradicting each other about > the same requirements. Can one of you explain? > > > -----Original Message----- > > From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com ] > > Sent: Monday, June 18, 2001 3:04 PM > > To: 'Phillip Neumiller'; Kulwinder Atwal; 'Pat Calhoun' > > Cc: 'Hamid Syed'; Gary Kenward; Rajeev Koodli; > > charliep@IPRG.nokia.com; > > seamoby-context@cdma-2000.org > > Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context > > transfe r] > > > > > > > > > > > -----Original Message----- > > > From: Phillip Neumiller [ mailto:PNeumiller@meshnetworks.com ] > > > Sent: Monday, June 18, 2001 2:48 PM > > > To: 'Kulwinder Atwal'; Phillip Neumiller; 'Pat Calhoun' > > > Cc: 'Hamid Syed'; Gary Kenward; Rajeev Koodli; > > > charliep@IPRG.nokia.com; > > > seamoby-context@cdma-2000.org > > > Subject: RE: [seamoby-context] Re: [RE: [seamoby] Reactive context > > > transfe r] > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com ] > > > > > > > > I believe making it explicit will almost guarrantee a > > > > religous holy war on > > > > the best MANET approach on the main Seamoby list. > > > > > > > Huh? I don't think MANET folks get into holy wars for one. > > > > > > > > > > I think we have done what Allison Mankin requested. Provide > > > > a 'Tool Kit' > > > > for ANY routing protocol to use. > > > > > > > > Are there specific requirements that are missing? > > > > > > > Yes lots of MANET requirements, but everytime I try to bring > > > up the most basic ones I get some kind of push back from you > > > Kulwinder. I am not sure why. Also, to answer Gary's question, > > > MN's MUST be able to accept and send context. I can give at > > > least a six reasons off the top of my head. > > > > > > 1). They may be routers. > > > 2). They may be gateways. > > > 3). They may have multiple active link layers. > > > 4). They may be transitiioning from fixed to wireless or > > vice versa. > > > 5). They may use CT information in handoff decisions. > > > 6). They may use CT information in routing decisions. > > > > > > > The current CT Protocol requirements + Mobile Router > Protocol + Router > > Discovery Protocol, I believe can handle ALL of these scenerios. > > > > If you don't think so, show me. > > > > - Kulwinder. > > > > > From owner-seamoby@diameter.org Mon Jun 18 17:41: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 RAA21828 for ; Mon, 18 Jun 2001 17:41:04 -0400 (EDT) Received: (qmail 12867 invoked by alias); 18 Jun 2001 21:27:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12861 invoked by uid 200); 18 Jun 2001 21:27:18 -0000 Received: (qmail 12856 invoked from network); 18 Jun 2001 21:27:16 -0000 Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jun 2001 21:27:16 -0000 Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f5ILkk928194; Mon, 18 Jun 2001 14:46:46 -0700 (PDT) Date: Mon, 18 Jun 2001 14:46:46 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: Rajeev Koodli cc: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... In-Reply-To: <3B2E6954.CFAC2480@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Rajeev, I feel as if this L2/L3 and triggering business is still in mysterious clouds. I'm also in the favor of providing some sort of L3 triggering being necessary. I agree that the L2 is extremely handy in terms of speed and efficiency, the L2 is only effective upon its availability. I'm not sure if it is a desired approach to assume the L2 triggering is present and available all the time, neither can it be universally specified considering it is like a flood of air-interface standards available. Is it sufficient for the L2 to successfully encapsulate all the L3 context? Anyhow, I'm currently preparing a draft which in some cases may be related to this discussion. It regards handoff triggering and L2/L3 interaction - movement detection/prediction, candidate agent/router discovery, and signaling issues. Youngjune On Mon, 18 Jun 2001, Rajeev Koodli wrote: > > For what it is worth.. > > Gary Kenward wrote: > > > > > > > How can I clarify this: the decision was not to "exclude" > > MN triggering, the decision was to exclude layer 3 signalling > > from the MN as part of CTP. > > > > Rajeev: That's the point. The MN may request CT using an IP message. > > > > > There needs to be a trigger event (this I believe we all also > > agreed upon). Some of us believe that the most effective source > > for this trigger event is from the link layer (this is the only > > way you can actually be proactive, as far as I know). However, > > there should not be any design restriction in CTP preventing this > > trigger event from being generated from a different source, and > > signalled via IP. > > > > Rajeev: When the link layer trigger is there, it should be used. > Assuming that it will always be there is parochial. > At the IP layer, we should provide this message. > > > Regards, > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, June 15, 2001 1:30 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'seamoby' > > > Subject: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & > > > Authorization ... > > > > > > > > > > > > Hello Gary, > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Kulwinder: > > > > > > > > I don't agree with your observation. We did discuss how > > > CT was to be > > > > > > > > initiated, and agreed that there would be no explicit > > > signalling from > > > > the MN (not at least as far as CT was concerned). > > > > > > > > > > Rajeev: I don't believe that we ever said there would be no explicit > > > > > signaling from the MN! > > > In fact, requirement 4.8 (which BTW, must be at least a SHOULD), > > gives > > > the option to the MN to indicate how the feature contexts be > > handled. > > > > > > I would have strong objection to this. > > > > > > > > > > > > > > The definition of reactive CT (read the problem > > > statement)has to do > > > > with > > > > the order/timing of events, not with where the initiating > > > event comes > > > > from. > > > > > > Rajeev: I don't remember going through reactive CT or proactive CT > > > during problem statement phase at all. Nevertheless, where is the > > > definition of reactive CT that says a MN cannot initiate signaling ? > > > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > > Sent: Thursday, June 14, 2001 6:30 PM > > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Pat > > > > > Calhoun'; Phillip > > > > > Neumiller > > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > "in-the-large" > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > Sent: Thursday, June 14, 2001 6:02 PM > > > > > > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat > > > > > > Calhoun'; Phillip > > > > > > Neumiller > > > > > > Cc: 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > > > > > Sent: Thursday, June 14, 2001 4:46 PM > > > > > > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip > > Neumiller > > > > > > Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby'; > > > > > > wirelessinternet@internet.motlabs.com > > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > > "in-the-large" > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > > Sent: Thursday, June 14, 2001 5:09 PM > > > > > > > To: 'Pat Calhoun'; Phillip Neumiller > > > > > > > Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; > > > > > > Kulwinder > > > > > > > Atwal; 'seamoby'; wirelessinternet@internet.motlabs.com > > > > > > > Subject: RE: [seamoby] RE: Authentication & Authorization > > > > > > > "in-the-large" > > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > > > > Sent: Wednesday, June 13, 2001 8:29 AM > > > > > > > To: Phillip Neumiller > > > > > > > Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; > > > > Charlie > > > > > > > Perkins; Kulwinder Atwal; 'seamoby'; > > > > > > > wirelessinternet@internet.motlabs.com > > > > > > > Subject: Re: [seamoby] RE: Authentication & Authorization > > > > > > > "in-the-large" > > > > > > > w as Re: [seamob y] ct problem statement > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 13, 2001 at 09:13:09AM -0400, Phillip Neumiller > > > > wrote: > > > > > > > > There are companies that build products (WRQ's reflection > > > > comes > > > > > > > > to mind) that freeze the state of the IP stack > > > (gracefully in > > > > > > > > the application sense), until the flow of IP traffic can > > > > resume. > > > > > > > > This is sort of an ultra-slow handover. I see no > > > > > reason why THIS > > > > > > > > can not be made seamless with CT. Why should CT not be > > > > capable > > > > > > > > of accomodating this Pat? > > > > > > > > > > > > > > Sure, they could, but what is seamless in this sense? The > > user > > > > has > > > > > > > no service for some time, so what is an extra couple of > > > > > > seconds while > > > > > > > signalling occurs over the air to update the local ARs > > state?? > > > > The > > > > > > > user would probably not even notice. > > > > > > > > > > > > > > Actually, you seem to imply something that I am not sure > > that > > > > I've > > > > > > > been thinking about that much, which is the mobile > > > updating the > > > > > > > AR's state. This, btw, can be problematic, since the > > > > > mobile doesn't > > > > > > > necessarily share an SA with the AR (hence DoS attacks), and > > a > > > > > > > malicious mobile could send bogus (mal-formed) CT > > > packets in an > > > > > > > attempt to crash (or cause mis-behaving) ARs. > > > > > > > > > > > > > > Something to think about in the DoS space. > > > > > > > > > > > > > > MN>> Yes, involving the MN is CT is definitely a whole other > > > > > > > > > ball of wax. As I said earlier the assumption was that the > > > > > > CT happens > > > > > > > AR to AR and I was exploring the DoSs for that case. > > > > > > > > > > > > > > > > > > > The MN is not authenticated to the newAR, so all kinds of > > > > security > > > > > > > problems exists until the MN is "properly introduced" to > > > > > the newAR. > > > > > > > > > > > > What do you mean "properly introduced" to the newAR. The MN > > > > > > can certainly > > > > > > authenticate to the newAR. The MN can just show up at the > > > > > new AR and > > > > > > introduce itself. It called "Reactive" Context Transfer. > > > > > > > > > > > > MN>>> Kulwinder, by "properly introduced", I meant to skip > > > > > > the security > > > > > > details between MN and newAR. Yes, MN can authenticate itself > > > > > > to newAR but > > > > > > not as part of CT, and for sure not before CT completition, > > > > > > especially, if > > > > > > the intention of CT was to transfer MN's > > > > > > for-AAA-Security-needed context. > > > > > > > > > > > > I don't think reactive context transfer was meant to be > > > > > > initiated by MN and > > > > > > definitely not after "MN's introduction itself to newAR". > > > > > > > > > > Of course it was intended. Read the Archive. If the MN is > > > > switching > > > > > between wireless and wired, _as_stated_in_our_charter_, there > > > > > is no other > > > > > way other than MN initiated CT. > > > > > > > > > > What do you expect will happen when an MN loses connectivity > > > > > between ARs and > > > > > just shows up at the newAR? Do you _really_ expect the > > > > > End-User to drive > > > > > back during Rush Hour to the oldAR and try again? > > > > > > > > > > > What does this > > > > > > introduction mean in context of "context transfer" anyway. If > > > > > > CT is supposed > > > > > > to happen between ARs, where does this introduction come in? > > > > > > Unless you are > > > > > > talking about an L2 connectivity signal or even an L2 > > > > > > authentication (which > > > > > > is not very fast!!!). > > > > > > The scenario is an AR-AR CT, then an MN-newAR authentication > > > > (proper > > > > > > introduction) > > > > > > based on transferred credential after CT is complete. > > > > > > > > > > How does the newAR even know that the MN has arrived if the > > > > > MN does not > > > > > annouce itself? Why should the newAR waste time doing a CT > > > > > for an MN that > > > > > is not authorized? Sounds like an opportunity for a DOS > > > > > attack. Authorize > > > > > first. Then do CT. Especially for an MN that has arrived > > > > > unannouced at the > > > > > newAR due to a service disruption will moving between ARs. > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > The preferred case, of course, is when the oldAR transfers > > > > > > trust to the > > > > > > newAR. > > > > > > > > > > > > MN>> Of course. That is why I mentioned "properly introduced" > > > > > > > > > > > > But, certainly we must consider the case of an MN just > > > > > > showing up at the > > > > > > newAR. The newAR is then faced with finding out where the > > > > > MN was last > > > > > > attached and invalidating the oldSA. The MN has to present a > > > > > > credential to > > > > > > the newAR that the oldAR will accept as valid. > > > > > > > > > > > > MN>> Yes, but that is not where CT helps, you are out of the > > > > > > CT-is-an-optimization > > > > > > territory. MN does a lot of negotiations for establishing > > > > > the context > > > > > > anyway. > > > > > > > > > > > > BTW, I just noticed that my initials and acronym for Mobile > > > > > > Node are the > > > > > > same :( > > > > > > "MN>> means I am talking :) > > > > > > > > > > > > Madjid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Madjid > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Mon Jun 18 20:30: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 UAA25104 for ; Mon, 18 Jun 2001 20:30:03 -0400 (EDT) Received: (qmail 16867 invoked by alias); 19 Jun 2001 00:14:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16859 invoked by uid 200); 19 Jun 2001 00:14:14 -0000 Received: (qmail 16852 invoked by uid 500); 19 Jun 2001 00:14:12 -0000 Date: Mon, 18 Jun 2001 17:14:12 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] New CT Issues web page available Message-ID: <20010618171412.E17928@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 new CT requirements issues web page is now available at http://www.diameter.org/seamoby-ct-issues.html, and the WG web site, http://www.diameter.org/seamoby.html has been updated to reflect the current changes in the WG. As previously discussed, anyone that wishes to proposed changes to the version 00 of the specification that Gary is sending to the secretariat must fill out an issue, and submit it to the mailing list. Thanks, PatC From owner-seamoby@diameter.org Tue Jun 19 00:17: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 AAA00006 for ; Tue, 19 Jun 2001 00:17:01 -0400 (EDT) Received: (qmail 19520 invoked by alias); 19 Jun 2001 04:04:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19514 invoked by uid 200); 19 Jun 2001 04:04:53 -0000 Received: (qmail 19506 invoked from network); 19 Jun 2001 04:04:51 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 04:04:51 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 00:15:12 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8031@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Gary Kenward Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Tue, 19 Jun 2001 00:15:11 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, June 18, 2001 4:52 PM > To: Gary Kenward > Cc: 'seamoby' > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > > Rajeev, > > I believe I've already asked for this, but let me try again. > > Could you please provide me with an example of when this would be > necessary? Some justification would be useful in my mind. 1. NewAR requests that MN Context be transferred because MN has arrived at newAR unannouced. 2. An Entity in the Network wishes to balance the network load between a group of ARs. 3. An MN requests a change in access technology. The same set of messages can be used for all three cases. - Kulwinder. > > PatC > On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote: > > Rajeev: > > > > The current requirements in no way prohibit signalling > from the MN. > > Myself and others have re-iterated this many times on the list. > > > > o the trigger arrives at an AR at L3; the source is not specified, > > and considered out of scope for CT. > > > > o CT must provide the mechanisms to allow per microflow > enable/disable; > > the control protocols are not specified and considered > out of scope for > > CT. > > > > Nothing you have said contradicts the above requirements. > The only issue > > seems to be that you and others want an explicit > requirement so that the > > design > > task for these protocols are explicitly part of CT. This > would mean not only > > that > > we will have to add MN signalling, but also signalling from > other sources, > > including > > L2 (?). Sounds like a lot of effort to me, and the solutions could > > unnecessarily > > constrain CT. > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Monday, June 18, 2001 2:32 PM > > > To: James Kempf > > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; > Kenward, Gary > > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & Authorization ... > > > > > > > > > > > > Hello James, > > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > > do L2 triggering > > > in all cases as well. > > > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > > as Gary points out, performance will suffer. > > > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > > > > If there's an L2 trigger, > > > > it should be used preferentially. > > > > > > Rajeev: certainly. It is one thing to say that if there is a > > > L2 trigger, it > > > should be used preferentially, but another thing to say that > > > we disallow using > > > L3 messages to trigger CT. We should have the possibility of > > > MN requesting CT. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > > Valley Messaging > > > > Protection > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > > >From: Rajeev Koodli > > > > >To: Singh Ajoy-ASINGH1 > > > > >CC: "'Kulwinder Atwal'" , > Gary Kenward > > > > , "'seamoby'" > > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & > > > > Authorization ... > > > > > > > > > > > > > > >Hello Ajoy, > > > > > > > > > >whereas use of link-layer triggers is very useful, it is > > > not something we > > > > >can rely upon to be present everywhere (as you correctly > > > point out for > > > > >Inter-technology handovers). I don't think we ever said we > > > disallow link > > > > >layer triggers. We must not say that that's our solution. > > > At the IP layer, > > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > > > >Regards, > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > >> I think it is possible to receive link layer trigger > at the new > > > > >> access router which can be used to initiate context transfer. > > > > >> This will be mostly useful in case of some intra-technology > > > > >> handovers. In case MN moves across different > technologies, yes > > > > >> some sort of MN trigger is useful. Having said that is it a > > > > >> good idea to limit the scope of CT protocol? I think we > > > > >> should allow both the options. > > > > >> regards, > > > > >> ajoy > > > > >> > > > > > > [snip, snip] > > > > > > > From owner-seamoby@diameter.org Tue Jun 19 02:02: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 CAA07073 for ; Tue, 19 Jun 2001 02:02:21 -0400 (EDT) Received: (qmail 20338 invoked by alias); 19 Jun 2001 05:50:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20332 invoked by uid 200); 19 Jun 2001 05:50:43 -0000 Received: (qmail 20327 invoked from network); 19 Jun 2001 05:50:42 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 05:50:42 -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 f5J61lb23524 for ; Tue, 19 Jun 2001 09:01:47 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 19 Jun 2001 09:01:24 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 19 Jun 2001 09:01:24 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B121@eseis04nok> From: john.loughney@nokia.com To: hmsyed@nortelnetworks.com Cc: seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 09:01:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Hamid, All right. Let me suggest the following requirements plus the description part and see if we can get a consensus on it. 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. While this is a noble goal, in practice I think that this will be a hard one to fufill. (Please interpret this meaning that I support this work, but think it will be very hard to do. I'd suggest it as a seperate work item.) Rather than MUST, I suggest we change this to SHOULD. I'd suggest the following: 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to initiate context transfer. 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate context transfer. 4.4 Context transfer SHOULD separate the signaling to initiate Context Transfer from the transfer of context. 4.3 is added for completeness. 4.4 is a SHOULD I think. What is the need for seperating signaling and transfer of context? If I am an AR, and I get a message 'Here is new header compression state for mobile node x' - I might be able to think that means that mobile node x is going to be coming to me soon ... best regards, John 4 From owner-seamoby@diameter.org Tue Jun 19 02:47: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 CAA14721 for ; Tue, 19 Jun 2001 02:46:59 -0400 (EDT) Received: (qmail 20863 invoked by alias); 19 Jun 2001 06:35:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20857 invoked by uid 200); 19 Jun 2001 06:35:49 -0000 Received: (qmail 20852 invoked from network); 19 Jun 2001 06:35:47 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 06:35:47 -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 f5J6kpm06609 for ; Tue, 19 Jun 2001 09:46:52 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 19 Jun 2001 09:46:37 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 19 Jun 2001 09:46:37 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B127@eseis04nok> From: john.loughney@nokia.com To: seamoby@cdma-2000.org Subject: [seamoby] Requirements language, from 50,000 ft Date: Tue, 19 Jun 2001 09:46:34 +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, A VERY general comment about some of the language used in the CT Requirements document. There is a big difference between the following two statements: 1) Context transfer MUST be reliable. 2) Context transfer MUST support reliable transport. -- or -- 1) Context transfer MUST be secure. 2) Context transfer MUST support secure transport. I just picked these two off the top of my head. These don't correspond to exact language in the CT Requirements draft, because I didn't want to argue specific techical points, but just wanted to bring an issue forward. Since we have yet to design a CT protocol or evaluate existing protocols, I think statements along the lines of 'MUST be ...' are dangerous, because they will limit protocol design. Going forward, I'd suggest we consider carefully what we mean with some of the requirement statements. A lot of the back-and-forth on the mailing list w.r.t. specific requirements can be avoided by choosing our words well. best regards, John From owner-seamoby@diameter.org Tue Jun 19 09:14: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 JAA20702 for ; Tue, 19 Jun 2001 09:14:22 -0400 (EDT) Received: (qmail 23640 invoked by alias); 19 Jun 2001 12:42:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23633 invoked by uid 200); 19 Jun 2001 12:42:28 -0000 Received: (qmail 23627 invoked by uid 500); 19 Jun 2001 12:42:26 -0000 Date: Tue, 19 Jun 2001 05:42:26 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] Requirements language, from 50,000 ft Message-ID: <20010619054226.I17928@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, seamoby@cdma-2000.org References: <01D91AFB08B6D211BFD00008C7EABAE10680B127@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680B127@eseis04nok>; from john.loughney@nokia.com on Tue, Jun 19, 2001 at 09:46:34AM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk Please open up an issue for these, and we can resolve them quickly in the next couple of weeks. PatC On Tue, Jun 19, 2001 at 09:46:34AM +0300, john.loughney@nokia.com wrote: > Hi all, > > A VERY general comment about some of the language used in the CT > Requirements document. There is a big difference between the > following two statements: > > 1) Context transfer MUST be reliable. > 2) Context transfer MUST support reliable transport. > > -- or -- > > 1) Context transfer MUST be secure. > 2) Context transfer MUST support secure transport. > > I just picked these two off the top of my head. These don't > correspond to exact language in the CT Requirements draft, > because I didn't want to argue specific techical points, but > just wanted to bring an issue forward. > > Since we have yet to design a CT protocol or evaluate > existing protocols, I think statements along the lines > of 'MUST be ...' are dangerous, because they will limit > protocol design. > > Going forward, I'd suggest we consider carefully what we > mean with some of the requirement statements. A lot of > the back-and-forth on the mailing list w.r.t. specific > requirements can be avoided by choosing our words well. > > best regards, > John From owner-seamoby@diameter.org Tue Jun 19 09:39: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 JAA21329 for ; Tue, 19 Jun 2001 09:39:43 -0400 (EDT) Received: (qmail 24219 invoked by alias); 19 Jun 2001 13:25:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24212 invoked by uid 200); 19 Jun 2001 13:25:37 -0000 Received: (qmail 24207 invoked from network); 19 Jun 2001 13:25:34 -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; 19 Jun 2001 13:25:34 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5JDZe015092 for ; Tue, 19 Jun 2001 09:35:40 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 19 Jun 2001 09:35:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 09:35:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0F4@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 09:35:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8C4.B41E58A0" 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_01C0F8C4.B41E58A0 Content-Type: text/plain Hello John, see my rssponse below. best regards -Hamid > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Tuesday, June 19, 2001 2:01 AM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: seamoby@diameter.org > Subject: Re: [seamoby] Reactive context transfer > > Hi Hamid, > > All right. Let me suggest the following requirements plus the description > part and see if we can get a consensus on it. > > 4.2 The context transfer MUST define the common IP level (layer 3) > triggers > to initiate context transfer. > > 4.3 The context transfer MUST separate the signaling to initiate Context > Transfer from the transfer of context. > > The request for the transfer of context may come from the MN, > current AR, recieving AR, or other entity on the Access Network. There > could > be instances where the access network or the MN may need to initiate > context > transfer e.g. to actively balance the load between several ARs or to > switch > to a different type of access technology. Therefore, a common set of IP > level signalling messages (Layer 3 Triggers) must be defined, and the > current AR must capable of recieveing such messsages on any of its > interfaces. These signalling messages do not preclude the use of Layer 2 > Triggers at the current AR to initiate the common layer 3 signaling for > context transfer initiation. > > > While this is a noble goal, in practice I think that this will be a hard > one > to fufill. (Please interpret this meaning that I support this work, but > think it will be very hard to do. I'd suggest it as a seperate work > item.) > Rather than MUST, I suggest we change this to SHOULD. I'd suggest the > following: > > 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to > initiate context transfer. > 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to > intiate > context transfer. [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope. > 4.4 Context transfer SHOULD separate the signaling to initiate Context > Transfer from the transfer of context. [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. See my comment below. > 4.3 is added for completeness. > > 4.4 is a SHOULD I think. What is the need for seperating signaling and > transfer of context? If I am an AR, and I get a message 'Here is new > header > compression state for mobile node x' - I might be able to think that means > that mobile node x is going to be coming to me soon ... [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context. > best regards, > John > > 4 > > > ------_=_NextPart_001_01C0F8C4.B41E58A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [seamoby] Reactive context transfer

Hello John,

see my rssponse = below.

best regards

-Hamid

    -----Original Message-----
    From:   john.loughney@nokia.com = [SMTP:john.loughney@nokia.com]
    Sent:   Tuesday, June 19, 2001 2:01 AM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     seamoby@diameter.org
    Subject:       = Re: [seamoby] Reactive context = transfer

    Hi Hamid,
     
    All right. Let me suggest the = following requirements plus the description
    part and see if we can get a = consensus on it.

    4.2 The context transfer MUST define = the common IP level (layer 3) triggers
    to initiate context transfer.

    4.3 The context transfer MUST separate = the signaling to initiate Context
    Transfer from the transfer of = context.  

            The request for the transfer of context may come from = the MN,
    current AR, recieving AR, or other = entity on the Access Network. There could
    be instances where the access network = or the MN may need to initiate context
    transfer e.g. to actively balance the = load between several ARs or to switch
    to a different type of access = technology.   Therefore, a common set of IP
    level signalling messages (Layer 3 = Triggers) must be defined, and the
    current AR must capable of recieveing = such messsages on any of its
    interfaces.  These signalling = messages do not preclude the use of Layer 2
    Triggers at the current AR to = initiate the common layer 3 signaling for
    context transfer initiation.


    While this is a noble goal, in = practice I think that this will be a hard one
    to fufill.  (Please interpret = this meaning that I support this work, but
    think it will be very hard to = do.  I'd suggest it as a seperate work item.)
    Rather than MUST, I suggest we change = this to SHOULD.  I'd suggest the
    following:
     
    4.2 Context transfer SHOULD define = common IP level (layer 3) triggers to
    initiate context transfer.
    4.3 Context transfer MUST provide = mechanisms for layer 2 triggers to intiate
    context transfer.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF = scope. It will also be layer 2 technology specific which we are trying = to avoid. Definitely each layer 2 technology can define its own = meachnism to trigger the common IP layer triggers for context transfer. = If we work on layer 3 triggers, it would be well within the ct = scope.

    4.4 Context transfer SHOULD separate = the signaling to initiate Context
    Transfer from the transfer of = context.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4. See my = comment below.
    4.3 is added for completeness.
     
    4.4 is a SHOULD I think.  What = is the need for seperating signaling and
    transfer of context?  If I am an = AR, and I get a message 'Here is new header
    compression state for mobile node x' = - I might be able to think that means
    that mobile node x is going to be = coming to me soon ...
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR or any = entity in the access network (ref: the description part of the = requirements) while the context transfer happens between the old and = new ARs. That is why the signaling MUST be separated from the actual = transfer of context.   =

    best regards,
    John
     
    4
     
     
     

------_=_NextPart_001_01C0F8C4.B41E58A0-- From owner-seamoby@diameter.org Tue Jun 19 11:03:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23433 for ; Tue, 19 Jun 2001 11:03:05 -0400 (EDT) Received: (qmail 25820 invoked by alias); 19 Jun 2001 14:48:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25814 invoked by uid 200); 19 Jun 2001 14:48:34 -0000 Received: (qmail 25809 invoked from network); 19 Jun 2001 14:48:32 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 14:48:32 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA11055 for ; Tue, 19 Jun 2001 07:59:24 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA05483 for ; Tue, 19 Jun 2001 07:59:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 09:59:23 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Hamid Syed'" , "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 09:59:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8D0.6C3DA840" 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_01C0F8D0.6C3DA840 Content-Type: text/plain Hello Hamid: I have some questions for you. regards, ajoy Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW, in absence of layer 2 trigger, how mobile node will know if it has moved to a new access router. Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer. Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? -----Original Message----- From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] Sent: Tuesday, June 19, 2001 8:35 AM To: 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello John, see my rssponse below. best regards -Hamid -----Original Message----- From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] Sent: Tuesday, June 19, 2001 2:01 AM To: Syed, Hamid [WDLN2:AN22:EXCH] Cc: seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer Hi Hamid, All right. Let me suggest the following requirements plus the description part and see if we can get a consensus on it. 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. While this is a noble goal, in practice I think that this will be a hard one to fufill. (Please interpret this meaning that I support this work, but think it will be very hard to do. I'd suggest it as a seperate work item.) Rather than MUST, I suggest we change this to SHOULD. I'd suggest the following: 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to initiate context transfer. 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate context transfer. [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope. 4.4 Context transfer SHOULD separate the signaling to initiate Context Transfer from the transfer of context. [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. See my comment below. 4.3 is added for completeness. 4.4 is a SHOULD I think. What is the need for seperating signaling and transfer of context? If I am an AR, and I get a message 'Here is new header compression state for mobile node x' - I might be able to think that means that mobile node x is going to be coming to me soon ... [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context. best regards, John 4 ------_=_NextPart_001_01C0F8D0.6C3DA840 Content-Type: text/html RE: [seamoby] Reactive context transfer
Hello Hamid:
I have some questions for you.
regards,
ajoy
 
Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid.
 
Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW,
in absence of layer 2 trigger, how mobile node will know if it has moved to a new
access router.
 
Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer.
 
Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ?
 
 
 
 
 
 
 
 
 

 -----Original Message-----
From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
Sent: Tuesday, June 19, 2001 8:35 AM
To: 'john.loughney@nokia.com'
Cc: seamoby@diameter.org
Subject: RE: [seamoby] Reactive context transfer

Hello John,

see my rssponse below.

best regards

-Hamid

    -----Original Message-----
    From:   john.loughney@nokia.com [SMTP:john.loughney@nokia.com]
    Sent:   Tuesday, June 19, 2001 2:01 AM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     seamoby@diameter.org
    Subject:        Re: [seamoby] Reactive context transfer

    Hi Hamid,
     
    All right. Let me suggest the following requirements plus the description
    part and see if we can get a consensus on it.

    4.2 The context transfer MUST define the common IP level (layer 3) triggers
    to initiate context transfer.

    4.3 The context transfer MUST separate the signaling to initiate Context
    Transfer from the transfer of context.  

            The request for the transfer of context may come from the MN,
    current AR, recieving AR, or other entity on the Access Network. There could
    be instances where the access network or the MN may need to initiate context
    transfer e.g. to actively balance the load between several ARs or to switch
    to a different type of access technology.   Therefore, a common set of IP
    level signalling messages (Layer 3 Triggers) must be defined, and the
    current AR must capable of recieveing such messsages on any of its
    interfaces.  These signalling messages do not preclude the use of Layer 2
    Triggers at the current AR to initiate the common layer 3 signaling for
    context transfer initiation.


    While this is a noble goal, in practice I think that this will be a hard one
    to fufill.  (Please interpret this meaning that I support this work, but
    think it will be very hard to do.  I'd suggest it as a seperate work item.)
    Rather than MUST, I suggest we change this to SHOULD.  I'd suggest the
    following:
     
    4.2 Context transfer SHOULD define common IP level (layer 3) triggers to
    initiate context transfer.
    4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate
    context transfer.
    [Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope.

    4.4 Context transfer SHOULD separate the signaling to initiate Context
    Transfer from the transfer of context.
    [Syed, Hamid [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4. See my comment below.
    4.3 is added for completeness.
     
    4.4 is a SHOULD I think.  What is the need for seperating signaling and
    transfer of context?  If I am an AR, and I get a message 'Here is new header
    compression state for mobile node x' - I might be able to think that means
    that mobile node x is going to be coming to me soon ...
    [Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context.  

    best regards,
    John
     
    4
     
     
     

------_=_NextPart_001_01C0F8D0.6C3DA840-- From owner-seamoby@diameter.org Tue Jun 19 11:48: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 LAA24639 for ; Tue, 19 Jun 2001 11:48:37 -0400 (EDT) Received: (qmail 26553 invoked by alias); 19 Jun 2001 15:33:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26547 invoked by uid 200); 19 Jun 2001 15:33:07 -0000 Received: (qmail 26542 invoked from network); 19 Jun 2001 15:33:05 -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; 19 Jun 2001 15:33:05 -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 f5JFhF011660 for ; Tue, 19 Jun 2001 11:43:15 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 19 Jun 2001 11:43:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 11:43:04 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD0FB@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Singh Ajoy-ASINGH1'" , "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 11:42:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8D6.80C83C70" 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_01C0F8D6.80C83C70 Content-Type: text/plain; charset="iso-8859-1" Hello Ajoy, see my response below. regards -Hamid > -----Original Message----- > From: Singh Ajoy-ASINGH1 [SMTP:ASINGH1@motorola.com] > Sent: Tuesday, June 19, 2001 10:59 AM > To: Syed, Hamid [WDLN2:AN22:EXCH]; 'john.loughney@nokia.com' > Cc: seamoby@diameter.org > Subject: RE: [seamoby] Reactive context transfer > > Hello Hamid: > I have some questions for you. > regards, > ajoy > > Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the > IETF scope. It will also be layer 2 technology specific which we are > trying to avoid. > > Ajoy: I thought we are assuming layer 2 triggers not defining any > mechanisms for layer 2 trigger. BTW, > in absence of layer 2 trigger, how mobile node will know if it has moved > to a new > access router. [Syed, Hamid [WDLN2:AN22:EXCH]] At IETF, probably we need to define layer 3 trigger and its characteristics to initiate context transfer. I am not saying that there wont be any layer 2 triggers but those could be different for individual layer 2 technology. > > Definitely each layer 2 technology can define its own mechanism to trigger > the common IP layer triggers for context transfer. > > Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 > message which may be used to initiate Context Transfer ? [Syed, Hamid [WDLN2:AN22:EXCH]] Yes. > > > > > > > > > > > > -----Original Message----- > From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] > Sent: Tuesday, June 19, 2001 8:35 AM > To: 'john.loughney@nokia.com' > Cc: seamoby@diameter.org > Subject: RE: [seamoby] Reactive context transfer > > > > Hello John, > > see my rssponse below. > > best regards > > -Hamid > > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Tuesday, June 19, 2001 2:01 AM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: seamoby@diameter.org > Subject: Re: [seamoby] Reactive context transfer > > Hi Hamid, > > All right. Let me suggest the following requirements plus the > description > part and see if we can get a consensus on it. > > 4.2 The context transfer MUST define the common IP level > (layer 3) triggers > to initiate context transfer. > > 4.3 The context transfer MUST separate the signaling to > initiate Context > Transfer from the transfer of context. > > The request for the transfer of context may come > from the MN, > current AR, recieving AR, or other entity on the Access Network. > There could > be instances where the access network or the MN may need to initiate > context > transfer e.g. to actively balance the load between several ARs or to > switch > to a different type of access technology. Therefore, a common set > of IP > level signalling messages (Layer 3 Triggers) must be defined, and > the > current AR must capable of recieveing such messsages on any of its > interfaces. These signalling messages do not preclude the use of > Layer 2 > Triggers at the current AR to initiate the common layer 3 signaling > for > context transfer initiation. > > > While this is a noble goal, in practice I think that this > will be a hard one > to fufill. (Please interpret this meaning that I support this work, > but > think it will be very hard to do. I'd suggest it as a seperate work > item.) > Rather than MUST, I suggest we change this to SHOULD. I'd suggest > the > following: > > 4.2 Context transfer SHOULD define common IP level (layer 3) > triggers to > initiate context transfer. > 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to > intiate > context transfer. > [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out > of the IETF scope. It will also be layer 2 technology specific which we > are trying to avoid. Definitely each layer 2 technology can define its own > meachnism to trigger the common IP layer triggers for context transfer. If > we work on layer 3 triggers, it would be well within the ct scope. > > 4.4 Context transfer SHOULD separate the signaling to > initiate Context > Transfer from the transfer of context. > [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. > See my comment below. > 4.3 is added for completeness. > > 4.4 is a SHOULD I think. What is the need for seperating signaling > and > transfer of context? If I am an AR, and I get a message 'Here is > new header > compression state for mobile node x' - I might be able to think that > means > that mobile node x is going to be coming to me soon ... > [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be > MN, AR or any entity in the access network (ref: the description part of > the requirements) while the context transfer happens between the old and > new ARs. That is why the signaling MUST be separated from the actual > transfer of context. > > best regards, > John > > 4 > > > > ------_=_NextPart_001_01C0F8D6.80C83C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Reactive context transfer

Hello Ajoy,

see my response = below.

regards

-Hamid

    -----Original Message-----
    From:   Singh Ajoy-ASINGH1 = [SMTP:ASINGH1@motorola.com]
    Sent:   Tuesday, June 19, 2001 10:59 AM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]; = 'john.loughney@nokia.com'
    Cc:     seamoby@diameter.org
    Subject:       = RE: [seamoby] Reactive context = transfer

    Hello Hamid:
    I have some = questions for you.
    regards,
    ajoy=20
    =A0
    Syed, Hamid = [WDLN2:AN22:EXCH]]=A0 Well. Any layer 2 mechanism is out of the IETF = scope. It will also be layer 2 technology specific which we are trying = to avoid.

    =A0
    Ajoy: I thought we = are assuming layer 2 triggers not defining any mechanisms for layer 2 = trigger. BTW,
    in=A0absence of = layer 2 trigger,=A0how mobile node will know=A0if it has moved to a = new
    access = router.=20

[Syed, Hamid = [WDLN2:AN22:EXCH]]  At IETF, probably we need to define layer 3 = trigger and its characteristics to initiate context transfer. I am not = saying that there wont be any layer 2 triggers but those could be = different for individual layer 2 technology.

    =A0
    Definitely each = layer 2 technology can define its own mechanism to trigger the common = IP layer triggers for context transfer.

    =A0
    Ajoy: Are you = saying that layer 2 trigger at MN will initiate layer 3 message which = may be used to initiate Context Transfer ?

    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Yes.
     
    =A0
    =A0
    =A0
    =A0
    =A0
    =A0
    =A0
    =A0
    =A0

    =A0-----Original Message-----
    From: Hamid Syed [mailto:hmsyed@nortelnetworks.c= om]
    Sent: Tuesday, June 19, 2001 8:35 AM
    To: 'john.loughney@nokia.com'
    Cc: seamoby@diameter.org
    Subject: RE: [seamoby] Reactive context transfer

      Hello = John,

      see my rssponse = below.

      best = regards

      -Hamid

              -----Original Message-----
      From:=A0=A0 john.loughney@nokia.com = [SMTP:john.loughney@nokia.com]
      Sent:=A0=A0 Tuesday, June 19, = 2001 2:01 AM
      To:=A0=A0=A0=A0 Syed, Hamid = [WDLN2:AN22:EXCH]
      Cc:=A0=A0=A0=A0 seamoby@diameter.org
      Subject:=A0=A0=A0=A0=A0=A0=A0 Re: [seamoby] = Reactive context transfer

              Hi Hamid,
      =A0
      All right. Let me suggest the = following requirements plus the description
      part and see if we can get a = consensus on it.=20

              4.2 The context transfer MUST define the common IP level = (layer 3) triggers
      to initiate context = transfer.=20

              4.3 The context transfer MUST separate the signaling to = initiate Context
      Transfer from the transfer of = context.=A0=A0=20

              =A0=A0=A0=A0=A0=A0=A0 The request for the transfer of context may come from = the MN,
      current AR, recieving AR, or other = entity on the Access Network. There could
      be instances where the access = network or the MN may need to initiate context
      transfer e.g. to actively balance = the load between several ARs or to switch
      to a different type of access = technology.=A0=A0 Therefore, a common set of IP
      level signalling messages (Layer 3 = Triggers) must be defined, and the
      current AR must capable of = recieveing such messsages on any of its
      interfaces.=A0 These signalling = messages do not preclude the use of Layer 2
      Triggers at the current AR to = initiate the common layer 3 signaling for
      context transfer = initiation.


              While this is a noble goal, in practice I think that = this will be a hard one
      to fufill.=A0 (Please interpret = this meaning that I support this work, but
      think it will be very hard to = do.=A0 I'd suggest it as a seperate work item.)
      Rather than MUST, I suggest we = change this to SHOULD.=A0 I'd suggest the
      following:
      =A0
      4.2 Context transfer SHOULD define = common IP level (layer 3) triggers to
      initiate context = transfer.
      4.3 Context transfer MUST provide = mechanisms for layer 2 triggers to intiate
      context transfer.
      [Syed, Hamid = [WDLN2:AN22:EXCH]]=A0 Well. Any layer 2 mechanism is out of the IETF scope. = It will also be layer 2 technology specific which we are trying to = avoid. Definitely each layer 2 technology can define its own meachnism = to trigger the common IP layer triggers for context transfer. If we = work on layer 3 triggers, it would be well within the ct = scope.

              4.4 Context transfer SHOULD separate the signaling to = initiate Context
      Transfer from the transfer of = context.
      [Syed, Hamid = [WDLN2:AN22:EXCH]]=A0 I would rather prefer MUST for 4.4. See my comment = below.
      4.3 is added for = completeness.
      =A0
      4.4 is a SHOULD I think.=A0 What = is the need for seperating signaling and
      transfer of context?=A0 If I am an = AR, and I get a message 'Here is new header
      compression state for mobile node = x' - I might be able to think that means
      that mobile node x is going to be = coming to me soon ...
      [Syed, Hamid = [WDLN2:AN22:EXCH]]=A0 The source of signaling could be MN, AR or any entity = in the access network (ref: the description part of the requirements) = while the context transfer happens between the old and new ARs. That is = why the signaling MUST be separated from the actual transfer of = context.=A0=A0

              best regards,
      John
      =A0
      4
      =A0
      =A0
      =A0 =

------_=_NextPart_001_01C0F8D6.80C83C70-- From owner-seamoby@diameter.org Tue Jun 19 13:08: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 NAA27428 for ; Tue, 19 Jun 2001 13:08:36 -0400 (EDT) Received: (qmail 27829 invoked by alias); 19 Jun 2001 16:32:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27823 invoked by uid 200); 19 Jun 2001 16:32:22 -0000 Received: (qmail 27818 invoked from network); 19 Jun 2001 16:32:19 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 16:32:19 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA15687 for ; Tue, 19 Jun 2001 09:43:07 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA06307 for ; Tue, 19 Jun 2001 09:36:24 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 11:43:06 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Hamid Syed'" , Singh Ajoy-ASINGH1 , "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 11:43:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8DE.EA0D9240" 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_01C0F8DE.EA0D9240 Content-Type: text/plain; charset="iso-8859-1" Hello Hamid: Please see one more questions. regards, ajoy Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? [Syed, Hamid [WDLN2:AN22:EXCH]] Yes. Don't you think any layer 3 message from MN to newAR may be too late for context transfer? The nework layer message can only be sent by MN to newAR upon completion of layer 2 handover. [-----Original Message----- From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] Sent: Tuesday, June 19, 2001 10:43 AM To: 'Singh Ajoy-ASINGH1'; 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello Ajoy, see my response below. regards -Hamid -----Original Message----- From: Singh Ajoy-ASINGH1 [SMTP:ASINGH1@motorola.com] Sent: Tuesday, June 19, 2001 10:59 AM To: Syed, Hamid [WDLN2:AN22:EXCH]; 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello Hamid: I have some questions for you. regards, ajoy Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW, in absence of layer 2 trigger, how mobile node will know if it has moved to a new access router. [Syed, Hamid [WDLN2:AN22:EXCH]] At IETF, probably we need to define layer 3 trigger and its characteristics to initiate context transfer. I am not saying that there wont be any layer 2 triggers but those could be different for individual layer 2 technology. Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer. Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? [Syed, Hamid [WDLN2:AN22:EXCH]] Yes. -----Original Message----- From: Hamid Syed [ mailto:hmsyed@nortelnetworks.com ] Sent: Tuesday, June 19, 2001 8:35 AM To: 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello John, see my rssponse below. best regards -Hamid -----Original Message----- From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] Sent: Tuesday, June 19, 2001 2:01 AM To: Syed, Hamid [WDLN2:AN22:EXCH] Cc: seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer Hi Hamid, All right. Let me suggest the following requirements plus the description part and see if we can get a consensus on it. 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. While this is a noble goal, in practice I think that this will be a hard one to fufill. (Please interpret this meaning that I support this work, but think it will be very hard to do. I'd suggest it as a seperate work item.) Rather than MUST, I suggest we change this to SHOULD. I'd suggest the following: 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to initiate context transfer. 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate context transfer. [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope. 4.4 Context transfer SHOULD separate the signaling to initiate Context Transfer from the transfer of context. [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. See my comment below. 4.3 is added for completeness. 4.4 is a SHOULD I think. What is the need for seperating signaling and transfer of context? If I am an AR, and I get a message 'Here is new header compression state for mobile node x' - I might be able to think that means that mobile node x is going to be coming to me soon ... [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context. best regards, John 4 ------_=_NextPart_001_01C0F8DE.EA0D9240 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Reactive context transfer

Hello Hamid:

Please see one more questions.

regards,

ajoy

Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ?

[Syed, Hamid [WDLN2:AN22:EXCH]]  Yes. 

Don't you think any layer 3 message from MN to newAR may be too late for context transfer? The nework

layer message can only be sent by MN to newAR upon completion of layer 2 handover. 

[-----Original Message-----
From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
Sent: Tuesday, June 19, 2001 10:43 AM
To: 'Singh Ajoy-ASINGH1'; 'john.loughney@nokia.com'
Cc: seamoby@diameter.org
Subject: RE: [seamoby] Reactive context transfer

Hello Ajoy,

see my response below.

regards

-Hamid

    -----Original Message-----
    From:   Singh Ajoy-ASINGH1 [SMTP:ASINGH1@motorola.com]
    Sent:   Tuesday, June 19, 2001 10:59 AM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]; 'john.loughney@nokia.com'
    Cc:     seamoby@diameter.org
    Subject:        RE: [seamoby] Reactive context transfer

    Hello Hamid:
    I have some questions for you.
    regards,
    ajoy
     
    Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid.

     
    Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW,
    in absence of layer 2 trigger, how mobile node will know if it has moved to a new
    access router.

[Syed, Hamid [WDLN2:AN22:EXCH]]  At IETF, probably we need to define layer 3 trigger and its characteristics to initiate context transfer. I am not saying that there wont be any layer 2 triggers but those could be different for individual layer 2 technology.

     
    Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer.

     
    Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ?

    [Syed, Hamid [WDLN2:AN22:EXCH]]  Yes.
     
     
     
     
     
     
     
     
     
     

     -----Original Message-----
    From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
    Sent: Tuesday, June 19, 2001 8:35 AM
    To: 'john.loughney@nokia.com'
    Cc: seamoby@diameter.org
    Subject: RE: [seamoby] Reactive context transfer

      Hello John,

      see my rssponse below.

      best regards

      -Hamid

              -----Original Message-----
      From:   john.loughney@nokia.com [SMTP:john.loughney@nokia.com]
      Sent:   Tuesday, June 19, 2001 2:01 AM
      To:     Syed, Hamid [WDLN2:AN22:EXCH]
      Cc:     seamoby@diameter.org
      Subject:        Re: [seamoby] Reactive context transfer

              Hi Hamid,
       
      All right. Let me suggest the following requirements plus the description
      part and see if we can get a consensus on it.

              4.2 The context transfer MUST define the common IP level (layer 3) triggers
      to initiate context transfer.

              4.3 The context transfer MUST separate the signaling to initiate Context
      Transfer from the transfer of context.  

                      The request for the transfer of context may come from the MN,
      current AR, recieving AR, or other entity on the Access Network. There could
      be instances where the access network or the MN may need to initiate context
      transfer e.g. to actively balance the load between several ARs or to switch
      to a different type of access technology.   Therefore, a common set of IP
      level signalling messages (Layer 3 Triggers) must be defined, and the
      current AR must capable of recieveing such messsages on any of its
      interfaces.  These signalling messages do not preclude the use of Layer 2
      Triggers at the current AR to initiate the common layer 3 signaling for
      context transfer initiation.


              While this is a noble goal, in practice I think that this will be a hard one
      to fufill.  (Please interpret this meaning that I support this work, but
      think it will be very hard to do.  I'd suggest it as a seperate work item.)
      Rather than MUST, I suggest we change this to SHOULD.  I'd suggest the
      following:
       
      4.2 Context transfer SHOULD define common IP level (layer 3) triggers to
      initiate context transfer.
      4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate
      context transfer.
      [Syed, Hamid [WDLN2:AN22:EXCH]]  Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope.

              4.4 Context transfer SHOULD separate the signaling to initiate Context
      Transfer from the transfer of context.
      [Syed, Hamid [WDLN2:AN22:EXCH]]  I would rather prefer MUST for 4.4. See my comment below.
      4.3 is added for completeness.
       
      4.4 is a SHOULD I think.  What is the need for seperating signaling and
      transfer of context?  If I am an AR, and I get a message 'Here is new header
      compression state for mobile node x' - I might be able to think that means
      that mobile node x is going to be coming to me soon ...
      [Syed, Hamid [WDLN2:AN22:EXCH]]  The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context.  

              best regards,
      John
       
      4
       
       
       

------_=_NextPart_001_01C0F8DE.EA0D9240-- From owner-seamoby@diameter.org Tue Jun 19 14:20: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 OAA29596 for ; Tue, 19 Jun 2001 14:20:11 -0400 (EDT) Received: (qmail 28930 invoked by alias); 19 Jun 2001 18:07:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28924 invoked by uid 200); 19 Jun 2001 18:07:41 -0000 Received: (qmail 28918 invoked from network); 19 Jun 2001 18:07:38 -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; 19 Jun 2001 18:07:38 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5JIHk007113 for ; Tue, 19 Jun 2001 14:17:47 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 19 Jun 2001 14:17:42 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 14:17:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D54@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@cdma-2000.org'" Subject: [seamoby] reqs draft issue Date: Tue, 19 Jun 2001 14:17:40 -0400 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8EC.206EDA80" 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_01C0F8EC.206EDA80 Content-Type: text/plain; charset="iso-8859-1" Description of issue: The current requirements document uses fixed access network specific terminology. The current requirements document uses fixed access network specific terminology. Submitter name: Gary Kenward Submitter email address: gkenward@nortelnetworks.com Date first submitted: June 17, 2001 Reference: Comment type: 'E'ditorial Priority: '1' Should fix Section: All Rationale/Explanation of issue: The current requirements document uses fixed access network specific terminology. In particular, "access router". It is suggested that "access router" and "AR" be changed to "forwarding node" or "FN" as used in the problem statement. Text can be added to the Terminology section explaining the different examples of forwarding nodes. Note: if someone has a better term then "FN", fine. Some consideration for consistency with the problem statement is probably worthwhile, but we should use a term that everyone understands, and is not considered bias. I believe that "access network" is still neutral enough to refer to both fixed access networks and all-wireless access networks. However, if there is a better term, this too could be changed. Requested change: It is suggested that "access router" and "AR" be changed to "forwarding node" or "FN" as used in the problem statement. Text can be added to the Terminology section explaining the different examples of forwarding nodes. Proposal See requested change. ------_=_NextPart_001_01C0F8EC.206EDA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable reqs draft issue

Description of issue:
The current requirements document uses fixed access = network specific
     terminology. The current = requirements document uses fixed access network specific
     terminology.
Submitter name: Gary Kenward
Submitter email address: gkenward@nortelnetworks.com =
Date first submitted: June 17, 2001
Reference: 
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: All
Rationale/Explanation of issue:
     The current requirements = document uses fixed access network specific
     terminology. In particular, = "access router". It is suggested that
     "access router" = and "AR" be changed to "forwarding node" or = "FN" as
     used in the problem = statement. Text can be added to the Terminology
     section explaining the = different examples of forwarding nodes.

     Note: if someone has a = better term then "FN", fine. Some consideration
     for consistency with the = problem statement is probably worthwhile, but
     we should use a term that = everyone understands, and is not considered
     bias.

     I believe that "access = network" is still neutral enough to refer to
     both fixed access networks = and all-wireless access networks. However,
     if there is a better term, = this too could be changed.

Requested change:
     It is suggested that = "access router" and "AR" be changed to
     "forwarding node" = or "FN" as used in the problem statement. Text can be
     added to the Terminology = section explaining the different examples of
     forwarding nodes.

Proposal
     See requested = change.

------_=_NextPart_001_01C0F8EC.206EDA80-- From owner-seamoby@diameter.org Tue Jun 19 15:25:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01499 for ; Tue, 19 Jun 2001 15:25:53 -0400 (EDT) Received: (qmail 29613 invoked by alias); 19 Jun 2001 19:14:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29607 invoked by uid 200); 19 Jun 2001 19:14:19 -0000 Received: (qmail 29602 invoked from network); 19 Jun 2001 19:14:17 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 19:14:17 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 15:24:36 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8036@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'john.loughney@nokia.com'" , hmsyed@nortelnetworks.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 15:24:34 -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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, June 19, 2001 2:01 AM > To: hmsyed@nortelnetworks.com > Cc: seamoby@diameter.org > Subject: Re: [seamoby] Reactive context transfer > > > Hi Hamid, > > All right. Let me suggest the following requirements plus the > description > part and see if we can get a consensus on it. > > 4.2 The context transfer MUST define the common IP level > (layer 3) triggers > to initiate context transfer. > > 4.3 The context transfer MUST separate the signaling to > initiate Context > Transfer from the transfer of context. > > The request for the transfer of context may come from the MN, > current AR, recieving AR, or other entity on the Access > Network. There could > be instances where the access network or the MN may need to > initiate context > transfer e.g. to actively balance the load between several > ARs or to switch > to a different type of access technology. Therefore, a > common set of IP > level signalling messages (Layer 3 Triggers) must be defined, and the > current AR must capable of recieveing such messsages on any of its > interfaces. These signalling messages do not preclude the > use of Layer 2 > Triggers at the current AR to initiate the common layer 3 > signaling for > context transfer initiation. > > > While this is a noble goal, in practice I think that this > will be a hard one > to fufill. (Please interpret this meaning that I support > this work, but > think it will be very hard to do. I'd suggest it as a > seperate work item.) > Rather than MUST, I suggest we change this to SHOULD. I'd suggest the > following: > > 4.2 Context transfer SHOULD define common IP level (layer 3) > triggers to > initiate context transfer. > 4.3 Context transfer MUST provide mechanisms for layer 2 > triggers to intiate > context transfer. > 4.4 Context transfer SHOULD separate the signaling to initiate Context > Transfer from the transfer of context. > > 4.3 is added for completeness. > > 4.4 is a SHOULD I think. What is the need for seperating > signaling and > transfer of context? If I am an AR, and I get a message > 'Here is new header > compression state for mobile node x' - I might be able to > think that means > that mobile node x is going to be coming to me soon ... An load balance decision, or the MN requesting this will not have context to contribute. Further, if it is the newAR, it will not be sending context to oldAR. It will be requesting. - Kulwinder. > > best regards, > John > > 4 > > > > From owner-seamoby@diameter.org Tue Jun 19 15: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 PAA01616 for ; Tue, 19 Jun 2001 15:29:34 -0400 (EDT) Received: (qmail 30085 invoked by alias); 19 Jun 2001 19:17:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30079 invoked by uid 200); 19 Jun 2001 19:17:12 -0000 Received: (qmail 30074 invoked from network); 19 Jun 2001 19:17:10 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 19:17:10 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 15:27:34 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8037@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Singh Ajoy-ASINGH1'" , "'Hamid Syed'" , "'john.loughney@nokia.com'" Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Tue, 19 Jun 2001 15:27:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, June 19, 2001 12:43 PM To: 'Hamid Syed'; Singh Ajoy-ASINGH1; 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello Hamid: Please see one more questions. regards, ajoy Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? [Syed, Hamid [WDLN2:AN22:EXCH]] Yes. Don't you think any layer 3 message from MN to newAR may be too late for context transfer? The nework layer message can only be sent by MN to newAR upon completion of layer 2 handover. [ka] The request could have been made at the oldAR, before the MN moved to the newAR. [-----Original Message----- From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] Sent: Tuesday, June 19, 2001 10:43 AM To: 'Singh Ajoy-ASINGH1'; 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello Ajoy, see my response below. regards -Hamid -----Original Message----- From: Singh Ajoy-ASINGH1 [SMTP:ASINGH1@motorola.com] Sent: Tuesday, June 19, 2001 10:59 AM To: Syed, Hamid [WDLN2:AN22:EXCH]; 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello Hamid: I have some questions for you. regards, ajoy Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Ajoy: I thought we are assuming layer 2 triggers not defining any mechanisms for layer 2 trigger. BTW, in absence of layer 2 trigger, how mobile node will know if it has moved to a new access router. [Syed, Hamid [WDLN2:AN22:EXCH]] At IETF, probably we need to define layer 3 trigger and its characteristics to initiate context transfer. I am not saying that there wont be any layer 2 triggers but those could be different for individual layer 2 technology. Definitely each layer 2 technology can define its own mechanism to trigger the common IP layer triggers for context transfer. Ajoy: Are you saying that layer 2 trigger at MN will initiate layer 3 message which may be used to initiate Context Transfer ? [Syed, Hamid [WDLN2:AN22:EXCH]] Yes. -----Original Message----- From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] Sent: Tuesday, June 19, 2001 8:35 AM To: 'john.loughney@nokia.com' Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hello John, see my rssponse below. best regards -Hamid -----Original Message----- From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] Sent: Tuesday, June 19, 2001 2:01 AM To: Syed, Hamid [WDLN2:AN22:EXCH] Cc: seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer Hi Hamid, All right. Let me suggest the following requirements plus the description part and see if we can get a consensus on it. 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. While this is a noble goal, in practice I think that this will be a hard one to fufill. (Please interpret this meaning that I support this work, but think it will be very hard to do. I'd suggest it as a seperate work item.) Rather than MUST, I suggest we change this to SHOULD. I'd suggest the following: 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to initiate context transfer. 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate context transfer. [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out of the IETF scope. It will also be layer 2 technology specific which we are trying to avoid. Definitely each layer 2 technology can define its own meachnism to trigger the common IP layer triggers for context transfer. If we work on layer 3 triggers, it would be well within the ct scope. 4.4 Context transfer SHOULD separate the signaling to initiate Context Transfer from the transfer of context. [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. See my comment below. 4.3 is added for completeness. 4.4 is a SHOULD I think. What is the need for seperating signaling and transfer of context? If I am an AR, and I get a message 'Here is new header compression state for mobile node x' - I might be able to think that means that mobile node x is going to be coming to me soon ... [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be MN, AR or any entity in the access network (ref: the description part of the requirements) while the context transfer happens between the old and new ARs. That is why the signaling MUST be separated from the actual transfer of context. best regards, John 4 From owner-seamoby@diameter.org Tue Jun 19 15:50: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 PAA02354 for ; Tue, 19 Jun 2001 15:50:55 -0400 (EDT) Received: (qmail 30623 invoked by alias); 19 Jun 2001 19:39:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30617 invoked by uid 200); 19 Jun 2001 19:39:39 -0000 Received: (qmail 30611 invoked by uid 500); 19 Jun 2001 19:39:36 -0000 Date: Tue, 19 Jun 2001 12:39:36 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'seamoby@cdma-2000.org'" Subject: Re: [seamoby] reqs draft issue Message-ID: <20010619123935.S17928@charizard.diameter.org> Mail-Followup-To: Gary Kenward , "'seamoby@cdma-2000.org'" References: <9FBD322B7824D511B36900508BF93C9C9F5D54@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: <9FBD322B7824D511B36900508BF93C9C9F5D54@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jun 19, 2001 at 02:17:40PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk The web site has been updated to reflect this new issue. The issue number assigned is 1. Thanks, PatC On Tue, Jun 19, 2001 at 02:17:40PM -0400, Gary Kenward wrote: > Description of issue: > The current requirements document uses fixed access network specific > terminology. The current requirements document uses fixed access > network specific > terminology. > Submitter name: Gary Kenward > Submitter email address: gkenward@nortelnetworks.com > Date first submitted: June 17, 2001 > Reference: > Comment type: 'E'ditorial > Priority: '1' Should fix > Section: All > Rationale/Explanation of issue: > The current requirements document uses fixed access network specific > terminology. In particular, "access router". It is suggested that > "access router" and "AR" be changed to "forwarding node" or "FN" as > used in the problem statement. Text can be added to the Terminology > section explaining the different examples of forwarding nodes. > > Note: if someone has a better term then "FN", fine. Some consideration > for consistency with the problem statement is probably worthwhile, but > we should use a term that everyone understands, and is not considered > bias. > > I believe that "access network" is still neutral enough to refer to > both fixed access networks and all-wireless access networks. However, > if there is a better term, this too could be changed. > > Requested change: > It is suggested that "access router" and "AR" be changed to > "forwarding node" or "FN" as used in the problem statement. Text can be > > added to the Terminology section explaining the different examples of > forwarding nodes. > > Proposal > See requested change. From owner-seamoby@diameter.org Tue Jun 19 16:14: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 QAA03205 for ; Tue, 19 Jun 2001 16:14:13 -0400 (EDT) Received: (qmail 31185 invoked by alias); 19 Jun 2001 20:03:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31179 invoked by uid 200); 19 Jun 2001 20:03:18 -0000 Received: (qmail 31174 invoked by uid 500); 19 Jun 2001 20:03:16 -0000 Date: Tue, 19 Jun 2001 13:03:16 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] CT Requirements Message-ID: <20010619130316.V17928@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, Gary Kenward has sent the context transfer requirements to the secretariat (thanks Gary!), and a preview of the spec can be found at: http://www.diameter.org/draft-ietf-seamoby-ct-reqs-00.txt Any changes that are needed to the spec should be sent to the list by filling out an issue. See http://www.diameter.org/seamoby-ct-issues.html for more info. My current goal is to have a document that is ready for WG last call by the next IETF I-D deadline. Thanks, PatC From owner-seamoby@diameter.org Tue Jun 19 16:46: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 QAA04432 for ; Tue, 19 Jun 2001 16:46:20 -0400 (EDT) Received: (qmail 31718 invoked by alias); 19 Jun 2001 20:35:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31712 invoked by uid 200); 19 Jun 2001 20:35:04 -0000 Received: (qmail 31706 invoked from network); 19 Jun 2001 20:35:02 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 20:35:02 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 16:45:26 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F803C@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] CT Requirements Date: Tue, 19 Jun 2001 16:45:24 -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 Description of issue The current text does not provide a uniform set of IP messages for various entities to request context to be transferred in an access technology independant manner. Submitter name: Kulwinder Atwal Submitter email address: kulwinder.atwal@zucotto.com Date first submitted: Jun 19, 2001 Reference: Comment type: Technical Priority: S Section: 4.2, 4.3 Rationale/Explanation of issue: While an L2 Trigger can be used to initiate the transfer of context at the current Forwarding Node, other entities in the network need a method to request, and recieve the completion status of a context transfer operation. While other entities may not need to be involved in every aspect of the transfer of context, they do need to be able to request particular context and recieve the results of the context transfer request. Requested change: 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. Proposal From owner-seamoby@diameter.org Tue Jun 19 17:02: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 RAA04852 for ; Tue, 19 Jun 2001 17:02:20 -0400 (EDT) Received: (qmail 32205 invoked by alias); 19 Jun 2001 20:51:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32199 invoked by uid 200); 19 Jun 2001 20:51:06 -0000 Received: (qmail 32194 invoked from network); 19 Jun 2001 20:51:03 -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; 19 Jun 2001 20:51:03 -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 f5JL1C001380 for ; Tue, 19 Jun 2001 17:01:12 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 19 Jun 2001 17:00:47 -0400 Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MZHTCZ6V; Tue, 19 Jun 2001 17:00:46 -0400 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KBYWGQ5J; Tue, 19 Jun 2001 17:00:45 -0400 Message-Id: <4.3.2.7.2.20010619170101.00c49b80@ZBL6C016.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 17:03:30 -0400 To: "Gary Kenward" , "'seamoby@cdma-2000.org'" From: "David Mitton" Subject: Re: [seamoby] reqs draft issue In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5D54@zcard031.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-seamoby@diameter.org Precedence: bulk At 6/19/01 02:17 PM -0400, Kenward, Gary [WDLN2:AN10:EXCH] wrote: ... not important. Could we please NOT generate messages to this list that have Sensitivity: Company-Confidential or Priority: something other than normal. They trip filters I have setup for really important or sensitive things and get copied to my Blackberry. Thank you. Dave. ------------------------------------------------------------ David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-seamoby@diameter.org Tue Jun 19 20:02: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 UAA08281 for ; Tue, 19 Jun 2001 20:02:34 -0400 (EDT) Received: (qmail 1964 invoked by alias); 19 Jun 2001 23:51:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1958 invoked by uid 200); 19 Jun 2001 23:51:25 -0000 Received: (qmail 1950 invoked by uid 500); 19 Jun 2001 23:51:22 -0000 Date: Tue, 19 Jun 2001 16:51:22 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Question on 4.2 Message-ID: <20010619165122.H17928@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 I do recall a recent discussion on this, so I appologize if this has already come up. Does the following text, which appears under section 4.2, imply that seamoby will define the triggers? " This implies that there are general characteristics of an IP level trigger that need to be defined so that the triggers generated by different layer 2 solutions will have identical semantics at the IP level." PatC From owner-seamoby@diameter.org Tue Jun 19 20:09: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 UAA08421 for ; Tue, 19 Jun 2001 20:09:10 -0400 (EDT) Received: (qmail 2449 invoked by alias); 19 Jun 2001 23:58:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2443 invoked by uid 200); 19 Jun 2001 23:58:14 -0000 Received: (qmail 2438 invoked by uid 500); 19 Jun 2001 23:58:12 -0000 Date: Tue, 19 Jun 2001 16:58:11 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Issue 1: Change access network terminology Message-ID: <20010619165811.J17928@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 Gary, My personal preference is to keep using AR. I understand that AR is commonly used in the wired space, but I believe that many folks make wireless to be much more complicated than it is really necessary (can you say 3G?). So, by using AR, I believe that our message to the community is that this is really nothing more than a router with a few extra features. Thanks, PatC From owner-seamoby@diameter.org Tue Jun 19 20:11: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 UAA08513 for ; Tue, 19 Jun 2001 20:11:24 -0400 (EDT) Received: (qmail 2829 invoked by alias); 19 Jun 2001 23:59:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2821 invoked by uid 200); 19 Jun 2001 23:59:24 -0000 Received: (qmail 2797 invoked from network); 19 Jun 2001 23:59:19 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jun 2001 23:59:19 -0000 Received: (qmail 15227 invoked from network); 20 Jun 2001 00:10:13 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 20 Jun 2001 00:10:13 -0000 Message-ID: <3B2FE9E5.6020506@comdev.cc> Date: Tue, 19 Jun 2001 17:10:13 -0700 From: Mark Smith Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: "'seamoby@cdma-2000.org'" Subject: [seamoby] Issue 1: Change AN Terminology References: <9FBD322B7824D511B36900508BF93C9C9F5D54@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I would have to agree with this. I'm trying to think of a situation where a FN (as defined below) would not function the same fixed as it would being a MN itself, and I can't think of one. I think this would (should? Please?) address Phil's issues (which I think are valid points about not wanting to limit ARs, as previously defined, to fixed, hardwired nodes) which were largely terminology related, not a grand conspiracy against MANETs and everything they stand for.... :-) (Just kidding, Phil. :) The only thing I request be added is a definition of the term "Forwarding Node" and _WHY_ we've made the distinction. Making sure to point out that, in the context of CTP, an FN can be a fixed AR _OR_ a MN itself. But, for the context of this particular CTP session, it's acting as an AR. (Did that make sense? Too many "context"s..) -Mark Gary Kenward wrote: > Description of issue: > The current requirements document uses fixed access network specific > terminology. The current requirements document uses fixed access > network specific > terminology. > Submitter name: Gary Kenward > Submitter email address: gkenward@nortelnetworks.com > Date first submitted: June 17, 2001 > Reference: > Comment type: 'E'ditorial > Priority: '1' Should fix > Section: All > Rationale/Explanation of issue: > The current requirements document uses fixed access network specific > terminology. In particular, "access router". It is suggested that > "access router" and "AR" be changed to "forwarding node" or "FN" as > used in the problem statement. Text can be added to the Terminology > section explaining the different examples of forwarding nodes. > > Note: if someone has a better term then "FN", fine. Some consideration > for consistency with the problem statement is probably worthwhile, but > we should use a term that everyone understands, and is not considered > bias. > > I believe that "access network" is still neutral enough to refer to > both fixed access networks and all-wireless access networks. However, > if there is a better term, this too could be changed. > > Requested change: > It is suggested that "access router" and "AR" be changed to > "forwarding node" or "FN" as used in the problem statement. Text > can be > added to the Terminology section explaining the different examples of > forwarding nodes. > > Proposal > See requested change. > From owner-seamoby@diameter.org Tue Jun 19 20:14: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 UAA08562 for ; Tue, 19 Jun 2001 20:14:10 -0400 (EDT) Received: (qmail 3401 invoked by alias); 20 Jun 2001 00:03:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3395 invoked by uid 200); 20 Jun 2001 00:03:05 -0000 Received: (qmail 3390 invoked from network); 20 Jun 2001 00:03:03 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 00:03:03 -0000 Received: (qmail 15721 invoked from network); 20 Jun 2001 00:13:57 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 20 Jun 2001 00:13:57 -0000 Message-ID: <3B2FEAC5.4010701@comdev.cc> Date: Tue, 19 Jun 2001 17:13:57 -0700 From: Mark Smith Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology References: <20010619165811.J17928@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 If we do this (which would be find for me, regardless of what my last post said :), make sure we define it to address Phil's requests. I think if we were to specify that an AR, in our case, is not neccessarily a fixed, wired device, that it can, infact, be an MN itself, that should do the trick. Whatever we call it, it should be defined. -Mark Pat Calhoun wrote: > Gary, > > My personal preference is to keep using AR. I understand that AR is commonly > used in the wired space, but I believe that many folks make wireless to be > much more complicated than it is really necessary (can you say 3G?). So, > by using AR, I believe that our message to the community is that this is really > nothing more than a router with a few extra features. > > Thanks, > > PatC > From owner-seamoby@diameter.org Tue Jun 19 20:16: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 UAA08613 for ; Tue, 19 Jun 2001 20:16:19 -0400 (EDT) Received: (qmail 3871 invoked by alias); 20 Jun 2001 00:05:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3865 invoked by uid 200); 20 Jun 2001 00:05:14 -0000 Received: (qmail 3859 invoked by uid 500); 20 Jun 2001 00:05:12 -0000 Date: Tue, 19 Jun 2001 17:05:12 -0700 From: Pat Calhoun To: Mark Smith Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology Message-ID: <20010619170512.L17928@charizard.diameter.org> Mail-Followup-To: Mark Smith , seamoby@cdma-2000.org References: <20010619165811.J17928@charizard.diameter.org> <3B2FEAC5.4010701@comdev.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B2FEAC5.4010701@comdev.cc>; from mark.smith@comdev.cc on Tue, Jun 19, 2001 at 05:13:57PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > If we do this (which would be find for me, regardless of what my last > post said :), make sure we define it to address Phil's requests. I > think if we were to specify that an AR, in our case, is not neccessarily > a fixed, wired device, that it can, infact, be an MN itself, that should > do the trick. > > Whatever we call it, it should be defined. yes, you posts crossed each other :) Well, if a CT peer can be an MN, then the use of AR is clearly innapropriate. AR is an access router, and this is typically where I see CT being used, but I understand that there are others, such as Phil, that see CT as having many other uses. Perhaps we should first have someone open an issue on whether an MN can in fact be a CT peer, and the result of that issue would dictate the future of this one. PatC From owner-seamoby@diameter.org Tue Jun 19 20:29: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 UAA08758 for ; Tue, 19 Jun 2001 20:29:15 -0400 (EDT) Received: (qmail 4368 invoked by alias); 20 Jun 2001 00:18:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4362 invoked by uid 200); 20 Jun 2001 00:18:18 -0000 Received: (qmail 4357 invoked by uid 500); 20 Jun 2001 00:18:16 -0000 Date: Tue, 19 Jun 2001 17:18:15 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] [Issue] Text to accompany requirement 4.7 Message-ID: <20010619171815.M17928@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 Text to accompany requirement 4.7 Submitter name: Pat Calhoun Submitter email address: pcalhoun@eng.sun.com Date first submitted: June 19,2001 Reference: Comment type: E Priority: 1 Section: 4.7 Rationale/Explanation of issue: Section 4.7 really needs some justification. Requested change: Add the following text to section 4.7: " It is believed that if a formal authentication exchange (e.g. exchanging credentials) were done during the context transfer, the computation overhead for both the sender and the receiver would cause additional and unnecessary latency to the handoff process. Therefore, the CT peers MUST exchange credentials prior to any context transfer." Proposal: Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Tue Jun 19 20:36: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 UAA09037 for ; Tue, 19 Jun 2001 20:36:22 -0400 (EDT) Received: (qmail 4851 invoked by alias); 20 Jun 2001 00:25:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4845 invoked by uid 200); 20 Jun 2001 00:25:26 -0000 Received: (qmail 4840 invoked by uid 500); 20 Jun 2001 00:25:25 -0000 Date: Tue, 19 Jun 2001 17:25:25 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Question on CT req 4.9 Message-ID: <20010619172525.N17928@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 require appears to imply that a context transfer is a one-shot event. The whole enchalada is sent when handoff occurs. Although I tend to agree with this, I would claim that in my mind (at least) it seems feasible for high priority data to be collected and transferred (e.g. HC state), while lower priority data be sent a few seconds later (e.g. AAA accounting information). The reason why perhaps this may be useful is that if the packet size, and hence context state, of the high priority data is small enough, it will be faster to build on the oAR, parse, and install on nAR. Has this discussion already taken place? Was there a decision that was taken? Thanks, PatC From owner-seamoby@diameter.org Tue Jun 19 20:48: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 UAA09294 for ; Tue, 19 Jun 2001 20:48:15 -0400 (EDT) Received: (qmail 5331 invoked by alias); 20 Jun 2001 00:37:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5325 invoked by uid 200); 20 Jun 2001 00:37:04 -0000 Received: (qmail 5316 invoked from network); 20 Jun 2001 00:37:03 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 00:37:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 20:47:27 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8047@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Date: Tue, 19 Jun 2001 20:47:23 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 19, 2001 8:25 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Question on CT req 4.9 > > > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). > > The reason why perhaps this may be useful is that if the > packet size, and hence > context state, of the high priority data is small enough, it > will be faster to > build on the oAR, parse, and install on nAR. I would think this makes sense. The desire would be that high priority data fit in the MTU for low latency transfers. While the rest can be sent in the next packet, to reduce the timing/bandwidth constraints on the overall operation. Initially, the possible types of context may be limited, but over time as new context types are defined for new protocols, we may exceed MTU. Also, MTU may vary across implementations/access technology types. - Kulwinder. > > Has this discussion already taken place? Was there a decision > that was taken? > > Thanks, > > PatC > From owner-seamoby@diameter.org Wed Jun 20 10:07: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 KAA08116 for ; Wed, 20 Jun 2001 10:07:18 -0400 (EDT) Received: (qmail 7819 invoked by alias); 20 Jun 2001 13:54:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7813 invoked by uid 200); 20 Jun 2001 13:54:41 -0000 Received: (qmail 7808 invoked from network); 20 Jun 2001 13:54:39 -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; 20 Jun 2001 13:54:39 -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 f5KE4n021365 for ; Wed, 20 Jun 2001 10:04:51 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 10:04:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:04:31 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D5F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , Mark Smith Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Wed, 20 Jun 2001 10:04:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F991.E71FD0D0" 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_01C0F991.E71FD0D0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 19, 2001 8:05 PM > To: Mark Smith > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > > If we do this (which would be find for me, regardless of > what my last > > post said :), make sure we define it to address Phil's requests. I > > think if we were to specify that an AR, in our case, is not > neccessarily > > a fixed, wired device, that it can, infact, be an MN > itself, that should > > do the trick. > > > > Whatever we call it, it should be defined. I changed the nomenclature in the problem statement simply because even though we had spent significant time working on clear definitions of "AP" and "AR", there was still fervent debate over what an "AP" was, and what an "AR" was on the list. The English language, particularly technical nomenclature is overburdened with the baggage of common usage and perceived meaning. So using a term that is "already recognized" is at best, guaranteed to produce mixed results. Case in point: Phil's recent concerns that AR's were not MR's and that the requirements for all-wireless networks were being ignored. In general, I have no preference either way, except that I would rather avoid endless debates over what we define versus what the industry usage is. I fear that simply publishing a definition will never be enough. Gary > > yes, you posts crossed each other :) > > Well, if a CT peer can be an MN, then the use of AR is > clearly innapropriate. > AR is an access router, and this is typically where I see CT > being used, but > I understand that there are others, such as Phil, that see CT > as having many > other uses. > > Perhaps we should first have someone open an issue on whether > an MN can in fact > be a CT peer, and the result of that issue would dictate the > future of this one. > > PatC > ------_=_NextPart_001_01C0F991.E71FD0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Issue 1: Change access network terminology

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Tuesday, June 19, 2001 8:05 PM
> To: Mark Smith
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] Issue 1: Change access = network terminology
>
>
> On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark = Smith wrote:
> > If we do this (which would be find for me, = regardless of
> what my last
> > post said :), make sure we define it to = address Phil's requests.  I
> > think if we were to specify that an AR, in = our case, is not
> neccessarily
> > a fixed, wired device, that it can, = infact, be an MN
> itself, that should
> > do the trick.
> >
> > Whatever we call it, it should be = defined.

I changed the nomenclature in the problem statement = simply because even
though we had spent significant time working on = clear definitions of "AP"
and "AR", there was still fervent debate = over what an "AP" was, and what an
"AR" was on the list.

The English language, particularly technical = nomenclature is overburdened
with the baggage of common usage and perceived = meaning. So using a term
that is "already recognized" is at best, = guaranteed to produce mixed
results. Case in point: Phil's recent concerns that = AR's were not MR's and
that the requirements for all-wireless networks were = being ignored.

In general, I have no preference either way, except = that I would rather avoid endless debates over what we define versus = what the industry usage is. I fear that simply publishing a definition = will never be enough.

Gary


>
> yes, you posts crossed each other :)
>
> Well, if a CT peer can be an MN, then the use = of AR is
> clearly innapropriate.
> AR is an access router, and this is typically = where I see CT
> being used, but
> I understand that there are others, such as = Phil, that see CT
> as having many
> other uses.
>
> Perhaps we should first have someone open an = issue on whether
> an MN can in fact
> be a CT peer, and the result of that issue = would dictate the
> future of this one.
>
> PatC
>

------_=_NextPart_001_01C0F991.E71FD0D0-- From owner-seamoby@diameter.org Wed Jun 20 10:16: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 KAA08473 for ; Wed, 20 Jun 2001 10:16:55 -0400 (EDT) Received: (qmail 8318 invoked by alias); 20 Jun 2001 14:03:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8312 invoked by uid 200); 20 Jun 2001 14:03:17 -0000 Received: (qmail 8307 invoked from network); 20 Jun 2001 14:03:15 -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; 20 Jun 2001 14:03:15 -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 f5KEDS023003 for ; Wed, 20 Jun 2001 10:13:28 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 10:13:12 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:13:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D60@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Mark Smith'" , "'seamoby@cdma-2000.org'" Subject: RE: [seamoby] Issue 1: Change AN Terminology Date: Wed, 20 Jun 2001 10:13:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F993.2497F0E0" 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_01C0F993.2497F0E0 Content-Type: text/plain; charset="iso-8859-1" With apologies for getting this responses out of order (the original emails have appeared out of order in my mail box). An FN is simply an AR or an MR. It can also be a "access gateway" (AG?) - at one time there was a discussion of CT between AGs. Like others, I think that CT should be designed to carry context between two "like" nodes. And, the CT solution should not be restricted by specific topological assumptions. I think this is more in keeping with the architectural principles of the internet (RFC1958). If you check the problem statement (both -01 and -02), the concept of ct is to transfer context related to the "forwarding service". Hence, ct is useful to forwarding nodes. I hope this helps. Gary > -----Original Message----- > From: Mark Smith [mailto:mark.smith@comdev.cc] > Sent: Tuesday, June 19, 2001 8:10 PM > To: 'seamoby@cdma-2000.org' > Subject: [seamoby] Issue 1: Change AN Terminology > > > I would have to agree with this. I'm trying to think of a situation > where a FN (as defined below) would not function the same fixed as it > would being a MN itself, and I can't think of one. > > I think this would (should? Please?) address Phil's issues (which I > think are valid points about not wanting to limit ARs, as previously > defined, to fixed, hardwired nodes) which were largely terminology > related, not a grand conspiracy against MANETs and everything > they stand > for.... :-) (Just kidding, Phil. :) > > The only thing I request be added is a definition of the term > "Forwarding Node" and _WHY_ we've made the distinction. > Making sure to > point out that, in the context of CTP, an FN can be a fixed > AR _OR_ a MN > itself. But, for the context of this particular CTP session, it's > acting as an AR. (Did that make sense? Too many "context"s..) > > -Mark > > Gary Kenward wrote: > > > Description of issue: > > The current requirements document uses fixed access network specific > > terminology. The current requirements document uses > fixed access > > network specific > > terminology. > > Submitter name: Gary Kenward > > Submitter email address: gkenward@nortelnetworks.com > > Date first submitted: June 17, 2001 > > Reference: > > Comment type: 'E'ditorial > > Priority: '1' Should fix > > Section: All > > Rationale/Explanation of issue: > > The current requirements document uses fixed access > network specific > > terminology. In particular, "access router". It is > suggested that > > "access router" and "AR" be changed to "forwarding > node" or "FN" as > > used in the problem statement. Text can be added to > the Terminology > > section explaining the different examples of forwarding nodes. > > > > Note: if someone has a better term then "FN", fine. > Some consideration > > for consistency with the problem statement is probably > worthwhile, but > > we should use a term that everyone understands, and is > not considered > > bias. > > > > I believe that "access network" is still neutral > enough to refer to > > both fixed access networks and all-wireless access > networks. However, > > if there is a better term, this too could be changed. > > > > Requested change: > > It is suggested that "access router" and "AR" be changed to > > "forwarding node" or "FN" as used in the problem > statement. Text > > can be > > added to the Terminology section explaining the > different examples of > > forwarding nodes. > > > > Proposal > > See requested change. > > > > > ------_=_NextPart_001_01C0F993.2497F0E0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Issue 1: Change AN Terminology

With apologies for getting this responses out of order (the
original emails have appeared out of order in my mail box).

An FN is simply an AR or an MR. It can also be a "access gateway" (AG?) -
at one time there was a discussion of CT between AGs. Like others, I think
that CT should be designed to carry context between two "like" nodes. And,
the CT solution should not be restricted by specific topological
assumptions. I think this is more in keeping with the architectural principles of the internet (RFC1958).

If you check the problem statement (both -01 and -02), the concept of ct is
to transfer context related to the "forwarding service". Hence, ct is useful to forwarding nodes.

I hope this helps.
Gary

> -----Original Message-----
> From: Mark Smith [mailto:mark.smith@comdev.cc]
> Sent: Tuesday, June 19, 2001 8:10 PM
> To: 'seamoby@cdma-2000.org'
> Subject: [seamoby] Issue 1: Change AN Terminology
>
>
> I would have to agree with this.  I'm trying to think of a situation
> where a FN (as defined below) would not function the same fixed as it
> would being a MN itself, and I can't think of one.
>
> I think this would (should?  Please?) address Phil's issues (which I
> think are valid points about not wanting to limit ARs, as previously
> defined, to fixed, hardwired nodes) which were largely terminology
> related, not a grand conspiracy against MANETs and everything
> they stand
> for....  :-)   (Just kidding, Phil.  :)
>
> The only thing I request be added is a definition of the term
> "Forwarding Node" and _WHY_ we've made the distinction. 
> Making sure to
> point out that, in the context of CTP, an FN can be a fixed
> AR _OR_ a MN
> itself.  But, for the context of this particular CTP session, it's
> acting as an AR.  (Did that make sense?  Too many "context"s..)
>
> -Mark
>
> Gary Kenward wrote:
>
> > Description of issue:
> > The current requirements document uses fixed access network specific
> >      terminology. The current requirements document uses
> fixed access
> > network specific
> >      terminology.
> > Submitter name: Gary Kenward
> > Submitter email address: gkenward@nortelnetworks.com
> > Date first submitted: June 17, 2001
> > Reference:
> > Comment type: 'E'ditorial
> > Priority: '1' Should fix
> > Section: All
> > Rationale/Explanation of issue:
> >      The current requirements document uses fixed access
> network specific
> >      terminology. In particular, "access router". It is
> suggested that
> >      "access router" and "AR" be changed to "forwarding
> node" or "FN" as
> >      used in the problem statement. Text can be added to
> the Terminology
> >      section explaining the different examples of forwarding nodes.
> >
> >      Note: if someone has a better term then "FN", fine.
> Some consideration
> >      for consistency with the problem statement is probably
> worthwhile, but
> >      we should use a term that everyone understands, and is
> not considered
> >      bias.
> >
> >      I believe that "access network" is still neutral
> enough to refer to
> >      both fixed access networks and all-wireless access
> networks. However,
> >      if there is a better term, this too could be changed.
> >
> > Requested change:
> >      It is suggested that "access router" and "AR" be changed to
> >      "forwarding node" or "FN" as used in the problem
> statement. Text
> > can be
> >      added to the Terminology section explaining the
> different examples of
> >      forwarding nodes.
> >
> > Proposal
> >      See requested change.
> >
>
>
>

------_=_NextPart_001_01C0F993.2497F0E0-- From owner-seamoby@diameter.org Wed Jun 20 10:22: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 KAA08670 for ; Wed, 20 Jun 2001 10:22:06 -0400 (EDT) Received: (qmail 8462 invoked by alias); 20 Jun 2001 14:04:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8455 invoked by uid 200); 20 Jun 2001 14:04:58 -0000 Received: (qmail 8445 invoked from network); 20 Jun 2001 14:04:56 -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; 20 Jun 2001 14:04:56 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5KEF7023531 for ; Wed, 20 Jun 2001 10:15:07 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 20 Jun 2001 10:14:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:14:47 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D61@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Text to accompany requirement 4.7 Date: Wed, 20 Jun 2001 10:14:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F993.58E7F840" 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_01C0F993.58E7F840 Content-Type: text/plain; charset="iso-8859-1" Looks good to me. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 19, 2001 8:18 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] [Issue] Text to accompany requirement 4.7 > > > > > Text to accompany requirement 4.7 > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@eng.sun.com > Date first submitted: June 19,2001 > Reference: > Comment type: E > Priority: 1 > Section: 4.7 > Rationale/Explanation of issue: > Section 4.7 really needs some justification. > > Requested change: > Add the following text to section 4.7: > > " It is believed that if a formal authentication exchange > (e.g. exchanging > credentials) were done during the context transfer, the > computation overhead > for both the sender and the receiver would cause > additional and unnecessary > latency to the handoff process. Therefore, the CT peers > MUST exchange > credentials prior to any context transfer." > > Proposal: > Adopt the text above in the -01 version of the requirements spec. > ------_=_NextPart_001_01C0F993.58E7F840 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] [Issue] Text to accompany requirement 4.7

Looks good to me.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, June 19, 2001 8:18 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] [Issue] Text to accompany requirement 4.7
>
>
>
>
> Text to accompany requirement 4.7
> Submitter name: Pat Calhoun
> Submitter email address: pcalhoun@eng.sun.com
> Date first submitted: June 19,2001
> Reference:
> Comment type: E
> Priority: 1
> Section: 4.7
> Rationale/Explanation of issue:
> Section 4.7 really needs some justification.
>
> Requested change:
> Add the following text to section 4.7:
>
> "  It is believed that if a formal authentication exchange
> (e.g. exchanging
>    credentials) were done during the context transfer, the
> computation overhead
>    for both the sender and the receiver would cause
> additional and unnecessary
>    latency to the handoff process. Therefore, the CT peers
> MUST exchange
>    credentials prior to any context transfer."
>
> Proposal:
> Adopt the text above in the -01 version of the requirements spec.
>

------_=_NextPart_001_01C0F993.58E7F840-- From owner-seamoby@diameter.org Wed Jun 20 10:27: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 KAA08826 for ; Wed, 20 Jun 2001 10:26:55 -0400 (EDT) Received: (qmail 9270 invoked by alias); 20 Jun 2001 14:14:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9264 invoked by uid 200); 20 Jun 2001 14:14:13 -0000 Received: (qmail 9256 invoked from network); 20 Jun 2001 14:14:11 -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; 20 Jun 2001 14:14:11 -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 f5KEOP025407 for ; Wed, 20 Jun 2001 10:24:25 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 10:24:27 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:24:29 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D62@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Date: Wed, 20 Jun 2001 10:24:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F994.B35E1F60" 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_01C0F994.B35E1F60 Content-Type: text/plain; charset="iso-8859-1" This is a really soft requirement Pat. It is really an embodiment of what was considered a simplifying assumption - namely, that if the context was available, there would be no requirement to build a multi-phasic protocol. You give a valid argument a phased context transfer. However, in order to defined this properly, we would have to build in mechanisms to inform the receiving AR when the full context had indeed been received. In addition, there was a concern (I think it was shared by more then me, but I can never be sure any more), that there may be an ordering/sychronization/latency issue for a phased transfer - i.e. can we be sure that the context that arrives later will always work with the context that arrived earlier? How can we be sure. For example, I send the QoS, compression, etc. state for a flow first, and the authorization second, however, in between the microflow is discontinued. Just some thoughts. Don't care either way if it is in or out. A good implementation will address these issues if the protocol does not. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 19, 2001 8:25 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Question on CT req 4.9 > > > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). > > The reason why perhaps this may be useful is that if the > packet size, and hence > context state, of the high priority data is small enough, it > will be faster to > build on the oAR, parse, and install on nAR. > > Has this discussion already taken place? Was there a decision > that was taken? > > Thanks, > > PatC > ------_=_NextPart_001_01C0F994.B35E1F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Question on CT req 4.9

This is a really soft requirement Pat. It is really = an embodiment of what
was considered a simplifying assumption - namely, = that if the context was available, there would be no requirement to = build a multi-phasic protocol.

You give a valid argument a phased context transfer. = However, in order to
defined this properly, we would have to build in = mechanisms to inform the
receiving AR when the full context had indeed been = received. In addition, there was a concern (I think it was shared by = more then me, but I can never

be sure any more), that there may be an = ordering/sychronization/latency issue for a phased transfer - i.e. can = we be sure that the context that arrives later will always work with = the context that arrived earlier? How can we be sure. For example, I = send the QoS, compression, etc. state for a flow first, and the = authorization second, however, in between the microflow is = discontinued.

Just some thoughts. Don't care either way if it is in = or out. A good implementation will address these issues if the protocol = does not.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Tuesday, June 19, 2001 8:25 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Question on CT req = 4.9
>
>
> This require appears to imply that a context = transfer is a
> one-shot event. The whole
> enchalada is sent when handoff occurs. Although = I tend to
> agree with this, I would
> claim that in my mind (at least) it seems = feasible for high
> priority data to be
> collected and transferred (e.g. HC state), = while lower
> priority data be sent
> a few seconds later (e.g. AAA accounting = information).
>
> The reason why perhaps this may be useful is = that if the
> packet size, and hence
> context state, of the high priority data is = small enough, it
> will be faster to
> build on the oAR, parse, and install on = nAR.
>
> Has this discussion already taken place? Was = there a decision
> that was taken?
>
> Thanks,
>
> PatC
>

------_=_NextPart_001_01C0F994.B35E1F60-- From owner-seamoby@diameter.org Wed Jun 20 12:20: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 MAA12610 for ; Wed, 20 Jun 2001 12:20:26 -0400 (EDT) Received: (qmail 10790 invoked by alias); 20 Jun 2001 16:09:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10784 invoked by uid 200); 20 Jun 2001 16:09:01 -0000 Received: (qmail 10779 invoked from network); 20 Jun 2001 16:08:59 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 16:08:59 -0000 Received: (qmail 27722 invoked from network); 20 Jun 2001 16:19:49 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 20 Jun 2001 16:19:49 -0000 Message-ID: <3B30CD24.1080105@comdev.cc> Date: Wed, 20 Jun 2001 09:19:48 -0700 From: Mark Smith Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology References: <20010619165811.J17928@charizard.diameter.org> <3B2FEAC5.4010701@comdev.cc> <20010619170512.L17928@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 I guess my question is, does it matter if a Forwarding Node (as Gary has defined them) is also a Mobile Node? What effect does it have on our design/requirement/problem statement? I think the idea is that, for the sake of a particular CTP session, a node is either an MN or an FN. If it's an FN for this CTP session, it may be an MN for another session, but those two sessions are independant of each other and should be viewed as such. -Mark Pat Calhoun wrote: > On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > >>If we do this (which would be find for me, regardless of what my last >>post said :), make sure we define it to address Phil's requests. I >>think if we were to specify that an AR, in our case, is not neccessarily >>a fixed, wired device, that it can, infact, be an MN itself, that should >>do the trick. >> >>Whatever we call it, it should be defined. >> > > yes, you posts crossed each other :) > > Well, if a CT peer can be an MN, then the use of AR is clearly innapropriate. > AR is an access router, and this is typically where I see CT being used, but > I understand that there are others, such as Phil, that see CT as having many > other uses. > > Perhaps we should first have someone open an issue on whether an MN can in fact > be a CT peer, and the result of that issue would dictate the future of this one. > > PatC > From owner-seamoby@diameter.org Wed Jun 20 13:07: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 NAA14270 for ; Wed, 20 Jun 2001 13:07:11 -0400 (EDT) Received: (qmail 11385 invoked by alias); 20 Jun 2001 16:55:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11379 invoked by uid 200); 20 Jun 2001 16:55:27 -0000 Received: (qmail 11374 invoked from network); 20 Jun 2001 16:55:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 16:55:25 -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 KAA02121; Wed, 20 Jun 2001 10:05:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KH5nA25122; Wed, 20 Jun 2001 10:05:49 -0700 X-mProtect: Wed, 20 Jun 2001 10:05:49 -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 smtpdkEgF7k; Wed, 20 Jun 2001 10:03:02 PDT Message-ID: <3B30D746.EA808B59@iprg.nokia.com> Date: Wed, 20 Jun 2001 10:03:02 -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: Mark Smith CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology References: <20010619165811.J17928@charizard.diameter.org> <3B2FEAC5.4010701@comdev.cc> <20010619170512.L17928@charizard.diameter.org> <3B30CD24.1080105@comdev.cc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Smith wrote: > I guess my question is, does it matter if a Forwarding Node (as Gary has > defined them) is also a Mobile Node? What effect does it have on our > design/requirement/problem statement? The decision should be based on performance. As a simple example, imagine that the access routers are separated by very slow media, and that the mobile node has a 55 Mb/sec wireless link to its local access router. Then, context transfer of header compression is unnecessary. If we postulate that the 55 Mb/sec is the _slowest_ link between the mobile node and the AAA in the visited domain, then even transfering security associations is questionable. On the other hand, I am much in favor of focusing the context transfer discussion on a solvable problem. From previous days' discussion, it seems logical that the context transfer protocol can be invoked in more than one way (layer-2 trigger, layer-3 protocol, ...) and it SHOULD be controlled in a way that depends upon characteristics of the local access router, but as well on the application needs of the mobile node. Related to the question of what initiates the context transfer, the transfer request itself has to include some authentication data generated from a security association with the mobile node. The credentials for authorizing or finalizing the context transfer are to be provided by the mobile node. The authentication data could be checked by the previous access router in the case of reactive context transfer, or they could be checked by the new access router against something provided by the previous access router, in the case of predictive handover. Regards, Charlie P. From owner-seamoby@diameter.org Wed Jun 20 13:36: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 NAA15382 for ; Wed, 20 Jun 2001 13:36:12 -0400 (EDT) Received: (qmail 11933 invoked by alias); 20 Jun 2001 17:24:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11927 invoked by uid 200); 20 Jun 2001 17:24:42 -0000 Received: (qmail 11922 invoked from network); 20 Jun 2001 17:24:40 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 17:24:40 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 13:35:31 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445541@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Wed, 20 Jun 2001 13:35:28 -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: Mark Smith [mailto:mark.smith@comdev.cc] > Sent: Wednesday, June 20, 2001 12:20 PM > To: seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > I guess my question is, does it matter if a Forwarding Node > (as Gary has > defined them) is also a Mobile Node? What effect does it have on our > design/requirement/problem statement? > > I think the idea is that, for the sake of a particular CTP session, a > node is either an MN or an FN. If it's an FN for this CTP > session, it > may be an MN for another session, but those two sessions are > independant > of each other and should be viewed as such. > > -Mark Hi Mark, Well, not exactly. It could really be both at once, in that the choice in which it makes to route its own MN-like traffic is the same choice made for its routed traffic. Forwarding is not a strong enough term for me since almost any edge device, even those running Windoze 2000, can be forwarding nodes. Its quite different if you are actually a full blown mobile router. Then again, the choice for its own traffic could be completely different from the choices made for its routed traffic. The MR is keeping up multiple simultaneous link layers that it routes over. It adds and drops these link layers frequently. For this reason, CTP must be sent the MINIMUM number of times necessary, and splitting them into orthogonal causes like you suggest would probably be a bad idea. One thing I am worrying about right now is path context transitivity. I am not completely sure I understand the implications for it yet myself, but allow me to try to explain it. Since we have mobile nodes that are full blow SeaMoby ARs in many respects, CT may need to be daisy chained along the route until a fixed AR is hit. At this point fixed network QoS and aggragation take over. Its like the MANET has to compensate QoS and CT-wise, until the traffic hits a "real" AR. So what I am worrying about a lot is if CT has to be passed down the whole router chain end-to-end to work properly in mobile ad hoc networks. I don't have the answer yet. Thanks, Phil From owner-seamoby@diameter.org Wed Jun 20 14:23: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 OAA17050 for ; Wed, 20 Jun 2001 14:23:18 -0400 (EDT) Received: (qmail 12858 invoked by alias); 20 Jun 2001 18:08:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12845 invoked by uid 200); 20 Jun 2001 18:08:38 -0000 Received: (qmail 12823 invoked from network); 20 Jun 2001 18:08:34 -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; 20 Jun 2001 18:08:34 -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 f5KIIf003371 for ; Wed, 20 Jun 2001 14:18:42 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 14:18:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 14:18:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D66@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Wed, 20 Jun 2001 14:18:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9B5.6B0C9F40" 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_01C0F9B5.6B0C9F40 Content-Type: text/plain; charset="iso-8859-1" Phil: Interesting thoughts. I just one to be clear that the model you have described was never the model I was thinking of. For me, CT happens between "like" nodes. FN was simply a generic term to described two arbitrary nodes in a network that need to exchange context. This approach works (I believe) for the problem statement, it *may* work for the requirements, but something different will likely be required when we look at the design. Consider that one of the goals (I think), was to develop a CT solution that works in general, and is not specific to a particular network solution, topology or wireless technology. As much as this goal was discussed and agreed upon (at least, in my recollection), everyone still has an image in their mind as to what the network really looks like. So, for some, CT is happening between GGSNs/SGSNs/PDSNs/RNCs, for others it is happening between 802.11 access points (although these are L2), for others between hosts/subscriber devices, for others, between MRs. In the general situation, a CT between two "like" nodes is a nice abstract concept. Where we seem to get into trouble is when we try to bound the problem space - different networks have different requirements. I don't believe it does anyone any good to force the restrictions of one network solution on another network solution through the bias of an L3 protocol. It is also risky to develop "swiss army knife" protocols to meet all needs. On the other hand, I hope that we can avoid different ct solutions for different networks. So how do we move forward? If we really knew the differences between the requirements for different networks, we might be better positioned to identify which differences really mattered and which ones could be generalized. However, this implies a need to develop (at least) two subsets of requirements - wireless access versus all-wireless. As an example, I can imagine a scenario where two MRs need to exchange context because one or both of the MRs have move, even though the subscriber device hasn't; what does this imply about triggers, AA, etc.? Certainly many of the assumptions that one could make about an access network would seem to be suspect in this case. Cheers, Gary > -----Original Message----- > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > Sent: Wednesday, June 20, 2001 1:35 PM > To: 'Mark Smith'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > > -----Original Message----- > > From: Mark Smith [mailto:mark.smith@comdev.cc] > > Sent: Wednesday, June 20, 2001 12:20 PM > > To: seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > > > > I guess my question is, does it matter if a Forwarding Node > > (as Gary has > > defined them) is also a Mobile Node? What effect does it > have on our > > design/requirement/problem statement? > > > > I think the idea is that, for the sake of a particular CTP > session, a > > node is either an MN or an FN. If it's an FN for this CTP > > session, it > > may be an MN for another session, but those two sessions are > > independant > > of each other and should be viewed as such. > > > > -Mark > > Hi Mark, > > Well, not exactly. It could really be both at once, in that the > choice in which it makes to route its own MN-like traffic is the > same choice made for its routed traffic. Forwarding is not a > strong enough term for me since almost any edge device, even those > running Windoze 2000, can be forwarding nodes. Its quite different > if you are actually a full blown mobile router. Then again, the > choice for its own traffic could be completely different from the > choices made for its routed traffic. The MR is keeping up multiple > simultaneous link layers that it routes over. It adds and drops > these link layers frequently. For this reason, CTP must be sent > the MINIMUM number of times necessary, and splitting them into > orthogonal causes like you suggest would probably be a bad idea. > > One thing I am worrying about right now is path context transitivity. > I am not completely sure I understand the implications for it yet > myself, but allow me to try to explain it. Since we have mobile nodes > that are full blow SeaMoby ARs in many respects, CT may need to be > daisy chained along the route until a fixed AR is hit. At this > point fixed network QoS and aggragation take over. Its like the > MANET has to compensate QoS and CT-wise, until the traffic hits a > "real" AR. So what I am worrying about a lot is if CT has to be > passed down the whole router chain end-to-end to work properly in > mobile ad hoc networks. I don't have the answer yet. > > Thanks, > > Phil > ------_=_NextPart_001_01C0F9B5.6B0C9F40 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Issue 1: Change access network terminology

Phil:

  Interesting thoughts. I just one to be clear that the model you
have described was never the model I was thinking of. For me,
CT happens between "like" nodes. FN was simply a generic term
to described two arbitrary nodes in a network that need to exchange
context. This approach works (I believe) for the problem statement,
it *may* work for the requirements, but something different will
likely be required when we look at the design.

  Consider that one of the goals (I think), was to develop a CT
solution that works in general, and is not specific to a particular
network solution, topology or wireless technology. As much as this
goal was discussed and agreed upon (at least, in my recollection),
everyone still has an image in their mind as to what the network
really looks like. So, for some, CT is happening between GGSNs/SGSNs/PDSNs/RNCs,
for others it is happening between 802.11 access points (although these
are L2), for others between hosts/subscriber devices, for others, between MRs.

  In the general situation, a CT between two "like" nodes is a nice
abstract concept. Where we seem to get into trouble is when we try
to bound the problem space - different networks have different requirements.

  I don't believe it does anyone any good to force the restrictions of
one network solution on another network solution through the bias of
an L3 protocol. It is also risky to develop "swiss army knife" protocols
to meet all needs. On the other hand, I hope that we can avoid different
ct solutions for different networks.

  So how do we move forward? If we really knew the differences between the
requirements for different networks, we might be better positioned to identify
which differences really mattered and which ones could be generalized. However,
this implies a need to develop (at least) two subsets of requirements - wireless
access versus all-wireless. As an example, I can imagine a scenario where two
MRs need to exchange context because one or both of the MRs have move, even
though the subscriber device hasn't; what does this imply about triggers, AA,
etc.? Certainly many of the assumptions that one could make about an access
network would seem to be suspect in this case.

Cheers,
Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, June 20, 2001 1:35 PM
> To: 'Mark Smith'; seamoby@cdma-2000.org
> Subject: RE: [seamoby] Issue 1: Change access network terminology
>
>
>
>
> > -----Original Message-----
> > From: Mark Smith [mailto:mark.smith@comdev.cc]
> > Sent: Wednesday, June 20, 2001 12:20 PM
> > To: seamoby@cdma-2000.org
> > Subject: Re: [seamoby] Issue 1: Change access network terminology
> >
> >
> > I guess my question is, does it matter if a Forwarding Node
> > (as Gary has
> > defined them) is also a Mobile Node?  What effect does it
> have on our
> > design/requirement/problem statement?
> >
> > I think the idea is that, for the sake of a particular CTP
> session, a
> > node is either an MN or an FN.  If it's an FN for this CTP
> > session, it
> > may be an MN for another session, but those two sessions are
> > independant
> > of each other and should be viewed as such.
> >
> > -Mark
>
> Hi Mark,
>
> Well, not exactly.  It could really be both at once, in that the
> choice in which it makes to route its own MN-like traffic is the
> same choice made for its routed traffic.  Forwarding is not a
> strong enough term for me since almost any edge device, even those
> running Windoze 2000, can be forwarding nodes.  Its quite different
> if you are actually a full blown mobile router.  Then again, the
> choice for its own traffic could be completely different from the
> choices made for its routed traffic.  The MR is keeping up multiple
> simultaneous link layers that it routes over.  It adds and drops
> these link layers frequently.  For this reason, CTP must be sent
> the MINIMUM number of times necessary, and splitting them into
> orthogonal causes like you suggest would probably be a bad idea.
>
> One thing I am worrying about right now is path context transitivity.
> I am not completely sure I understand the implications for it yet
> myself, but allow me to try to explain it.  Since we have mobile nodes
> that are full blow SeaMoby ARs in many respects, CT may need to be
> daisy chained along the route until a fixed AR is hit.  At this
> point fixed network QoS and aggragation take over.  Its like the
> MANET has to compensate QoS and CT-wise, until the traffic hits a
> "real" AR.  So what I am worrying about a lot is if CT has to be
> passed down the whole router chain end-to-end to work properly in
> mobile ad hoc networks.  I don't have the answer yet.
>
> Thanks,
>
> Phil
>

------_=_NextPart_001_01C0F9B5.6B0C9F40-- From owner-seamoby@diameter.org Wed Jun 20 14:49:48 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17872 for ; Wed, 20 Jun 2001 14:49:47 -0400 (EDT) Received: (qmail 13586 invoked by alias); 20 Jun 2001 18:38:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13580 invoked by uid 200); 20 Jun 2001 18:38:20 -0000 Received: (qmail 13575 invoked from network); 20 Jun 2001 18:38:19 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 18:38:19 -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 LAA10762 for ; Wed, 20 Jun 2001 11:48:46 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KImjV21601 for ; Wed, 20 Jun 2001 11:48:45 -0700 X-mProtect: Wed, 20 Jun 2001 11:48:45 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdaVu49p; Wed, 20 Jun 2001 11:48:44 PDT Message-ID: <3B30F00C.CFB7CABD@iprg.nokia.com> Date: Wed, 20 Jun 2001 11:48:44 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: [seamoby] proactive and reactive CT definitions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue :Clear, unambiguous definitions are missing. Submitter name: Rajeev Koodli Submitter email address: rajeev@iprg.nokia.com Date first submitted: June 20, 2001 Comment type: 'T'echnical Priority: ''S'/MUST fix Section: 4.5 Rationale/Explanation of issue: The section provides the description of proactive and reactive CT without properly defining what they are. We need the definitions. Requested Change: Reactive CT: The context transfer process which takes place subsequent to arrival of a MN's packet at the target AR Proactive (I prfer Charlie's Predictive better) CT: The context transfer process in which the required contexts are in place at the target AR prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 14:57:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18149 for ; Wed, 20 Jun 2001 14:57:25 -0400 (EDT) Received: (qmail 14070 invoked by alias); 20 Jun 2001 18:46:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14064 invoked by uid 200); 20 Jun 2001 18:46:11 -0000 Received: (qmail 14058 invoked from network); 20 Jun 2001 18:46:09 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 18:46:09 -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 LAA11872; Wed, 20 Jun 2001 11:56:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KIuaW01637; Wed, 20 Jun 2001 11:56:36 -0700 X-mProtect: Wed, 20 Jun 2001 11:56:36 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdlV1u7s; Wed, 20 Jun 2001 11:56:35 PDT Message-ID: <3B30F1E3.8F845B97@iprg.nokia.com> Date: Wed, 20 Jun 2001 11:56:35 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Question on CT req 4.9 References: <20010619172525.N17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit We need to send those contexts that would otherwise become stale along with handover (per-packet state considerations). The remaining contexts _could_ be sent separately depending on the performance/MTU considerations. The former might be what you mention as high-priority contexts and the latter the low-priority contexts. Regards, -Rajeev Pat Calhoun wrote: > This require appears to imply that a context transfer is a one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to agree with this, I would > claim that in my mind (at least) it seems feasible for high priority data to be > collected and transferred (e.g. HC state), while lower priority data be sent > a few seconds later (e.g. AAA accounting information). > > The reason why perhaps this may be useful is that if the packet size, and hence > context state, of the high priority data is small enough, it will be faster to > build on the oAR, parse, and install on nAR. > > Has this discussion already taken place? Was there a decision that was taken? > > Thanks, > > PatC From owner-seamoby@diameter.org Wed Jun 20 15:07: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 PAA18636 for ; Wed, 20 Jun 2001 15:06:57 -0400 (EDT) Received: (qmail 14566 invoked by alias); 20 Jun 2001 18:55:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14560 invoked by uid 200); 20 Jun 2001 18:55:26 -0000 Received: (qmail 14555 invoked from network); 20 Jun 2001 18:55:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 18:55:25 -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 MAA12633; Wed, 20 Jun 2001 12:05:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KJ5q714689; Wed, 20 Jun 2001 12:05:52 -0700 X-mProtect: Wed, 20 Jun 2001 12:05:52 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdEfhEwc; Wed, 20 Jun 2001 12:05:50 PDT Message-ID: <3B30F40E.A5046771@iprg.nokia.com> Date: Wed, 20 Jun 2001 12:05:51 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Smith CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology References: <20010619165811.J17928@charizard.diameter.org> <3B2FEAC5.4010701@comdev.cc> <20010619170512.L17928@charizard.diameter.org> <3B30CD24.1080105@comdev.cc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps I am missing something.. Aren't we concerned about the "entity" which offers different features (QoS, HC,..) ? I guess we went with AR because that's the entity that typically offers the features. Regards, -Rajeev Mark Smith wrote: > I guess my question is, does it matter if a Forwarding Node (as Gary has > defined them) is also a Mobile Node? What effect does it have on our > design/requirement/problem statement? > > I think the idea is that, for the sake of a particular CTP session, a > node is either an MN or an FN. If it's an FN for this CTP session, it > may be an MN for another session, but those two sessions are independant > of each other and should be viewed as such. > > -Mark > > Pat Calhoun wrote: > > > On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > > > >>If we do this (which would be find for me, regardless of what my last > >>post said :), make sure we define it to address Phil's requests. I > >>think if we were to specify that an AR, in our case, is not neccessarily > >>a fixed, wired device, that it can, infact, be an MN itself, that should > >>do the trick. > >> > >>Whatever we call it, it should be defined. > >> > > > > yes, you posts crossed each other :) > > > > Well, if a CT peer can be an MN, then the use of AR is clearly innapropriate. > > AR is an access router, and this is typically where I see CT being used, but > > I understand that there are others, such as Phil, that see CT as having many > > other uses. > > > > Perhaps we should first have someone open an issue on whether an MN can in fact > > be a CT peer, and the result of that issue would dictate the future of this one. > > > > PatC > > From owner-seamoby@diameter.org Wed Jun 20 15:33: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 PAA19521 for ; Wed, 20 Jun 2001 15:33:27 -0400 (EDT) Received: (qmail 15169 invoked by alias); 20 Jun 2001 19:21:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15163 invoked by uid 200); 20 Jun 2001 19:21:52 -0000 Received: (qmail 15158 invoked from network); 20 Jun 2001 19:21:51 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 19:21:51 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 15:32:15 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F804B@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Mark Smith Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Wed, 20 Jun 2001 15:32:09 -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 To expand on Mark's comment: If we think of an AR or MN as a software thread/task/process with its own AR context/MN context, instead of physical devices, then we should be able to keep the terms AR and MN seperate. 1. A physical device may have just the AR task running, in which case it is only an AR. 2. A physical device may have just the MN task running, in which case it is only an MN. 3. A physical device may have a MN task and an AR task running in which case it is both, but the functionality is modularized. With the AR discovery protocol is possible to learn in a mobile environment which mobile device nearby has an AR task running before attempting CT. - Kulwinder. > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 3:06 PM > To: Mark Smith > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > > Perhaps I am missing something.. Aren't we concerned about > the "entity" which offers > different features (QoS, HC,..) ? I guess we went with AR > because that's the entity > that typically offers the features. > > Regards, > > -Rajeev > > > Mark Smith wrote: > > > I guess my question is, does it matter if a Forwarding Node > (as Gary has > > defined them) is also a Mobile Node? What effect does it > have on our > > design/requirement/problem statement? > > > > I think the idea is that, for the sake of a particular CTP > session, a > > node is either an MN or an FN. If it's an FN for this CTP > session, it > > may be an MN for another session, but those two sessions > are independant > > of each other and should be viewed as such. > > > > -Mark > > > > Pat Calhoun wrote: > > > > > On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > > > > > >>If we do this (which would be find for me, regardless of > what my last > > >>post said :), make sure we define it to address Phil's > requests. I > > >>think if we were to specify that an AR, in our case, is > not neccessarily > > >>a fixed, wired device, that it can, infact, be an MN > itself, that should > > >>do the trick. > > >> > > >>Whatever we call it, it should be defined. > > >> > > > > > > yes, you posts crossed each other :) > > > > > > Well, if a CT peer can be an MN, then the use of AR is > clearly innapropriate. > > > AR is an access router, and this is typically where I see > CT being used, but > > > I understand that there are others, such as Phil, that > see CT as having many > > > other uses. > > > > > > Perhaps we should first have someone open an issue on > whether an MN can in fact > > > be a CT peer, and the result of that issue would dictate > the future of this one. > > > > > > PatC > > > > From owner-seamoby@diameter.org Wed Jun 20 15: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 PAA20126 for ; Wed, 20 Jun 2001 15:49:24 -0400 (EDT) Received: (qmail 15727 invoked by alias); 20 Jun 2001 19:36:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15721 invoked by uid 200); 20 Jun 2001 19:36:40 -0000 Received: (qmail 15716 invoked from network); 20 Jun 2001 19:36:38 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 19:36:38 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 15:47:05 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F804C@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Gary Kenward'" , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Date: Wed, 20 Jun 2001 15:46:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9C1.C3442000" 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_01C0F9C1.C3442000 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, June 20, 2001 10:24 AM To: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 This is a really soft requirement Pat. It is really an embodiment of what was considered a simplifying assumption - namely, that if the context was available, there would be no requirement to build a multi-phasic protocol. There is also a implementation specific design assumption here that all technologies will have the same or sufficient bandwith/MTU/CPU cycles available to do a complete CT in real-time. This is not the case. You give a valid argument a phased context transfer. However, in order to defined this properly, we would have to build in mechanisms to inform the receiving AR when the full context had indeed been received. In addition, there was a concern (I think it was shared by more then me, but I can never This could be a single bit set in the header. - Kulwinder. be sure any more), that there may be an ordering/sychronization/latency issue for a phased transfer - i.e. can we be sure that the context that arrives later will always work with the context that arrived earlier? How can we be sure. For example, I send the QoS, compression, etc. state for a flow first, and the authorization second, however, in between the microflow is discontinued. Just some thoughts. Don't care either way if it is in or out. A good implementation will address these issues if the protocol does not. Gary > -----Original Message----- > From: Pat Calhoun [ mailto:pcalhoun@diameter.org ] > Sent: Tuesday, June 19, 2001 8:25 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Question on CT req 4.9 > > > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). > > The reason why perhaps this may be useful is that if the > packet size, and hence > context state, of the high priority data is small enough, it > will be faster to > build on the oAR, parse, and install on nAR. > > Has this discussion already taken place? Was there a decision > that was taken? > > Thanks, > > PatC > ------_=_NextPart_001_01C0F9C1.C3442000 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Question on CT req 4.9
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, June 20, 2001 10:24 AM
To: 'Pat Calhoun'; seamoby@cdma-2000.org
Subject: RE: [seamoby] Question on CT req 4.9

This is a really soft requirement Pat. It is really an embodiment of what
was considered a simplifying assumption - namely, that if the context was available, there would be no requirement to build a multi-phasic protocol.

There is also a implementation specific design assumption here that all technologies will have the same or sufficient bandwith/MTU/CPU cycles available to do a complete CT in real-time.  This is not the case. 

 You give a valid argument a phased context transfer. However, in order to
defined this properly, we would have to build in mechanisms to inform the
receiving AR when the full context had indeed been received. In addition, there was a concern (I think it was shared by more then me, but I can never 

This could be a single bit set in the header.

- Kulwinder. 

 be sure any more), that there may be an ordering/sychronization/latency issue for a phased transfer - i.e. can we be sure that the context that arrives later will always work with the context that arrived earlier? How can we be sure. For example, I send the QoS, compression, etc. state for a flow first, and the authorization second, however, in between the microflow is discontinued.

Just some thoughts. Don't care either way if it is in or out. A good implementation will address these issues if the protocol does not.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, June 19, 2001 8:25 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Question on CT req 4.9
>
>
> This require appears to imply that a context transfer is a
> one-shot event. The whole
> enchalada is sent when handoff occurs. Although I tend to
> agree with this, I would
> claim that in my mind (at least) it seems feasible for high
> priority data to be
> collected and transferred (e.g. HC state), while lower
> priority data be sent
> a few seconds later (e.g. AAA accounting information).
>
> The reason why perhaps this may be useful is that if the
> packet size, and hence
> context state, of the high priority data is small enough, it
> will be faster to
> build on the oAR, parse, and install on nAR.
>
> Has this discussion already taken place? Was there a decision
> that was taken?
>
> Thanks,
>
> PatC
>

------_=_NextPart_001_01C0F9C1.C3442000-- From owner-seamoby@diameter.org Wed Jun 20 16:17:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21085 for ; Wed, 20 Jun 2001 16:17:52 -0400 (EDT) Received: (qmail 16329 invoked by alias); 20 Jun 2001 20:06:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16323 invoked by uid 200); 20 Jun 2001 20:06:15 -0000 Received: (qmail 16318 invoked from network); 20 Jun 2001 20:06:13 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 20:06:13 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA02272 for ; Wed, 20 Jun 2001 13:17:10 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA05734 for ; Wed, 20 Jun 2001 13:10:24 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 15:17:09 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DD4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , hmsyed@nortelnetworks.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Wed, 20 Jun 2001 15:16:44 -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, What is a "common" IP level trigger mean here? common with what? What is the difference between "signalling to initiate context tranfer (which is a CT trigger)" and "common IP level triggers". Don't get me wrong, I think I was among the very first people who talked about CT trigger, but I am not sure I see the difference the two. Thanks, Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Tuesday, June 19, 2001 1:01 AM To: hmsyed@nortelnetworks.com Cc: seamoby@diameter.org Subject: Re: [seamoby] Reactive context transfer Hi Hamid, All right. Let me suggest the following requirements plus the description part and see if we can get a consensus on it. 4.2 The context transfer MUST define the common IP level (layer 3) triggers to initiate context transfer. 4.3 The context transfer MUST separate the signaling to initiate Context Transfer from the transfer of context. The request for the transfer of context may come from the MN, current AR, recieving AR, or other entity on the Access Network. There could be instances where the access network or the MN may need to initiate context transfer e.g. to actively balance the load between several ARs or to switch to a different type of access technology. Therefore, a common set of IP level signalling messages (Layer 3 Triggers) must be defined, and the current AR must capable of recieveing such messsages on any of its interfaces. These signalling messages do not preclude the use of Layer 2 Triggers at the current AR to initiate the common layer 3 signaling for context transfer initiation. While this is a noble goal, in practice I think that this will be a hard one to fufill. (Please interpret this meaning that I support this work, but think it will be very hard to do. I'd suggest it as a seperate work item.) Rather than MUST, I suggest we change this to SHOULD. I'd suggest the following: 4.2 Context transfer SHOULD define common IP level (layer 3) triggers to initiate context transfer. 4.3 Context transfer MUST provide mechanisms for layer 2 triggers to intiate context transfer. 4.4 Context transfer SHOULD separate the signaling to initiate Context Transfer from the transfer of context. 4.3 is added for completeness. 4.4 is a SHOULD I think. What is the need for seperating signaling and transfer of context? If I am an AR, and I get a message 'Here is new header compression state for mobile node x' - I might be able to think that means that mobile node x is going to be coming to me soon ... best regards, John 4 From owner-seamoby@diameter.org Wed Jun 20 16:43: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 QAA21986 for ; Wed, 20 Jun 2001 16:43:04 -0400 (EDT) Received: (qmail 16885 invoked by alias); 20 Jun 2001 20:30:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16879 invoked by uid 200); 20 Jun 2001 20:30:16 -0000 Received: (qmail 16874 invoked from network); 20 Jun 2001 20:30:14 -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; 20 Jun 2001 20:30:14 -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 f5KKeS025444 for ; Wed, 20 Jun 2001 16:40:28 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 16:40:28 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:40:31 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D68@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@cdma-2000.org Cc: "'Rajeev Koodli'" Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 16:40:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9C9.3E673DB0" 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_01C0F9C9.3E673DB0 Content-Type: text/plain; charset="iso-8859-1" This is essentially the same definitions I proposed during the discussion over proactive and reactive a few months back. And, as someone pointed out, it was mistaken. The first question that was asked then, and is still apropos: what benefit is derived from focussing on the specific arrival event as the delineator? To explain further, let me illustrate with a scenario: suppose that it takes 10ms to complete a context transfer; now suppose that the ct trigger event happens in less then 10ms from the actual first packet arrival, say 9 ms - is this a proactive or reactive ct? The ct that occurs fulfills neither of the offered definitions. The only definitive goal is for proactive CT: by definition, the context must be in place before the AR has to forward the first packet (I really could not care less about when that first packet arrives at the AR, for I do not really need context to process an arrival, only to forward the packet). Proactive CT is a highly desirable goal to ensure that handover happens seamlessly - surely, from a ct p.o.v, there can be no less impact on handover then to have the context in place before it is needed for the first packet. If the context is not in place for the first packet forwarding, then the transfer is reactive; meaning that at this point, the goal is to complete the transfer as fast as possible to minimize the delay in forwarding that first packet. Reactive CT is when I either choose not to perform proactive CT, or I fail to meet the goal of being proactive. To me, this is very crisp. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 2:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The > context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. > > > > ------_=_NextPart_001_01C0F9C9.3E673DB0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] proactive and reactive CT definitions

This is essentially the same definitions I proposed during
the discussion over proactive and reactive a few months back.
And, as someone pointed out, it was mistaken.

The first question that was asked then, and is still apropos:
what benefit is derived from focussing on the specific arrival
event as the delineator?

To explain further, let me illustrate with a scenario: suppose that
it takes 10ms to complete a context transfer; now suppose
that the ct trigger event happens  in less then 10ms from the
actual first packet arrival, say 9 ms - is this a proactive or
reactive ct? The ct that occurs fulfills neither of the offered
definitions.

The only definitive goal is for proactive CT: by definition,
the context must be in place before the AR has to forward
the first packet (I really could not care less about when that first
packet arrives at the AR, for I do not really need context to process
an arrival, only to forward the packet).

Proactive CT is a highly desirable goal to ensure that handover
happens seamlessly - surely, from a ct p.o.v, there can be no less impact
on handover then to have the context in place before it is needed for
the first packet.

If the context is not in place for the first packet forwarding, then
the transfer is reactive; meaning that at this point, the goal is to
complete the transfer as fast as possible to minimize the delay in
forwarding that first packet.

Reactive CT is when I either choose not to perform proactive CT, or
I fail to meet the goal of being proactive.

To me, this is very crisp.

Gary


> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Wednesday, June 20, 2001 2:49 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] proactive and reactive CT definitions
>
>
>
> Description of issue :Clear, unambiguous definitions are missing.
>
> Submitter name: Rajeev Koodli
>
> Submitter email address: rajeev@iprg.nokia.com
>
> Date first submitted: June 20, 2001
>
> Comment type: 'T'echnical
>
> Priority:  ''S'/MUST fix
>
> Section:  4.5
>
> Rationale/Explanation of issue:
>
> The section provides the description of proactive and reactive
> CT without properly defining what they are. We need the definitions.
>
> Requested Change:
>
> Reactive CT: The context transfer process which takes place subsequent
> to arrival of a MN's packet at the target AR
>
> Proactive (I prfer Charlie's Predictive better) CT: The
> context transfer
> process in which the required contexts are in place at the target AR
> prior to the arrival of MN's packet at target AR.
>
>
>
>

------_=_NextPart_001_01C0F9C9.3E673DB0-- From owner-seamoby@diameter.org Wed Jun 20 16:57: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 QAA22517 for ; Wed, 20 Jun 2001 16:57:12 -0400 (EDT) Received: (qmail 17412 invoked by alias); 20 Jun 2001 20:42:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17407 invoked by uid 200); 20 Jun 2001 20:42:59 -0000 Received: (qmail 17402 invoked from network); 20 Jun 2001 20:42:57 -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; 20 Jun 2001 20:42:57 -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 f5KKrC026790 for ; Wed, 20 Jun 2001 16:53:12 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 16:53:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:53:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D69@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@cdma-2000.org Cc: "'Kulwinder Atwal'" Subject: RE: [seamoby] Question on CT req 4.9 Date: Wed, 20 Jun 2001 16:53:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9CB.03DAEB90" 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_01C0F9CB.03DAEB90 Content-Type: text/plain; charset="iso-8859-1" Kulwinder: -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Wednesday, June 20, 2001 3:47 PM To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, June 20, 2001 10:24 AM To: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 This is a really soft requirement Pat. It is really an embodiment of what was considered a simplifying assumption - namely, that if the context was available, there would be no requirement to build a multi-phasic protocol. There is also a implementation specific design assumption here that all technologies will have the same or sufficient bandwith/MTU/CPU cycles available to do a complete CT in real-time. This is not the case. I guess, given the precept that CT was to enhance the real-time performance of handover, it would seem a reasonable assumption that the ARs could perform in real time. There seems to be an emerging them of performing a reactive context transfer in stages, the first stage providing enough context to allow one or more packets to be forwarded so that the the added delay is kept as small as possible, the latter stage providing the remaining context. I have my doubts about this approach, but I do see the value in extending the definition of reactive ct to allow for it. The essential difference between the existing requirement and this modified approach is to ensure that the first packet arrival (or arrivals) are not buffered waiting for the ct to complete. May I suggest that the way to address this is to modify the definition of reactive so that it allows ct to complete after the packet forwarding commences? You give a valid argument a phased context transfer. However, in order to defined this properly, we would have to build in mechanisms to inform the receiving AR when the full context had indeed been received. In addition, there was a concern (I think it was shared by more then me, but I can never This could be a single bit set in the header. And what happens if that packet is lost? There needs to be recovery mechanisms built in, etc., etc. The point is that there is an additional mechanism required (and it's never as simple as a "single bit in the header"). Having said this, the case for splitting ct for reactive mode has been made, so I guess we will have to find a solution ;^}. - Kulwinder. Gary be sure any more), that there may be an ordering/sychronization/latency issue for a phased transfer - i.e. can we be sure that the context that arrives later will always work with the context that arrived earlier? How can we be sure. For example, I send the QoS, compression, etc. state for a flow first, and the authorization second, however, in between the microflow is discontinued. Just some thoughts. Don't care either way if it is in or out. A good implementation will address these issues if the protocol does not. Gary > -----Original Message----- > From: Pat Calhoun [ mailto:pcalhoun@diameter.org ] > Sent: Tuesday, June 19, 2001 8:25 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Question on CT req 4.9 > > > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). > > The reason why perhaps this may be useful is that if the > packet size, and hence > context state, of the high priority data is small enough, it > will be faster to > build on the oAR, parse, and install on nAR. > > Has this discussion already taken place? Was there a decision > that was taken? > > Thanks, > > PatC > ------_=_NextPart_001_01C0F9CB.03DAEB90 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] Question on CT req 4.9
Kulwinder:
-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, June 20, 2001 3:47 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; seamoby@cdma-2000.org
Subject: RE: [seamoby] Question on CT req 4.9

 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, June 20, 2001 10:24 AM
To: 'Pat Calhoun'; seamoby@cdma-2000.org
Subject: RE: [seamoby] Question on CT req 4.9

This is a really soft requirement Pat. It is really an embodiment of what
was considered a simplifying assumption - namely, that if the context was available, there would be no requirement to build a multi-phasic protocol.

There is also a implementation specific design assumption here that all technologies will have the same or sufficient bandwith/MTU/CPU cycles available to do a complete CT in real-time.  This is not the case.  

I guess, given the precept that CT was to enhance the real-time performance of handover, it would seem a reasonable assumption that the ARs could perform in real time.

There seems to be an emerging them of performing a reactive context transfer in stages, the first stage providing enough context to allow one or more packets to be forwarded so that the the added delay is kept as small as possible, the latter stage providing the remaining context. I have my doubts about this approach, but I do see the value in extending the definition of reactive ct to allow for it.

The essential difference between the existing requirement and this modified approach is to ensure that the first packet arrival (or arrivals) are not buffered waiting for the ct to complete.

May I suggest that the way to address this is to modify the definition of reactive so that it allows ct to complete after the packet forwarding commences?

  You give a valid argument a phased context transfer. However, in order to
defined this properly, we would have to build in mechanisms to inform the
receiving AR when the full context had indeed been received. In addition, there was a concern (I think it was shared by more then me, but I can never 

This could be a single bit set in the header. 

And what happens if that packet is lost? There needs to be recovery mechanisms built in, etc., etc. The point is that there is an additional mechanism required (and it's never as simple as a "single bit in the header"). 

Having said this, the case for splitting ct for reactive mode has been made, so I guess we will have to find a solution ;^}.

- Kulwinder.  

Gary 

 be sure any more), that there may be an ordering/sychronization/latency issue for a phased transfer - i.e. can we be sure that the context that arrives later will always work with the context that arrived earlier? How can we be sure. For example, I send the QoS, compression, etc. state for a flow first, and the authorization second, however, in between the microflow is discontinued.

Just some thoughts. Don't care either way if it is in or out. A good implementation will address these issues if the protocol does not.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, June 19, 2001 8:25 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Question on CT req 4.9
>
>
> This require appears to imply that a context transfer is a
> one-shot event. The whole
> enchalada is sent when handoff occurs. Although I tend to
> agree with this, I would
> claim that in my mind (at least) it seems feasible for high
> priority data to be
> collected and transferred (e.g. HC state), while lower
> priority data be sent
> a few seconds later (e.g. AAA accounting information).
>
> The reason why perhaps this may be useful is that if the
> packet size, and hence
> context state, of the high priority data is small enough, it
> will be faster to
> build on the oAR, parse, and install on nAR.
>
> Has this discussion already taken place? Was there a decision
> that was taken?
>
> Thanks,
>
> PatC
>

------_=_NextPart_001_01C0F9CB.03DAEB90-- From owner-seamoby@diameter.org Wed Jun 20 17:05: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 RAA22764 for ; Wed, 20 Jun 2001 17:05:28 -0400 (EDT) Received: (qmail 17668 invoked by alias); 20 Jun 2001 20:46:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17662 invoked by uid 200); 20 Jun 2001 20:46:32 -0000 Received: (qmail 17656 invoked from network); 20 Jun 2001 20:46:29 -0000 Received: from wall.comdev.cc (HELO cleanup.comdev.cc) (63.150.62.162) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 20:46:29 -0000 Received: (qmail 28429 invoked from network); 20 Jun 2001 20:57:19 -0000 Received: from jersey.comdev.cc (HELO comdev.cc) (192.168.67.202) by cleanup.comdev.cc with SMTP; 20 Jun 2001 20:57:19 -0000 Message-ID: <3B310E2F.3030203@comdev.cc> Date: Wed, 20 Jun 2001 13:57:19 -0700 From: Mark Smith Organization: COM DEV Wireless User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9.1) Gecko/20010607 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F804B@NEPTUNE.zucotto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you, yes, that summarizes quite nicely what I was trying to say. I'm not trying to say that this isn't a problem, I'm asking if anyone can see why it would be. I can't, but I don't claim to be all knowing. :) -Mark Kulwinder Atwal wrote: > To expand on Mark's comment: > > If we think of an AR or MN as a software thread/task/process with its own AR > context/MN context, instead of physical devices, then we should be able to > keep the terms AR and MN seperate. > > 1. A physical device may have just the AR task running, in which case it is > only an AR. > > 2. A physical device may have just the MN task running, in which case it is > only an MN. > > 3. A physical device may have a MN task and an AR task running in which case > it is both, but the functionality is modularized. > > With the AR discovery protocol is possible to learn in a mobile environment > which mobile device nearby has an AR task running before attempting CT. > > - Kulwinder. > > >>-----Original Message----- >>From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] >>Sent: Wednesday, June 20, 2001 3:06 PM >>To: Mark Smith >>Cc: seamoby@cdma-2000.org >>Subject: Re: [seamoby] Issue 1: Change access network terminology >> >> >> >>Perhaps I am missing something.. Aren't we concerned about >>the "entity" which offers >>different features (QoS, HC,..) ? I guess we went with AR >>because that's the entity >>that typically offers the features. >> >>Regards, >> >>-Rajeev >> >> >>Mark Smith wrote: >> >> >>>I guess my question is, does it matter if a Forwarding Node >>> >>(as Gary has >> >>>defined them) is also a Mobile Node? What effect does it >>> >>have on our >> >>>design/requirement/problem statement? >>> >>>I think the idea is that, for the sake of a particular CTP >>> >>session, a >> >>>node is either an MN or an FN. If it's an FN for this CTP >>> >>session, it >> >>>may be an MN for another session, but those two sessions >>> >>are independant >> >>>of each other and should be viewed as such. >>> >>>-Mark >>> >>>Pat Calhoun wrote: >>> >>> >>>>On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: >>>> >>>> >>>>>If we do this (which would be find for me, regardless of >>>>> >>what my last >> >>>>>post said :), make sure we define it to address Phil's >>>>> >>requests. I >> >>>>>think if we were to specify that an AR, in our case, is >>>>> >>not neccessarily >> >>>>>a fixed, wired device, that it can, infact, be an MN >>>>> >>itself, that should >> >>>>>do the trick. >>>>> >>>>>Whatever we call it, it should be defined. >>>>> >>>>> >>>>yes, you posts crossed each other :) >>>> >>>>Well, if a CT peer can be an MN, then the use of AR is >>>> >>clearly innapropriate. >> >>>>AR is an access router, and this is typically where I see >>>> >>CT being used, but >> >>>>I understand that there are others, such as Phil, that >>>> >>see CT as having many >> >>>>other uses. >>>> >>>>Perhaps we should first have someone open an issue on >>>> >>whether an MN can in fact >> >>>>be a CT peer, and the result of that issue would dictate >>>> >>the future of this one. >> >>>>PatC >>>> >>>> From owner-seamoby@diameter.org Wed Jun 20 17:31: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 RAA23641 for ; Wed, 20 Jun 2001 17:31:20 -0400 (EDT) Received: (qmail 19233 invoked by alias); 20 Jun 2001 21:19:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19227 invoked by uid 200); 20 Jun 2001 21:19:19 -0000 Received: (qmail 19222 invoked from network); 20 Jun 2001 21:19:17 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 21:19:17 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA25897 for ; Wed, 20 Jun 2001 14:30:14 -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 OAA03893 for ; Wed, 20 Jun 2001 14:30:14 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:30:14 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DD8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 16:30:06 -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 I still don't know whether I should respond to these issues or not, but it seems that is the going trend. For Proactive, your definition works, and actually it is the same as in the draft. I think this definition of reactive is going backward a bit. We did discuss this issue at length and I think you were in agreement that reactive CT, does not always mean that CT cannot start until after the MN's packets have arrived. For reactive, CT can happens simultaneous as Handover signaling but it might not finish when handover signaling is complete. What you are suggesting, means that you don't need CT to deliver packets the mobile and are totally moving CT out of the critical path for timing. I guess say for header compression it means that the newAR does not have HC states for a while, assuming it can receive uncompressed packets, But would this work for security and authentication, I don't think so. I like the current definition for reactive: "doing CT when handover is imminent" and that means that oldAR or newAR are already engaged in handover signaling, now this could be a L2 trigger that newAR has received or a HI or something else, but it does not mean completion of handover signaling and packet routing change. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Wednesday, June 20, 2001 1:49 PM To: seamoby@cdma-2000.org Subject: [seamoby] proactive and reactive CT definitions Description of issue :Clear, unambiguous definitions are missing. Submitter name: Rajeev Koodli Submitter email address: rajeev@iprg.nokia.com Date first submitted: June 20, 2001 Comment type: 'T'echnical Priority: ''S'/MUST fix Section: 4.5 Rationale/Explanation of issue: The section provides the description of proactive and reactive CT without properly defining what they are. We need the definitions. Requested Change: Reactive CT: The context transfer process which takes place subsequent to arrival of a MN's packet at the target AR Proactive (I prfer Charlie's Predictive better) CT: The context transfer process in which the required contexts are in place at the target AR prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 17:41:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23953 for ; Wed, 20 Jun 2001 17:41:25 -0400 (EDT) Received: (qmail 20179 invoked by alias); 20 Jun 2001 21:29:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20173 invoked by uid 200); 20 Jun 2001 21:29:36 -0000 Received: (qmail 20156 invoked from network); 20 Jun 2001 21:29:33 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 21:29:33 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA19523 for ; Wed, 20 Jun 2001 14:40:30 -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 OAA12073 for ; Wed, 20 Jun 2001 14:40:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:40:30 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DD9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: [seamoby] context priority was: Question on CT req 4.9 Date: Wed, 20 Jun 2001 16:40:19 -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 Pat, I am not sure about the relation of size and priority, but as far as priority alone, I did ask the same question long time ago, during our timing discussion. Not much discussion took place actually and I thought maybe as we go along and understand more about the demands of various feature's, we might sort their context in priority before sending them over, a couple of things to consider is: What is needed first at the newAR to setup packet delivery (HC/ security?) What gets updates on packet by packet basis, so it will become stale by the time CT is getting close to completion (again HC?) What context can wait until after resuming packet delivery to MN at newAR? Would you have to resend updates of some contexts before CT session is over? Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Tuesday, June 19, 2001 7:25 PM To: seamoby@cdma-2000.org Subject: [seamoby] Question on CT req 4.9 This require appears to imply that a context transfer is a one-shot event. The whole enchalada is sent when handoff occurs. Although I tend to agree with this, I would claim that in my mind (at least) it seems feasible for high priority data to be collected and transferred (e.g. HC state), while lower priority data be sent a few seconds later (e.g. AAA accounting information). The reason why perhaps this may be useful is that if the packet size, and hence context state, of the high priority data is small enough, it will be faster to build on the oAR, parse, and install on nAR. Has this discussion already taken place? Was there a decision that was taken? Thanks, PatC From owner-seamoby@diameter.org Wed Jun 20 17:44: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 RAA23996 for ; Wed, 20 Jun 2001 17:44:12 -0400 (EDT) Received: (qmail 20279 invoked by alias); 20 Jun 2001 21:30:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20273 invoked by uid 200); 20 Jun 2001 21:30:03 -0000 Received: (qmail 20254 invoked from network); 20 Jun 2001 21:30:00 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 21:30:00 -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 OAA25970; Wed, 20 Jun 2001 14:40:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KLeQx08975; Wed, 20 Jun 2001 14:40:26 -0700 X-mProtect: Wed, 20 Jun 2001 14:40:26 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdT2zwGj; Wed, 20 Jun 2001 14:40:25 PDT Message-ID: <3B311849.414CB431@iprg.nokia.com> Date: Wed, 20 Jun 2001 14:40:25 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D68@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > This is essentially the same definitions I proposed during > the discussion over proactive and reactive a few months back. > And, as someone pointed out, it was mistaken. > > The first question that was asked then, and is still apropos: > what benefit is derived from focussing on the specific arrival > event as the delineator? > Rajeev: The benefit is a clear starting point for the CT process. (i.e., when to initiate CT) > > To explain further, let me illustrate with a scenario: suppose that > it takes 10ms to complete a context transfer; now suppose > that the ct trigger event happens in less then 10ms from the > actual first packet arrival, say 9 ms - is this a proactive or > reactive ct? The ct that occurs fulfills neither of the offered > definitions. Rajeev: The offered definition does not say anything about how long context transfer takes place. The _start_ of CT request is the issue. A packet arrives at the new AR (e.g., a MN request for CT), there is no context there, then you fetch it. > > > If the context is not in place for the first packet forwarding, then > the transfer is reactive; meaning that at this point, the goal is to > complete the transfer as fast as possible to minimize the delay in > forwarding that first packet. > Rajeev: Exactly. This is what I am proposing to be added. > > Reactive CT is when I either choose not to perform proactive CT, or > I fail to meet the goal of being proactive. Rajeev: Agreed. Can we add the text then ? What do others think ? Regards, -Rajeev > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 2:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place > subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > context transfer > > process in which the required contexts are in place at the target AR > > > prior to the arrival of MN's packet at target AR. > > > > > > > > From owner-seamoby@diameter.org Wed Jun 20 17:47: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 RAA24065 for ; Wed, 20 Jun 2001 17:47:17 -0400 (EDT) Received: (qmail 20668 invoked by alias); 20 Jun 2001 21:32:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20660 invoked by uid 200); 20 Jun 2001 21:32:11 -0000 Received: (qmail 20647 invoked from network); 20 Jun 2001 21:32:09 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 21:32:09 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 17:42:36 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F804F@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 17:42:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I also like the definition as stated in the draft, becuase if the MN has no real-time traffic, then the AR can choose to conserve scarce bandwidth by doing Reactive CT with no percievable impact for the End-user. If I am doing a file download and loose 60mSec lets say to Reactive CT, I will not notice as an End-User. - Kulwinder. > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, June 20, 2001 5:30 PM > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in > agreement that > reactive CT, does not always mean that CT cannot start until > after the MN's > packets have arrived. > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The > context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. > > From owner-seamoby@diameter.org Wed Jun 20 17:49: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 RAA24108 for ; Wed, 20 Jun 2001 17:48:59 -0400 (EDT) Received: (qmail 19730 invoked by alias); 20 Jun 2001 21:26:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19724 invoked by uid 200); 20 Jun 2001 21:26:51 -0000 Received: (qmail 19719 invoked from network); 20 Jun 2001 21:26:49 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 21:26:49 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA20205 for ; Wed, 20 Jun 2001 14:37:46 -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 OAA22626 for ; Wed, 20 Jun 2001 14:37:46 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:37:45 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: Nakhjiri Madjid-MNAKHJI1 , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 16:36:22 -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 Hello Madjid: I also like your definition of reactive handover. I do not think doing context transfer after completion of layer 3 handover will much sense. regards, ajoy -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid_Nakhjiri-MNAKHJI1@email.mot.com] Sent: Wednesday, June 20, 2001 4:30 PM To: 'Rajeev Koodli'; seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions I still don't know whether I should respond to these issues or not, but it seems that is the going trend. For Proactive, your definition works, and actually it is the same as in the draft. I think this definition of reactive is going backward a bit. We did discuss this issue at length and I think you were in agreement that reactive CT, does not always mean that CT cannot start until after the MN's packets have arrived. For reactive, CT can happens simultaneous as Handover signaling but it might not finish when handover signaling is complete. What you are suggesting, means that you don't need CT to deliver packets the mobile and are totally moving CT out of the critical path for timing. I guess say for header compression it means that the newAR does not have HC states for a while, assuming it can receive uncompressed packets, But would this work for security and authentication, I don't think so. I like the current definition for reactive: "doing CT when handover is imminent" and that means that oldAR or newAR are already engaged in handover signaling, now this could be a L2 trigger that newAR has received or a HI or something else, but it does not mean completion of handover signaling and packet routing change. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Wednesday, June 20, 2001 1:49 PM To: seamoby@cdma-2000.org Subject: [seamoby] proactive and reactive CT definitions Description of issue :Clear, unambiguous definitions are missing. Submitter name: Rajeev Koodli Submitter email address: rajeev@iprg.nokia.com Date first submitted: June 20, 2001 Comment type: 'T'echnical Priority: ''S'/MUST fix Section: 4.5 Rationale/Explanation of issue: The section provides the description of proactive and reactive CT without properly defining what they are. We need the definitions. Requested Change: Reactive CT: The context transfer process which takes place subsequent to arrival of a MN's packet at the target AR Proactive (I prfer Charlie's Predictive better) CT: The context transfer process in which the required contexts are in place at the target AR prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 18:15: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 SAA24765 for ; Wed, 20 Jun 2001 18:15:34 -0400 (EDT) Received: (qmail 22083 invoked by alias); 20 Jun 2001 22:02:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22075 invoked by uid 200); 20 Jun 2001 22:02:45 -0000 Received: (qmail 22063 invoked from network); 20 Jun 2001 22:02:42 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:02:42 -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 PAA28555; Wed, 20 Jun 2001 15:13:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KMD7M22260; Wed, 20 Jun 2001 15:13:07 -0700 X-mProtect: Wed, 20 Jun 2001 15:13:07 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9FlVOm; Wed, 20 Jun 2001 15:13:06 PDT Message-ID: <3B311FF2.87A182C7@iprg.nokia.com> Date: Wed, 20 Jun 2001 15:13:06 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Ajoy, Singh Ajoy-ASINGH1 wrote: > Hello Madjid: > I also like your definition of reactive handover. I do not think > doing context transfer after completion of layer 3 handover will > much sense. > Can you say why it does not make sense ? -Rajeev > regards, > ajoy > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid_Nakhjiri-MNAKHJI1@email.mot.com] > Sent: Wednesday, June 20, 2001 4:30 PM > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] proactive and reactive CT definitions > > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 18:18: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 SAA24842 for ; Wed, 20 Jun 2001 18:18:54 -0400 (EDT) Received: (qmail 22466 invoked by alias); 20 Jun 2001 22:05:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22460 invoked by uid 200); 20 Jun 2001 22:05:18 -0000 Received: (qmail 22448 invoked from network); 20 Jun 2001 22:05:15 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:05:15 -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 PAA28714; Wed, 20 Jun 2001 15:15:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KMFhE23720; Wed, 20 Jun 2001 15:15:43 -0700 X-mProtect: Wed, 20 Jun 2001 15:15:43 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdq4YG5s; Wed, 20 Jun 2001 15:15:41 PDT Message-ID: <3B31208D.203D47F2@iprg.nokia.com> Date: Wed, 20 Jun 2001 15:15:41 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F804F@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 Hello Kulwinder, Kulwinder Atwal wrote: > I also like the definition as stated in the draft, becuase if the MN has no > real-time traffic, then the AR can choose to conserve scarce bandwidth by > doing Reactive CT with no percievable impact for the End-user. > Rajeev: does this mean that reactive CT is only for the non real-time traffic ? What happens if I cannot do proactive CT and I _do_ have real-time traffic ? Would you not do any CT at all then ? > > If I am doing a file download and loose 60mSec lets say to Reactive CT, I > will not notice as an End-User. > Rajeev: good example. Not sufficient :-) Regards, -Rajeev > > - Kulwinder. > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Wednesday, June 20, 2001 5:30 PM > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in > > agreement that > > reactive CT, does not always mean that CT cannot start until > > after the MN's > > packets have arrived. > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. > > > > From owner-seamoby@diameter.org Wed Jun 20 18:32: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 SAA25112 for ; Wed, 20 Jun 2001 18:32:16 -0400 (EDT) Received: (qmail 21720 invoked by alias); 20 Jun 2001 22:00:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21714 invoked by uid 200); 20 Jun 2001 22:00:08 -0000 Received: (qmail 21709 invoked from network); 20 Jun 2001 22:00:06 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:00:06 -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 PAA28404; Wed, 20 Jun 2001 15:10:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KMAXH19333; Wed, 20 Jun 2001 15:10:33 -0700 X-mProtect: Wed, 20 Jun 2001 15:10:33 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdz0tXb6; Wed, 20 Jun 2001 15:10:31 PDT Message-ID: <3B311F58.792D1EE5@iprg.nokia.com> Date: Wed, 20 Jun 2001 15:10:32 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DD8@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 Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > Rajeev: It's a good going trend to straighten things out. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > Rajeev: Reactive CT means that there is no context at the new AR when MN's packets arrive. If we want to do CT, I would think that that's a good time to start. Going by your argument, when do you start a reactive CT ? If we both agree that there is no context in place when the MN's packets arrive, what do you do ? If you had started CT before, that's proactive, but not working very well. Claiming that reactive CT is the "proactive CT gone bad" is extremely poor definition. I don't believe that I agreed at all to such a definition. Please enlighten me! > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. Rajeev: Where is this definition ? This can take another avatar of its own :-) > > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > Rajeev: If the context is not present when the MN's packet arrive, you try to get it. Right ? Why is that not reactive CT ? If CT is not there, and while I try to fetch it, why can't I forward the packets if it is possible ? If I *don't* forward packets, what do I do ? Drop them ? How's that good for TCP/RTP's performance ? Consider the ability to send and receive normal IP packets as a service (aka connectivity) upon which the rest of the CT features are based. For HC, you could forward on downlink. For security, you could forward the packets in both the directions until you receive the appropriate contexts. You may not have a packet *treated* with require feature, but you can still forward packets. If CT fails all together, what do you do ? You could require the MN to re-authenticate itself. How do you do that ? You need connectivity to send and receive IP packets. In a nut shell, if there are no contexts, you can always go fetch them *or* require the MN to re-establish them. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > Rajeev: When would you start CT in this case ? When does new AR receive L2 trigger ? Is it trying to do CT when it receives a HI ? I understand that when a packet arrives at new AR, the CT may be already "in progress", as indicated by the signaling that has taken place. The new AR may *still* initiate CT signaling and the old AR must be able to handle requests that come in sequence. It is called "idempotent" operation. Regards, -Rajeev > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 18:47: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 SAA25328 for ; Wed, 20 Jun 2001 18:47:34 -0400 (EDT) Received: (qmail 23252 invoked by alias); 20 Jun 2001 22:35:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23246 invoked by uid 200); 20 Jun 2001 22:35:30 -0000 Received: (qmail 23241 invoked from network); 20 Jun 2001 22:35:29 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:35:29 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 18:45:56 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8051@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 18:45: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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, June 20, 2001 6:16 PM > To: Kulwinder Atwal > Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > Hello Kulwinder, > > Kulwinder Atwal wrote: > > > I also like the definition as stated in the draft, becuase > if the MN has no > > real-time traffic, then the AR can choose to conserve > scarce bandwidth by > > doing Reactive CT with no percievable impact for the End-user. > > > > Rajeev: does this mean that reactive CT is only for the non > real-time traffic > ? >What happens if I cannot do proactive CT and I _do_ have > real-time traffic ? > Would you not do any CT at all then ? > If we can prioritize context, and provide partial context updates of real-time context, then I am fine with your request to change the text. - Kulwinder. > > > > > If I am doing a file download and loose 60mSec lets say to > Reactive CT, I > > will not notice as an End-User. > > > > Rajeev: good example. Not sufficient :-) > > Regards, > > -Rajeev > > > > > > - Kulwinder. > > > > > -----Original Message----- > > > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid.Nakhjiri@motorola.com] > > > Sent: Wednesday, June 20, 2001 5:30 PM > > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > I still don't know whether I should respond to these > issues or not, > > > but it seems that is the going trend. > > > > > > For Proactive, your definition works, and actually it is the same > > > as in the draft. > > > > > > I think this definition of reactive is going backward a bit. > > > We did discuss this issue at length and I think you were in > > > agreement that > > > reactive CT, does not always mean that CT cannot start until > > > after the MN's > > > packets have arrived. > > > > > > For reactive, CT can happens simultaneous as Handover signaling > > > but it might not finish when handover signaling is complete. > > > > > > What you are suggesting, means that you don't need CT to deliver > > > packets the mobile and are totally moving CT out of the critical > > > path for timing. I guess say for header compression > > > it means that the newAR does not have HC states for a while, > > > assuming it can receive uncompressed packets, > > > But would this work for security and authentication, I > don't think so. > > > > > > I like the current definition for reactive: > > > "doing CT when handover is imminent" and that means that oldAR or > > > newAR are already engaged in handover signaling, now this could be > > > a L2 trigger that newAR has received or a HI or something > else, but > > > it does not mean completion of handover signaling and > packet routing > > > change. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > Submitter name: Rajeev Koodli > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > Date first submitted: June 20, 2001 > > > > > > Comment type: 'T'echnical > > > > > > Priority: ''S'/MUST fix > > > > > > Section: 4.5 > > > > > > Rationale/Explanation of issue: > > > > > > The section provides the description of proactive and reactive > > > CT without properly defining what they are. We need the > definitions. > > > > > > Requested Change: > > > > > > Reactive CT: The context transfer process which takes > place subsequent > > > to arrival of a MN's packet at the target AR > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > context transfer > > > process in which the required contexts are in place at > the target AR > > > prior to the arrival of MN's packet at target AR. > > > > > > > From owner-seamoby@diameter.org Wed Jun 20 18:56: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 SAA25561 for ; Wed, 20 Jun 2001 18:56:30 -0400 (EDT) Received: (qmail 23768 invoked by alias); 20 Jun 2001 22:44:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23762 invoked by uid 200); 20 Jun 2001 22:44:13 -0000 Received: (qmail 23757 invoked from network); 20 Jun 2001 22:44:12 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:44:12 -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 PAA02215; Wed, 20 Jun 2001 15:54:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KMscx22368; Wed, 20 Jun 2001 15:54:38 -0700 X-mProtect: Wed, 20 Jun 2001 15:54:38 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdauCdpb; Wed, 20 Jun 2001 15:54:37 PDT Message-ID: <3B3129AE.4368E5FF@iprg.nokia.com> Date: Wed, 20 Jun 2001 15:54:38 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8051@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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, June 20, 2001 6:16 PM > > To: Kulwinder Atwal > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > Hello Kulwinder, > > > > Kulwinder Atwal wrote: > > > > > I also like the definition as stated in the draft, becuase > > if the MN has no > > > real-time traffic, then the AR can choose to conserve > > scarce bandwidth by > > > doing Reactive CT with no percievable impact for the End-user. > > > > > > > Rajeev: does this mean that reactive CT is only for the non > > real-time traffic > > ? > >What happens if I cannot do proactive CT and I _do_ have > > real-time traffic ? > > Would you not do any CT at all then ? > > > > If we can prioritize context, and provide partial context updates of > real-time context, then I am fine with your request to change the text. > > Rajeev: May be you would like to bring this up a separate issue ? Coming back to the point I have raised, I hope you would agree that we have to consider reactive CT independent of real-time nature of the traffic. Sometimes, all you have is basic connectivity, and you could use it to reactively fetch contexts. Regards, -Rajeev > - Kulwinder. > > > > > > > > > If I am doing a file download and loose 60mSec lets say to > > Reactive CT, I > > > will not notice as an End-User. > > > > > > > Rajeev: good example. Not sufficient :-) > > > > Regards, > > > > -Rajeev > > > > > > > > > > - Kulwinder. > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Wednesday, June 20, 2001 5:30 PM > > > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > I still don't know whether I should respond to these > > issues or not, > > > > but it seems that is the going trend. > > > > > > > > For Proactive, your definition works, and actually it is the same > > > > as in the draft. > > > > > > > > I think this definition of reactive is going backward a bit. > > > > We did discuss this issue at length and I think you were in > > > > agreement that > > > > reactive CT, does not always mean that CT cannot start until > > > > after the MN's > > > > packets have arrived. > > > > > > > > For reactive, CT can happens simultaneous as Handover signaling > > > > but it might not finish when handover signaling is complete. > > > > > > > > What you are suggesting, means that you don't need CT to deliver > > > > packets the mobile and are totally moving CT out of the critical > > > > path for timing. I guess say for header compression > > > > it means that the newAR does not have HC states for a while, > > > > assuming it can receive uncompressed packets, > > > > But would this work for security and authentication, I > > don't think so. > > > > > > > > I like the current definition for reactive: > > > > "doing CT when handover is imminent" and that means that oldAR or > > > > newAR are already engaged in handover signaling, now this could be > > > > a L2 trigger that newAR has received or a HI or something > > else, but > > > > it does not mean completion of handover signaling and > > packet routing > > > > change. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > Comment type: 'T'echnical > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > Section: 4.5 > > > > > > > > Rationale/Explanation of issue: > > > > > > > > The section provides the description of proactive and reactive > > > > CT without properly defining what they are. We need the > > definitions. > > > > > > > > Requested Change: > > > > > > > > Reactive CT: The context transfer process which takes > > place subsequent > > > > to arrival of a MN's packet at the target AR > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > context transfer > > > > process in which the required contexts are in place at > > the target AR > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 20 19:00: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 TAA25643 for ; Wed, 20 Jun 2001 19:00:36 -0400 (EDT) Received: (qmail 24193 invoked by alias); 20 Jun 2001 22:47:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24184 invoked by uid 200); 20 Jun 2001 22:47:35 -0000 Received: (qmail 24175 invoked from network); 20 Jun 2001 22:47:32 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:47:32 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA07493 for ; Wed, 20 Jun 2001 15:58:27 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA09463 for ; Wed, 20 Jun 2001 15:58:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 17:58:26 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 17:58:26 -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 Hello Rajeev: Please find my clarification. regards, ajoy Rajeev: When would you start CT in this case ? When does new AR receive L2 trigger ? Is it trying to do CT when it receives a HI ? Ajoy: In some network, it is easier to receive link layer trigger at the target access network much before the completion of link layer and network layer handoff. The trigger is available when link layer handover is in progress. For example, the target trigger can be available due to exchange of some link layer message from oldAR to newAR or may be from MN to newAR. I suppose this target trigger can be used to initiate so called reactive CT. Please note that there is big benefit of doing this. In this case, you know that MN is moving to a particular destination network, so you don't end up sending Context to unwanted ARs. In case of proactive CT, CT is initiated based upon some prediction which may not be always correct. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Wednesday, June 20, 2001 5:11 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > Rajeev: It's a good going trend to straighten things out. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > Rajeev: Reactive CT means that there is no context at the new AR when MN's packets arrive. If we want to do CT, I would think that that's a good time to start. Going by your argument, when do you start a reactive CT ? If we both agree that there is no context in place when the MN's packets arrive, what do you do ? If you had started CT before, that's proactive, but not working very well. Claiming that reactive CT is the "proactive CT gone bad" is extremely poor definition. I don't believe that I agreed at all to such a definition. Please enlighten me! > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. Rajeev: Where is this definition ? This can take another avatar of its own :-) > > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > Rajeev: If the context is not present when the MN's packet arrive, you try to get it. Right ? Why is that not reactive CT ? If CT is not there, and while I try to fetch it, why can't I forward the packets if it is possible ? If I *don't* forward packets, what do I do ? Drop them ? How's that good for TCP/RTP's performance ? Consider the ability to send and receive normal IP packets as a service (aka connectivity) upon which the rest of the CT features are based. For HC, you could forward on downlink. For security, you could forward the packets in both the directions until you receive the appropriate contexts. You may not have a packet *treated* with require feature, but you can still forward packets. If CT fails all together, what do you do ? You could require the MN to re-authenticate itself. How do you do that ? You need connectivity to send and receive IP packets. In a nut shell, if there are no contexts, you can always go fetch them *or* require the MN to re-establish them. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > Rajeev: When would you start CT in this case ? When does new AR receive L2 trigger ? Is it trying to do CT when it receives a HI ? I understand that when a packet arrives at new AR, the CT may be already "in progress", as indicated by the signaling that has taken place. The new AR may *still* initiate CT signaling and the old AR must be able to handle requests that come in sequence. It is called "idempotent" operation. Regards, -Rajeev > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 19:10:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25886 for ; Wed, 20 Jun 2001 19:10:03 -0400 (EDT) Received: (qmail 24746 invoked by alias); 20 Jun 2001 22:58:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24740 invoked by uid 200); 20 Jun 2001 22:58:14 -0000 Received: (qmail 24735 invoked from network); 20 Jun 2001 22:58:12 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 22:58:12 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA12563 for ; Wed, 20 Jun 2001 16:09:09 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA16943 for ; Wed, 20 Jun 2001 16:09:09 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 18:09:09 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 18:09:09 -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 Hello Rajeev: I think CT is required to support real time traffic. Can't I renegotiate the context in default case ? What is the saving in doing context transfer after completion of layer 3 handover? May be I am missing something. regards, ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 5:13 PM To: Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Hello Ajoy, Singh Ajoy-ASINGH1 wrote: > Hello Madjid: > I also like your definition of reactive handover. I do not think > doing context transfer after completion of layer 3 handover will > much sense. > Can you say why it does not make sense ? -Rajeev > regards, > ajoy > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 > [mailto:Madjid_Nakhjiri-MNAKHJI1@email.mot.com] > Sent: Wednesday, June 20, 2001 4:30 PM > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] proactive and reactive CT definitions > > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 19:46: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 TAA26621 for ; Wed, 20 Jun 2001 19:46:49 -0400 (EDT) Received: (qmail 25273 invoked by alias); 20 Jun 2001 23:34:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25267 invoked by uid 200); 20 Jun 2001 23:34:46 -0000 Received: (qmail 25262 invoked from network); 20 Jun 2001 23:34:44 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 23:34:44 -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 QAA05941; Wed, 20 Jun 2001 16:45:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5KNjBE16481; Wed, 20 Jun 2001 16:45:11 -0700 X-mProtect: Wed, 20 Jun 2001 16:45:11 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdPpb461; Wed, 20 Jun 2001 16:45:09 PDT Message-ID: <3B313586.9AF29CF5@iprg.nokia.com> Date: Wed, 20 Jun 2001 16:45:10 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Ajoy, Singh Ajoy-ASINGH1 wrote: > Hello Rajeev: > I think CT is required to support real time > traffic. Can't I renegotiate the > context in default case ? Rajeev: If you mean that the MN can re-establish the contexts, yes. > What is the saving in > doing context transfer after completion of layer 3 > handover? May be I am missing something. > Rajeev: Perhaps.. after L3 handover (i.e., the MN has IP connectivity), if the context is missing, doing re-establishment over a potentially narrow-band link is expensive. Doing CT over a higher-speed link between the ARs is a better option. Also, some could claim that it is not "seamless". Regards, -Rajeev > regards, > ajoy > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, June 20, 2001 5:13 PM > To: Singh Ajoy-ASINGH1 > Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Hello Ajoy, > > Singh Ajoy-ASINGH1 wrote: > > > Hello Madjid: > > I also like your definition of reactive handover. I do not think > > doing context transfer after completion of layer 3 handover will > > much sense. > > > > Can you say why it does not make sense ? > > -Rajeev > > > regards, > > ajoy > > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid_Nakhjiri-MNAKHJI1@email.mot.com] > > Sent: Wednesday, June 20, 2001 4:30 PM > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in agreement that > > reactive CT, does not always mean that CT cannot start until after the MN's > > packets have arrived. > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 19:57:55 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 TAA26797 for ; Wed, 20 Jun 2001 19:57:53 -0400 (EDT) Received: (qmail 25754 invoked by alias); 20 Jun 2001 23:45:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25748 invoked by uid 200); 20 Jun 2001 23:45:40 -0000 Received: (qmail 25743 invoked from network); 20 Jun 2001 23:45:39 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 23:45:39 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 19:56:07 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8053@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Wed, 20 Jun 2001 19:56:04 -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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, June 20, 2001 6:55 PM > To: Kulwinder Atwal > Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > Kulwinder Atwal wrote: > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Wednesday, June 20, 2001 6:16 PM > > > To: Kulwinder Atwal > > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org > > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > Hello Kulwinder, > > > > > > Kulwinder Atwal wrote: > Coming back to the point I have raised, I hope you would > agree that we have > to consider reactive CT independent of real-time nature of > the traffic. > Sometimes, all you have is basic connectivity, and you could use it to > reactively fetch contexts. I have always agreed with this. My primary concern is that a seperate mechanism exist to deal with Real-Time transfers such that lumping all context into a single packet is an optional feature not a requirement. I believe that section 5.5 Context Update and Synchronization would cover the real-time aspect and the reliability section provide a mechanism to ensure that all of the context was transmitted in case of packet loss. - Kulwinder. > > Regards, > > -Rajeev > > > > > - Kulwinder. > > > > > > > > > > > > > If I am doing a file download and loose 60mSec lets say to > > > Reactive CT, I > > > > will not notice as an End-User. > > > > > > > > > > Rajeev: good example. Not sufficient :-) > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > -----Original Message----- > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > Sent: Wednesday, June 20, 2001 5:30 PM > > > > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > > > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > > > > > > I still don't know whether I should respond to these > > > issues or not, > > > > > but it seems that is the going trend. > > > > > > > > > > For Proactive, your definition works, and actually it > is the same > > > > > as in the draft. > > > > > > > > > > I think this definition of reactive is going backward a bit. > > > > > We did discuss this issue at length and I think you were in > > > > > agreement that > > > > > reactive CT, does not always mean that CT cannot start until > > > > > after the MN's > > > > > packets have arrived. > > > > > > > > > > For reactive, CT can happens simultaneous as Handover > signaling > > > > > but it might not finish when handover signaling is complete. > > > > > > > > > > What you are suggesting, means that you don't need CT > to deliver > > > > > packets the mobile and are totally moving CT out of > the critical > > > > > path for timing. I guess say for header compression > > > > > it means that the newAR does not have HC states for a while, > > > > > assuming it can receive uncompressed packets, > > > > > But would this work for security and authentication, I > > > don't think so. > > > > > > > > > > I like the current definition for reactive: > > > > > "doing CT when handover is imminent" and that means > that oldAR or > > > > > newAR are already engaged in handover signaling, now > this could be > > > > > a L2 trigger that newAR has received or a HI or something > > > else, but > > > > > it does not mean completion of handover signaling and > > > packet routing > > > > > change. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > > > To: seamoby@cdma-2000.org > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions > are missing. > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > Section: 4.5 > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > The section provides the description of proactive and reactive > > > > > CT without properly defining what they are. We need the > > > definitions. > > > > > > > > > > Requested Change: > > > > > > > > > > Reactive CT: The context transfer process which takes > > > place subsequent > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > context transfer > > > > > process in which the required contexts are in place at > > > the target AR > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 20 20:02: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 UAA26959 for ; Wed, 20 Jun 2001 20:02:33 -0400 (EDT) Received: (qmail 26270 invoked by alias); 20 Jun 2001 23:49:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26264 invoked by uid 200); 20 Jun 2001 23:49:35 -0000 Received: (qmail 26259 invoked from network); 20 Jun 2001 23:49:34 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jun 2001 23:49:34 -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 RAA06798; Wed, 20 Jun 2001 17:00:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5L000502491; Wed, 20 Jun 2001 17:00:00 -0700 X-mProtect: Wed, 20 Jun 2001 17:00:00 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsc6y0e; Wed, 20 Jun 2001 16:59:58 PDT Message-ID: <3B3138FF.77C5F0BC@iprg.nokia.com> Date: Wed, 20 Jun 2001 16:59:59 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ajoy, see my replies in-line. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > Hello Rajeev: > Please find my clarification. > regards, > ajoy > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > Ajoy: In some network, it is easier to receive link layer trigger > at the target access network much before the completion of link layer and > network > layer handoff. The trigger is available when link layer handover > is in progress. For example, the target trigger can be available > due to exchange of some link layer message from oldAR to newAR or may be > from > MN to newAR. Rajeev: I guess what you describe could be called a "link-layer triggered CT". This is fine on those links where the link-layer trigger is available. Would go as far as saying that such a CT is reactive CT ? I would not.. > I suppose this target trigger can be used to > initiate so called reactive CT. Please note that there is big > benefit of doing this. Rajeev: I agree that there are benefits in using link layer triggers. There are also pitfalls. When you transfer context due to a link-layer trigger while the old AR is still forwarding packets, the contexts (on the new AR and old AR) are out of sync. > In this case, you know that MN is moving > to a particular destination network, so you don't end up sending > Context to unwanted ARs. In case of proactive CT, CT is initiated > based upon some prediction which may not be always correct. Rajeev: Well, proactive need not mean that we don't know where the MN is going (and thus we will CT to many ARs). Anyway, let me indicate to you the two cases below. 1. We know well in advance the MN is going to new AR. So we do the CT to that AR so that all the contexts are in place before the first packet arrives at new AR. You could make use of link-layer triggers here. 2. Due to network conditions, the MN looses its link with old AR and shows up (after a while) at new AR. You could do CT here after the first packet from the MN arrives. Perhaps you could make use of link-layer triggers here as well. We could call 1> proactive or predictive, and 2> reactive. How's that ? > > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 5:11 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > Rajeev: It's a good going trend to straighten things out. > > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in agreement that > > reactive CT, does not always mean that CT cannot start until after the > MN's > > packets have arrived. > > > > Rajeev: Reactive CT means that there is no context at the new AR when MN's > packets arrive. If we want to do CT, I would think that that's a good time > to > start. > Going by your argument, when do you start a reactive CT ? If we both agree > that > there is no context in place when the MN's packets arrive, what do you do ? > If > you had started CT before, that's proactive, but not working very well. > Claiming that reactive CT is the "proactive CT gone bad" is extremely poor > definition. I don't believe that I agreed at all to such a definition. > Please > enlighten me! > > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > Rajeev: Where is this definition ? This can take another avatar of its own > :-) > > > > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > Rajeev: If the context is not present when the MN's packet arrive, you try > to > get it. Right ? Why is that not reactive CT ? If CT is not there, and while > I try to fetch it, why can't I forward the packets if it is possible ? If > I *don't* forward packets, what do I do ? Drop them ? How's that good for > TCP/RTP's performance ? Consider the ability to send and receive normal IP > packets as a service (aka connectivity) upon which the rest of the CT > features > are based. > > For HC, you could forward on downlink. For security, you could forward the > packets in both the directions until you receive the appropriate contexts. > You > may not have a packet *treated* with require feature, but you can still > forward > packets. If CT fails all together, what do you do ? You could require the MN > to > re-authenticate itself. How do you do that ? You need connectivity to send > and > receive IP packets. > In a nut shell, if there are no contexts, you can always go fetch them *or* > require the MN to re-establish them. > > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > I understand that when a packet arrives at new AR, the CT may be already "in > progress", as indicated by the signaling that has taken place. The new AR > may > *still* initiate CT signaling and the old AR must be able to handle requests > that come in sequence. It is called "idempotent" operation. > > Regards, > > -Rajeev > > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 20:14: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 UAA27108 for ; Wed, 20 Jun 2001 20:14:23 -0400 (EDT) Received: (qmail 26880 invoked by alias); 21 Jun 2001 00:02:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26874 invoked by uid 200); 21 Jun 2001 00:02:03 -0000 Received: (qmail 26861 invoked from network); 21 Jun 2001 00:02:00 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 00:02:00 -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 RAA07877; Wed, 20 Jun 2001 17:12:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5L0CRb16442; Wed, 20 Jun 2001 17:12:27 -0700 X-mProtect: Wed, 20 Jun 2001 17:12:27 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdDAdt1y; Wed, 20 Jun 2001 17:12:26 PDT Message-ID: <3B313BEA.A3DC0EC9@iprg.nokia.com> Date: Wed, 20 Jun 2001 17:12:26 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kulwinder Atwal CC: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8053@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: > > > Coming back to the point I have raised, I hope you would > > agree that we have > > to consider reactive CT independent of real-time nature of > > the traffic. > > Sometimes, all you have is basic connectivity, and you could use it to > > reactively fetch contexts. > > I have always agreed with this. My primary concern is that a seperate > mechanism exist to deal with Real-Time transfers such that lumping all > context into a single packet is an optional feature not a requirement. > Rajeev: Good. Let's see if we can separate the issues here. a> reactive CT should include all types of contexts. It is initiated when the new AR receives an IP packet for MN for which there is no context present. b> Lumping all the contexts may not be a good idea. I believe this was the point Pat made as well. > > I believe that section 5.5 Context Update and Synchronization would cover > the real-time aspect and the reliability section provide a mechanism to > ensure that all of the context was transmitted in case of packet loss. Rajeev: Context update and synchronization is not clear to me, for the moment at least. We will see what happens with the reliability section. Regards, -Rajeev > > > - Kulwinder. > > > > > Regards, > > > > -Rajeev > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > If I am doing a file download and loose 60mSec lets say to > > > > Reactive CT, I > > > > > will not notice as an End-User. > > > > > > > > > > > > > Rajeev: good example. Not sufficient :-) > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > -----Original Message----- > > > > > > From: Nakhjiri Madjid-MNAKHJI1 > > > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > > > Sent: Wednesday, June 20, 2001 5:30 PM > > > > > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > > > > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still don't know whether I should respond to these > > > > issues or not, > > > > > > but it seems that is the going trend. > > > > > > > > > > > > For Proactive, your definition works, and actually it > > is the same > > > > > > as in the draft. > > > > > > > > > > > > I think this definition of reactive is going backward a bit. > > > > > > We did discuss this issue at length and I think you were in > > > > > > agreement that > > > > > > reactive CT, does not always mean that CT cannot start until > > > > > > after the MN's > > > > > > packets have arrived. > > > > > > > > > > > > For reactive, CT can happens simultaneous as Handover > > signaling > > > > > > but it might not finish when handover signaling is complete. > > > > > > > > > > > > What you are suggesting, means that you don't need CT > > to deliver > > > > > > packets the mobile and are totally moving CT out of > > the critical > > > > > > path for timing. I guess say for header compression > > > > > > it means that the newAR does not have HC states for a while, > > > > > > assuming it can receive uncompressed packets, > > > > > > But would this work for security and authentication, I > > > > don't think so. > > > > > > > > > > > > I like the current definition for reactive: > > > > > > "doing CT when handover is imminent" and that means > > that oldAR or > > > > > > newAR are already engaged in handover signaling, now > > this could be > > > > > > a L2 trigger that newAR has received or a HI or something > > > > else, but > > > > > > it does not mean completion of handover signaling and > > > > packet routing > > > > > > change. > > > > > > > > > > > > Madjid > > > > > > > > > > > > -----Original Message----- > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > > > > To: seamoby@cdma-2000.org > > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions > > are missing. > > > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > > > Section: 4.5 > > > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > The section provides the description of proactive and reactive > > > > > > CT without properly defining what they are. We need the > > > > definitions. > > > > > > > > > > > > Requested Change: > > > > > > > > > > > > Reactive CT: The context transfer process which takes > > > > place subsequent > > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > > context transfer > > > > > > process in which the required contexts are in place at > > > > the target AR > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 20 20:36: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 UAA27343 for ; Wed, 20 Jun 2001 20:36:01 -0400 (EDT) Received: (qmail 27444 invoked by alias); 21 Jun 2001 00:22:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27438 invoked by uid 200); 21 Jun 2001 00:22:52 -0000 Received: (qmail 27432 invoked from network); 21 Jun 2001 00:22:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 00:22:50 -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 RAA09046; Wed, 20 Jun 2001 17:33:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5L0XIK01639; Wed, 20 Jun 2001 17:33:18 -0700 X-mProtect: Wed, 20 Jun 2001 17:33:18 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIQ6TD7; Wed, 20 Jun 2001 17:33:16 PDT Message-ID: <3B3140CC.BB9622AF@iprg.nokia.com> Date: Wed, 20 Jun 2001 17:33:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Koodli CC: Singh Ajoy-ASINGH1 , Nakhjiri Madjid-MNAKHJI1 , seamoby@diameter.org Subject: Re: [seamoby]reactive CT definition References: <3B3138FF.77C5F0BC@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit in my mind Reactive Context transfer - MN looses its link with the oldAR and shows up at the newAR. the MN supplies both the oldCoA. the newAR requests the oldAR to transfer context related to the MN. the oldAR supplies it. the newAR instantiates the context.... till this happens a few packets get dropped. you do the context transfer fast enough so that the MN does not have to 1. go through establishing a security association with the access router again (this could take more than 2 seconds if AAA is used) 2. set up header compression state again... 3. and etc... this IS reactive context transfer. basically you are reacting to the handover. Vijay Rajeev Koodli wrote: > > Ajoy, > > see my replies in-line. > > Regards, > > -Rajeev > > Singh Ajoy-ASINGH1 wrote: > > > Hello Rajeev: > > Please find my clarification. > > regards, > > ajoy > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > > trigger ? Is it trying to do CT when it receives a HI ? > > > > Ajoy: In some network, it is easier to receive link layer trigger > > at the target access network much before the completion of link layer and > > network > > layer handoff. The trigger is available when link layer handover > > is in progress. For example, the target trigger can be available > > due to exchange of some link layer message from oldAR to newAR or may be > > from > > MN to newAR. > > Rajeev: I guess what you describe could be called a "link-layer triggered CT". > This is fine on those links where the link-layer trigger is available. Would go > as far as saying that such a CT is reactive CT ? I would not.. > > > I suppose this target trigger can be used to > > initiate so called reactive CT. Please note that there is big > > benefit of doing this. > > Rajeev: I agree that there are benefits in using link layer triggers. There are > also pitfalls. When you transfer context due to a link-layer trigger while the > old AR is still forwarding packets, the contexts (on the new AR and old AR) are > out of sync. > > > In this case, you know that MN is moving > > to a particular destination network, so you don't end up sending > > Context to unwanted ARs. In case of proactive CT, CT is initiated > > based upon some prediction which may not be always correct. > > Rajeev: Well, proactive need not mean that we don't know where the MN is going > (and thus we will CT to many ARs). Anyway, let me indicate to you the two cases > below. > > 1. We know well in advance the MN is going to new AR. So we do the CT to that > AR so that all the contexts are in place before the first packet arrives at new > AR. You could make use of link-layer triggers here. > > 2. Due to network conditions, the MN looses its link with old AR and shows up > (after a while) at new AR. You could do CT here after the first packet from the > MN arrives. Perhaps you could make use of link-layer triggers here as well. > > We could call 1> proactive or predictive, and 2> reactive. How's that ? > > > > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 5:11 PM > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > I still don't know whether I should respond to these issues or not, > > > but it seems that is the going trend. > > > > > > > Rajeev: It's a good going trend to straighten things out. > > > > > > > > For Proactive, your definition works, and actually it is the same > > > as in the draft. > > > > > > I think this definition of reactive is going backward a bit. > > > We did discuss this issue at length and I think you were in agreement that > > > reactive CT, does not always mean that CT cannot start until after the > > MN's > > > packets have arrived. > > > > > > > Rajeev: Reactive CT means that there is no context at the new AR when MN's > > packets arrive. If we want to do CT, I would think that that's a good time > > to > > start. > > Going by your argument, when do you start a reactive CT ? If we both agree > > that > > there is no context in place when the MN's packets arrive, what do you do ? > > If > > you had started CT before, that's proactive, but not working very well. > > Claiming that reactive CT is the "proactive CT gone bad" is extremely poor > > definition. I don't believe that I agreed at all to such a definition. > > Please > > enlighten me! > > > > > > > > For reactive, CT can happens simultaneous as Handover signaling > > > but it might not finish when handover signaling is complete. > > > > Rajeev: Where is this definition ? This can take another avatar of its own > > :-) > > > > > > > > > > > What you are suggesting, means that you don't need CT to deliver > > > packets the mobile and are totally moving CT out of the critical > > > path for timing. I guess say for header compression > > > it means that the newAR does not have HC states for a while, > > > assuming it can receive uncompressed packets, > > > But would this work for security and authentication, I don't think so. > > > > > > > Rajeev: If the context is not present when the MN's packet arrive, you try > > to > > get it. Right ? Why is that not reactive CT ? If CT is not there, and while > > I try to fetch it, why can't I forward the packets if it is possible ? If > > I *don't* forward packets, what do I do ? Drop them ? How's that good for > > TCP/RTP's performance ? Consider the ability to send and receive normal IP > > packets as a service (aka connectivity) upon which the rest of the CT > > features > > are based. > > > > For HC, you could forward on downlink. For security, you could forward the > > packets in both the directions until you receive the appropriate contexts. > > You > > may not have a packet *treated* with require feature, but you can still > > forward > > packets. If CT fails all together, what do you do ? You could require the MN > > to > > re-authenticate itself. How do you do that ? You need connectivity to send > > and > > receive IP packets. > > In a nut shell, if there are no contexts, you can always go fetch them *or* > > require the MN to re-establish them. > > > > > > > > I like the current definition for reactive: > > > "doing CT when handover is imminent" and that means that oldAR or > > > newAR are already engaged in handover signaling, now this could be > > > a L2 trigger that newAR has received or a HI or something else, but > > > it does not mean completion of handover signaling and packet routing > > > change. > > > > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > > trigger ? Is it trying to do CT when it receives a HI ? > > > > I understand that when a packet arrives at new AR, the CT may be already "in > > progress", as indicated by the signaling that has taken place. The new AR > > may > > *still* initiate CT signaling and the old AR must be able to handle requests > > that come in sequence. It is called "idempotent" operation. > > > > Regards, > > > > -Rajeev > > > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > Submitter name: Rajeev Koodli > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > Date first submitted: June 20, 2001 > > > > > > Comment type: 'T'echnical > > > > > > Priority: ''S'/MUST fix > > > > > > Section: 4.5 > > > > > > Rationale/Explanation of issue: > > > > > > The section provides the description of proactive and reactive > > > CT without properly defining what they are. We need the definitions. > > > > > > Requested Change: > > > > > > Reactive CT: The context transfer process which takes place subsequent > > > to arrival of a MN's packet at the target AR > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > > process in which the required contexts are in place at the target AR > > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Wed Jun 20 20:41: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 UAA27381 for ; Wed, 20 Jun 2001 20:41:06 -0400 (EDT) Received: (qmail 27526 invoked by alias); 21 Jun 2001 00:23:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27520 invoked by uid 200); 21 Jun 2001 00:23:31 -0000 Received: (qmail 27507 invoked from network); 21 Jun 2001 00:23:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 00:23:25 -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 RAA09073; Wed, 20 Jun 2001 17:33:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5L0Xne02324; Wed, 20 Jun 2001 17:33:49 -0700 X-mProtect: Wed, 20 Jun 2001 17:33:49 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdvlkDIg; Wed, 20 Jun 2001 17:33:47 PDT Message-ID: <3B3140EC.9EB61F89@iprg.nokia.com> Date: Wed, 20 Jun 2001 17:33:48 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Gary Kenward , "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> <20010618135157.Z17928@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, consider that the MN just shows up at new AR. I mean it looses its current link, and gets a new one with new AR. After it establishes the link, the MN sends an IP message (just as it would send a Binding Update) to the new AR providing its previous IP address and previous AR address. The new AR contacts the old AR to fetch contexts. How's that ? -Rajeev Pat Calhoun wrote: > Rajeev, > > I believe I've already asked for this, but let me try again. > > Could you please provide me with an example of when this would be > necessary? Some justification would be useful in my mind. > > PatC > On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote: > > Rajeev: > > > > The current requirements in no way prohibit signalling from the MN. > > Myself and others have re-iterated this many times on the list. > > > > o the trigger arrives at an AR at L3; the source is not specified, > > and considered out of scope for CT. > > > > o CT must provide the mechanisms to allow per microflow enable/disable; > > the control protocols are not specified and considered out of scope for > > CT. > > > > Nothing you have said contradicts the above requirements. The only issue > > seems to be that you and others want an explicit requirement so that the > > design > > task for these protocols are explicitly part of CT. This would mean not only > > that > > we will have to add MN signalling, but also signalling from other sources, > > including > > L2 (?). Sounds like a lot of effort to me, and the solutions could > > unnecessarily > > constrain CT. > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Monday, June 18, 2001 2:32 PM > > > To: James Kempf > > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & Authorization ... > > > > > > > > > > > > Hello James, > > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > > do L2 triggering > > > in all cases as well. > > > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > > as Gary points out, performance will suffer. > > > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > > > > If there's an L2 trigger, > > > > it should be used preferentially. > > > > > > Rajeev: certainly. It is one thing to say that if there is a > > > L2 trigger, it > > > should be used preferentially, but another thing to say that > > > we disallow using > > > L3 messages to trigger CT. We should have the possibility of > > > MN requesting CT. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > > Valley Messaging > > > > Protection > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > > >From: Rajeev Koodli > > > > >To: Singh Ajoy-ASINGH1 > > > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > > > , "'seamoby'" > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & > > > > Authorization ... > > > > > > > > > > > > > > >Hello Ajoy, > > > > > > > > > >whereas use of link-layer triggers is very useful, it is > > > not something we > > > > >can rely upon to be present everywhere (as you correctly > > > point out for > > > > >Inter-technology handovers). I don't think we ever said we > > > disallow link > > > > >layer triggers. We must not say that that's our solution. > > > At the IP layer, > > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > > > >Regards, > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > > >> access router which can be used to initiate context transfer. > > > > >> This will be mostly useful in case of some intra-technology > > > > >> handovers. In case MN moves across different technologies, yes > > > > >> some sort of MN trigger is useful. Having said that is it a > > > > >> good idea to limit the scope of CT protocol? I think we > > > > >> should allow both the options. > > > > >> regards, > > > > >> ajoy > > > > >> > > > > > > [snip, snip] > > > > > > From owner-seamoby@diameter.org Wed Jun 20 20:44: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 UAA27421 for ; Wed, 20 Jun 2001 20:44:55 -0400 (EDT) Received: (qmail 27809 invoked by alias); 21 Jun 2001 00:26:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27803 invoked by uid 200); 21 Jun 2001 00:26:21 -0000 Received: (qmail 27790 invoked from network); 21 Jun 2001 00:26:17 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 00:26:17 -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 RAA09155; Wed, 20 Jun 2001 17:36:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5L0afk03245; Wed, 20 Jun 2001 17:36:41 -0700 X-mProtect: Wed, 20 Jun 2001 17:36:41 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHQOYhX; Wed, 20 Jun 2001 17:36:39 PDT Message-ID: <3B314198.424DCF80@iprg.nokia.com> Date: Wed, 20 Jun 2001 17:36:40 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward wrote: > Rajeev: > > The current requirements in no way prohibit signalling from the MN. > Myself and others have re-iterated this many times on the list. > > o the trigger arrives at an AR at L3; the source is not specified, > and considered out of scope for CT. > > o CT must provide the mechanisms to allow per microflow enable/disable; > the control protocols are not specified and considered out of scope for > CT. > > Nothing you have said contradicts the above requirements. The only issue > seems to be that you and others want an explicit requirement so that the > design > task for these protocols are explicitly part of CT. This would mean not only > that > we will have to add MN signalling, but also signalling from other sources, > including > L2 (?). Sounds like a lot of effort to me, and the solutions could > unnecessarily > constrain CT. > Rajeev: why would we have to add L2 signaling ? An IP message to initiate CT would be needed for the MN and is perhaps useful for other entities. I think it is doable. -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Monday, June 18, 2001 2:32 PM > > To: James Kempf > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & Authorization ... > > > > > > > > Hello James, > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > do L2 triggering > > in all cases as well. > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > as Gary points out, performance will suffer. > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > If there's an L2 trigger, > > > it should be used preferentially. > > > > Rajeev: certainly. It is one thing to say that if there is a > > L2 trigger, it > > should be used preferentially, but another thing to say that > > we disallow using > > L3 messages to trigger CT. We should have the possibility of > > MN requesting CT. > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > jak > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > Valley Messaging > > > Protection > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > >From: Rajeev Koodli > > > >To: Singh Ajoy-ASINGH1 > > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > > , "'seamoby'" > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > Authentication & > > > Authorization ... > > > > > > > > > > > >Hello Ajoy, > > > > > > > >whereas use of link-layer triggers is very useful, it is > > not something we > > > >can rely upon to be present everywhere (as you correctly > > point out for > > > >Inter-technology handovers). I don't think we ever said we > > disallow link > > > >layer triggers. We must not say that that's our solution. > > At the IP layer, > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > >Regards, > > > > > > > >-Rajeev > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > >> access router which can be used to initiate context transfer. > > > >> This will be mostly useful in case of some intra-technology > > > >> handovers. In case MN moves across different technologies, yes > > > >> some sort of MN trigger is useful. Having said that is it a > > > >> good idea to limit the scope of CT protocol? I think we > > > >> should allow both the options. > > > >> regards, > > > >> ajoy > > > >> > > > > [snip, snip] > > > > From owner-seamoby@diameter.org Thu Jun 21 02:11: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 CAA16370 for ; Thu, 21 Jun 2001 02:11:32 -0400 (EDT) Received: (qmail 29370 invoked by alias); 21 Jun 2001 06:00:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29364 invoked by uid 200); 21 Jun 2001 06:00:01 -0000 Received: (qmail 29357 invoked from network); 21 Jun 2001 05:59:59 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 05:59:59 -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 f5L6BCI04380 for ; Thu, 21 Jun 2001 09:11:12 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 21 Jun 2001 09:10:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 21 Jun 2001 09:10:56 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B154@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Thu, 21 Jun 2001 09:10:55 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Madjid, > What is a "common" IP level trigger mean here? common with what? Common might not be the correct term, perhaps standard would be better? Of course, going into standard IP triggers gets into an API issue. Should we go down that road already? > What is the difference between "signalling to initiate context tranfer > (which is a CT trigger)" and "common IP level triggers". I am making a seperation between an explicit message (i.e. - signaling) and the arrival of some data (which could be a trigger). > Don't get me wrong, I think I was among the very first people who > talked about CT trigger, but I am not sure I see the > difference the two. I think the difference (in my mind) is whether we have implicit signaling or explicit signaling. More comments in my next mail. John From owner-seamoby@diameter.org Thu Jun 21 02:23: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 CAA17345 for ; Thu, 21 Jun 2001 02:23:50 -0400 (EDT) Received: (qmail 29875 invoked by alias); 21 Jun 2001 06:12:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29869 invoked by uid 200); 21 Jun 2001 06:12:15 -0000 Received: (qmail 29863 invoked from network); 21 Jun 2001 06:12:13 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 06:12:13 -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 f5L6MG907841 for ; Thu, 21 Jun 2001 09:22:16 +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, 21 Jun 2001 09:23:04 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 21 Jun 2001 09:23:04 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B155@eseis04nok> From: john.loughney@nokia.com To: hmsyed@nortelnetworks.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Thu, 21 Jun 2001 09:23:01 +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 Hamid, > see my rssponse below. > [Syed, Hamid [WDLN2:AN22:EXCH]] Well. Any layer 2 mechanism is out > of the IETF scope. It will also be layer 2 technology specific which > we are trying to avoid. Definitely each layer 2 technology can define > its own meachnism to trigger the common IP layer triggers for context > transfer. If we work on layer 3 triggers, it would be well within the ct scope. Well, I think that standardizing layer 2 info is outside of the scope of the IETF, supporting layer 2 info is not outside of the scope - but it is an implementation dependent issue. All I seek is that we don't disallow layer 2 triggers in addition to layer 3 triggers. Layer 3 triggers are a bit tricky, in my opinion, because layer 3 triggers may be impacted by the OS you are using, the seperation between user space & kernel space, etc. I think this is work that needs to be done, but I'm not so sure it should be embedded within a SeaMoby document. > > 4.4 Context transfer SHOULD separate the signaling to initiate Context > > Transfer from the transfer of context. > [Syed, Hamid [WDLN2:AN22:EXCH]] I would rather prefer MUST for 4.4. See > my comment below. > > 4.4 is a SHOULD I think. What is the need for seperating signaling and > > transfer of context? If I am an AR, and I get a message 'Here is new header > > compression state for mobile node x' - I might be able to think that means > > that mobile node x is going to be coming to me soon ... > [Syed, Hamid [WDLN2:AN22:EXCH]] The source of signaling could be MN, AR > or any entity in the access network (ref: the description part of the > requirements) while the context transfer happens between the old and new > ARs. That is why the signaling MUST be separated from the actual transfer > of context. Perhaps we are debating if the signaling is implicit or explicit. Would modifying the above to: 4.4 Context transfer MUST be able to separate the signaling to initiate Context Transfer from the transfer of context. This would allow seperate signaling where needed, but also allow the context transfer itself to act as signaling as well. br, John From owner-seamoby@diameter.org Thu Jun 21 02:34: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 CAA18115 for ; Thu, 21 Jun 2001 02:34:09 -0400 (EDT) Received: (qmail 30351 invoked by alias); 21 Jun 2001 06:22:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30345 invoked by uid 200); 21 Jun 2001 06:22:43 -0000 Received: (qmail 30340 invoked from network); 21 Jun 2001 06:22:41 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 06:22:41 -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 f5L6Wj913287 for ; Thu, 21 Jun 2001 09:32:45 +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, 21 Jun 2001 09:33:31 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 21 Jun 2001 09:33:31 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B157@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Date: Thu, 21 Jun 2001 09:33:30 +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 > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). I agree with you. I think 4.9 should be rewritten so that the whole enchalada can be sent at once, but does not have to be. br, John From owner-seamoby@diameter.org Thu Jun 21 02: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 CAA18351 for ; Thu, 21 Jun 2001 02:36:35 -0400 (EDT) Received: (qmail 30835 invoked by alias); 21 Jun 2001 06:25:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30829 invoked by uid 200); 21 Jun 2001 06:25:06 -0000 Received: (qmail 30824 invoked from network); 21 Jun 2001 06:25:04 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 06:25:04 -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 f5L6aHI15140 for ; Thu, 21 Jun 2001 09:36:17 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 21 Jun 2001 09:35:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 21 Jun 2001 09:35:56 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B158@eseis04nok> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: RE: [seamoby] Question on 4.2 Date: Thu, 21 Jun 2001 09:35:54 +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, > I do recall a recent discussion on this, so I appologize if > this has already come up. Does the following text, which appears > under section 4.2, imply that seamoby will define the triggers? > > " This implies that there are general > characteristics of an IP level trigger that need to be defined so > that the triggers generated by different layer 2 solutions > will have identical semantics at the IP level." This I am not sure of, and this gets to my point about it being much more of an API issue. Can we re-word the text so that IP level triggers are supported (but don't have to go into the dirty details of what they are yet)? John From owner-seamoby@diameter.org Thu Jun 21 07:00: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 HAA23241 for ; Thu, 21 Jun 2001 07:00:11 -0400 (EDT) Received: (qmail 500 invoked by alias); 21 Jun 2001 10:48:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 493 invoked by uid 200); 21 Jun 2001 10:48:29 -0000 Received: (qmail 488 invoked from network); 21 Jun 2001 10:48:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 10:48:27 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22983; Thu, 21 Jun 2001 06:58:49 -0400 (EDT) Message-Id: <200106211058.GAA22983@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-ct-reqs-00.txt Date: Thu, 21 Jun 2001 06:58:49 -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 Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting Working Group of the IETF. Title : General Requirements for a Context Transfer Framework Author(s) : H. Syed, G. Kenward et al. Filename : draft-ietf-seamoby-ct-reqs-00.txt Pages : Date : 20-Jun-01 The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily on the ability to minimize the impact of the traffic redirection during a change of packet forwarding path. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The transfer of context information may be advantageous in minimizing the impact of host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ct-reqs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-ct-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010620132108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-ct-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-ct-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010620132108.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Jun 21 09:11: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 JAA27151 for ; Thu, 21 Jun 2001 09:10:47 -0400 (EDT) Received: (qmail 1354 invoked by alias); 21 Jun 2001 12:55:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1348 invoked by uid 200); 21 Jun 2001 12:55:01 -0000 Received: (qmail 1343 invoked from network); 21 Jun 2001 12:54:59 -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; 21 Jun 2001 12:54:59 -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 f5LD5C007551 for ; Thu, 21 Jun 2001 09:05:15 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 21 Jun 2001 09:05:05 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:05:08 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD100@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Rajeev Koodli'" , "Gary Kenward" Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Thu, 21 Jun 2001 09:05:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA52.CAC2CC00" 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_01C0FA52.CAC2CC00 Content-Type: text/plain; charset="iso-8859-1" Rajeev, I would suggest you to look at the issue # 2 and the proposed changes by Kulwinder. The text and requirements proposed sounds good to me. cheers -Hamid > -----Original Message----- > From: Rajeev Koodli [SMTP:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 8:37 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'seamoby' > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > Gary Kenward wrote: > > > Rajeev: > > > > The current requirements in no way prohibit signalling from the MN. > > Myself and others have re-iterated this many times on the list. > > > > o the trigger arrives at an AR at L3; the source is not specified, > > and considered out of scope for CT. > > > > o CT must provide the mechanisms to allow per microflow > enable/disable; > > the control protocols are not specified and considered out of scope > for > > CT. > > > > Nothing you have said contradicts the above requirements. The only > issue > > seems to be that you and others want an explicit requirement so that the > > design > > task for these protocols are explicitly part of CT. This would mean not > only > > that > > we will have to add MN signalling, but also signalling from other > sources, > > including > > L2 (?). Sounds like a lot of effort to me, and the solutions could > > unnecessarily > > constrain CT. > > > > Rajeev: why would we have to add L2 signaling ? An IP message to initiate > CT would be needed for the MN and is perhaps useful for other entities. I > think > it is doable. > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Monday, June 18, 2001 2:32 PM > > > To: James Kempf > > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & Authorization ... > > > > > > > > > > > > Hello James, > > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > > do L2 triggering > > > in all cases as well. > > > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > > as Gary points out, performance will suffer. > > > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > > > > If there's an L2 trigger, > > > > it should be used preferentially. > > > > > > Rajeev: certainly. It is one thing to say that if there is a > > > L2 trigger, it > > > should be used preferentially, but another thing to say that > > > we disallow using > > > L3 messages to trigger CT. We should have the possibility of > > > MN requesting CT. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > > Valley Messaging > > > > Protection > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > > >From: Rajeev Koodli > > > > >To: Singh Ajoy-ASINGH1 > > > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > > > , "'seamoby'" > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > Authentication & > > > > Authorization ... > > > > > > > > > > > > > > >Hello Ajoy, > > > > > > > > > >whereas use of link-layer triggers is very useful, it is > > > not something we > > > > >can rely upon to be present everywhere (as you correctly > > > point out for > > > > >Inter-technology handovers). I don't think we ever said we > > > disallow link > > > > >layer triggers. We must not say that that's our solution. > > > At the IP layer, > > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > > > >Regards, > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > > >> access router which can be used to initiate context transfer. > > > > >> This will be mostly useful in case of some intra-technology > > > > >> handovers. In case MN moves across different technologies, yes > > > > >> some sort of MN trigger is useful. Having said that is it a > > > > >> good idea to limit the scope of CT protocol? I think we > > > > >> should allow both the options. > > > > >> regards, > > > > >> ajoy > > > > >> > > > > > > [snip, snip] > > > > > > > ------_=_NextPart_001_01C0FA52.CAC2CC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication = & Authorization ...

Rajeev,

I would suggest you = to look at the issue # 2 and the proposed changes by Kulwinder. The = text and requirements proposed sounds good to me.

cheers

-Hamid

    -----Original Message-----
    From:   Rajeev Koodli = [SMTP:rajeev@IPRG.nokia.com]
    Sent:   Wednesday, June 20, 2001 8:37 PM
    To:     Kenward, Gary [WDLN2:AN10:EXCH]
    Cc:     'seamoby'
    Subject:       = Re: Reactive CT definition: Was Re: = [seamoby] RE: Authentication &  Authorization ...

    Gary Kenward wrote:

    > Rajeev:
    >
    >   The current = requirements in no way prohibit signalling from the MN.
    > Myself and others have = re-iterated this many times on the list.
    >
    >   o the trigger = arrives at an AR at L3; the source is not specified,
    >     and = considered out of scope for CT.
    >
    >   o CT must provide = the mechanisms to allow per microflow enable/disable;
    >     the = control protocols are not specified and considered out of scope = for
    > CT.
    >
    >   Nothing you have = said contradicts the above requirements. The only issue
    > seems to be that you and others = want an explicit requirement so that the
    > design
    > task for these protocols are = explicitly part of CT. This would mean not only
    > that
    > we will have to add MN = signalling, but also signalling from other sources,
    > including
    > L2 (?). Sounds like a lot of = effort to me, and the solutions could
    > unnecessarily
    > constrain CT.
    >

    Rajeev: why would we have to add L2 = signaling ? An IP message to initiate
    CT would be needed for the MN and is = perhaps useful for other entities. I think
    it is doable.

    -Rajeev


    >
    > Gary
    >
    > > -----Original = Message-----
    > > From: Rajeev Koodli = [mailto:rajeev@IPRG.nokia.com]
    > > Sent: Monday, June 18, 2001 = 2:32 PM
    > > To: James Kempf
    > > Cc: ASINGH1@motorola.com; = kulwinder.atwal@zucotto.com; Kenward, Gary
    > > [WDLN2:AN10:EXCH]; = seamoby@diameter.org
    > > Subject: Re: Reactive CT = definition: Was Re: [seamoby] RE:
    > > Authentication & = Authorization ...
    > >
    > >
    > >
    > > Hello James,
    > >
    > > James Kempf wrote:
    > >
    > > > Rajeev,
    > > >
    > > > I don't think we can = require L3 triggering in all cases. We need
    > > >
    > >
    > > Rajeev: Unfortunately, I = think we cannot require that the MN
    > > do L2 triggering
    > > in all cases as = well.
    > >
    > > > to make sure that an = MN not need to do L3 triggering, otherwise,
    > > > as Gary points out, = performance will suffer.
    > >
    > > Rajeev: yes in some links, = may be (or no impact) in others.
    > >
    > >
    > > > If there's an L2 = trigger,
    > > > it should be used = preferentially.
    > >
    > > Rajeev: certainly. It is = one thing to say that if there is a
    > > L2 trigger, it
    > > should be used = preferentially, but another thing to say that
    > > we disallow using
    > > L3 messages to trigger CT. = We should have the possibility of
    > > MN requesting CT.
    > >
    > > Regards,
    > >
    > > -Rajeev
    > >
    > >
    > > >
    > > >
    > > = >           &n= bsp;     jak
    > > >
    > > > >Delivered-To: = seamoby-list@charizard.diameter.org
    > > > >X-mProtect: Fri, = 15 Jun 2001 11:59:37 -0700 Nokia Silicon
    > > Valley Messaging
    > > > Protection
    > > > >Date: Fri, 15 Jun = 2001 11:59:37 -0700
    > > > >From: Rajeev = Koodli <rajeev@IPRG.nokia.com>
    > > > >To: Singh = Ajoy-ASINGH1 <ASINGH1@motorola.com>
    > > > >CC: = "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, Gary = Kenward
    > > > = <gkenward@nortelnetworks.com>, "'seamoby'" = <seamoby@diameter.org>
    > > > >Subject: Re: = Reactive CT definition: Was Re: [seamoby] RE:
    > > Authentication &
    > > > Authorization = ...
    > > > >
    > > > >
    > > > >Hello Ajoy,
    > > > >
    > > > >whereas use of = link-layer triggers is very useful, it is
    > > not something we
    > > > >can rely upon to = be present everywhere (as you correctly
    > > point out for
    > > > >Inter-technology = handovers). I don't think we ever said we
    > > disallow link
    > > > >layer triggers. We = must not say that that's our solution.
    > > At the IP layer,
    > > > >we need to define = IP messages. I think we pretty much agree.
    > > > >
    > > > >Regards,
    > > > >
    > > > >-Rajeev
    > > > >
    > > > >
    > > > >Singh Ajoy-ASINGH1 = wrote:
    > > > >
    > > > >> I think it is = possible to receive link layer trigger at the new
    > > > >> access router = which can be used to initiate context transfer.
    > > > >> This will be = mostly useful in case of some intra-technology
    > > > >> handovers. In = case MN moves across different technologies, yes
    > > > >> some sort of = MN trigger is useful. Having said that is it a
    > > > >> good idea to = limit the scope of CT protocol? I think we
    > > > >> should allow = both the options.
    > > > >> = regards,
    > > > >> ajoy
    > > > >>
    > >
    > > [snip, snip]
    > >
    > >

------_=_NextPart_001_01C0FA52.CAC2CC00-- From owner-seamoby@diameter.org Thu Jun 21 09:22: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 JAA27624 for ; Thu, 21 Jun 2001 09:22:23 -0400 (EDT) Received: (qmail 1648 invoked by alias); 21 Jun 2001 13:01:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1641 invoked by uid 200); 21 Jun 2001 13:00:59 -0000 Received: (qmail 1626 invoked from network); 21 Jun 2001 13:00:52 -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; 21 Jun 2001 13:00:52 -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 f5LDAt008595; Thu, 21 Jun 2001 09:10:55 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 21 Jun 2001 09:10:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:10:48 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD101@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Rajeev Koodli'" , Pat Calhoun Cc: "Gary Kenward" , "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Thu, 21 Jun 2001 09:10:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA53.94F35B20" 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_01C0FA53.94F35B20 Content-Type: text/plain; charset="iso-8859-1" Rajeev, By the time the context arrives at the new AR and processed (e.g. for resource availability against the QoS context0, what is going to happen to the traffic from the MN to the new AR (as you already said that the new AR has layer 3 connectivity with MN). Sounds like latency issue here. The MN sends the IP message to the new AR, the new AR goes back to the old AR, and finally the context arrives at the new AR, it gets processed. Now the new Ar is able to determine whether the support for the MN's microflows is available or not. Does it help assuring a "seamlessness" to the MN? -Hamid > -----Original Message----- > From: Rajeev Koodli [SMTP:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 8:34 PM > To: Pat Calhoun > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby' > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > > Hi Pat, > > consider that the MN just shows up at new AR. I mean it looses its current > link, > and gets a new one with new AR. After it establishes the link, the MN > sends an > IP message (just as it would send a Binding Update) to the new AR > providing its > previous IP address and previous AR address. The new AR contacts the old > AR to > fetch contexts. > > How's that ? > > -Rajeev > > > Pat Calhoun wrote: > > > Rajeev, > > > > I believe I've already asked for this, but let me try again. > > > > Could you please provide me with an example of when this would be > > necessary? Some justification would be useful in my mind. > > > > PatC > > On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote: > > > Rajeev: > > > > > > The current requirements in no way prohibit signalling from the MN. > > > Myself and others have re-iterated this many times on the list. > > > > > > o the trigger arrives at an AR at L3; the source is not specified, > > > and considered out of scope for CT. > > > > > > o CT must provide the mechanisms to allow per microflow > enable/disable; > > > the control protocols are not specified and considered out of > scope for > > > CT. > > > > > > Nothing you have said contradicts the above requirements. The only > issue > > > seems to be that you and others want an explicit requirement so that > the > > > design > > > task for these protocols are explicitly part of CT. This would mean > not only > > > that > > > we will have to add MN signalling, but also signalling from other > sources, > > > including > > > L2 (?). Sounds like a lot of effort to me, and the solutions could > > > unnecessarily > > > constrain CT. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Monday, June 18, 2001 2:32 PM > > > > To: James Kempf > > > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > > Authentication & Authorization ... > > > > > > > > > > > > > > > > Hello James, > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > > > do L2 triggering > > > > in all cases as well. > > > > > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > > > as Gary points out, performance will suffer. > > > > > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > > > > > > > If there's an L2 trigger, > > > > > it should be used preferentially. > > > > > > > > Rajeev: certainly. It is one thing to say that if there is a > > > > L2 trigger, it > > > > should be used preferentially, but another thing to say that > > > > we disallow using > > > > L3 messages to trigger CT. We should have the possibility of > > > > MN requesting CT. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > > > Valley Messaging > > > > > Protection > > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > > > >From: Rajeev Koodli > > > > > >To: Singh Ajoy-ASINGH1 > > > > > >CC: "'Kulwinder Atwal'" , Gary > Kenward > > > > > , "'seamoby'" > > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > > Authentication & > > > > > Authorization ... > > > > > > > > > > > > > > > > > >Hello Ajoy, > > > > > > > > > > > >whereas use of link-layer triggers is very useful, it is > > > > not something we > > > > > >can rely upon to be present everywhere (as you correctly > > > > point out for > > > > > >Inter-technology handovers). I don't think we ever said we > > > > disallow link > > > > > >layer triggers. We must not say that that's our solution. > > > > At the IP layer, > > > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > > > > > >Regards, > > > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > > > >> access router which can be used to initiate context transfer. > > > > > >> This will be mostly useful in case of some intra-technology > > > > > >> handovers. In case MN moves across different technologies, yes > > > > > >> some sort of MN trigger is useful. Having said that is it a > > > > > >> good idea to limit the scope of CT protocol? I think we > > > > > >> should allow both the options. > > > > > >> regards, > > > > > >> ajoy > > > > > >> > > > > > > > > [snip, snip] > > > > > > > > > ------_=_NextPart_001_01C0FA53.94F35B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication = & Authorization ...

Rajeev,

By the time the = context arrives at the new AR and processed (e.g. for resource = availability against the QoS context0, what is going to happen to the = traffic from the MN to the new AR (as you already said that the new AR = has layer 3 connectivity with MN). Sounds like latency issue here. The = MN sends the IP message to the new AR, the new AR goes back to the old = AR, and finally the context arrives at the new AR, it gets processed. = Now the new Ar is able to determine whether the support for the MN's = microflows is available or not.

Does it help = assuring a "seamlessness" to the MN?

-Hamid

    -----Original Message-----
    From:   Rajeev Koodli = [SMTP:rajeev@IPRG.nokia.com]
    Sent:   Wednesday, June 20, 2001 8:34 PM
    To:     Pat Calhoun
    Cc:     Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'
    Subject:       = Re: Reactive CT definition: Was Re: = [seamoby] RE: Authentication &  Authorization ...


    Hi Pat,

    consider that the MN just shows up at = new AR. I mean it looses its current link,
    and gets a new one with new AR. After = it establishes the link, the MN sends an
    IP message (just as it would send a = Binding Update) to the new AR providing its
    previous IP address and previous AR = address. The new AR contacts the old AR to
    fetch contexts.

    How's that ?

    -Rajeev


    Pat Calhoun wrote:

    > Rajeev,
    >
    > I believe I've already asked for = this, but let me try again.
    >
    > Could you please provide me with = an example of when this would be
    > necessary? Some justification = would be useful in my mind.
    >
    > PatC
    > On Mon, Jun 18, 2001 at = 04:56:13PM -0400, Gary Kenward wrote:
    > > Rajeev:
    > >
    > >   The current = requirements in no way prohibit signalling from the MN.
    > > Myself and others have = re-iterated this many times on the list.
    > >
    > >   o the trigger = arrives at an AR at L3; the source is not specified,
    > >     and = considered out of scope for CT.
    > >
    > >   o CT must = provide the mechanisms to allow per microflow enable/disable;
    > >     the = control protocols are not specified and considered out of scope = for
    > > CT.
    > >
    > >   Nothing you = have said contradicts the above requirements. The only issue
    > > seems to be that you and = others want an explicit requirement so that the
    > > design
    > > task for these protocols = are explicitly part of CT. This would mean not only
    > > that
    > > we will have to add MN = signalling, but also signalling from other sources,
    > > including
    > > L2 (?). Sounds like a lot = of effort to me, and the solutions could
    > > unnecessarily
    > > constrain CT.
    > >
    > > Gary
    > >
    > > > -----Original = Message-----
    > > > From: Rajeev Koodli = [mailto:rajeev@IPRG.nokia.com]
    > > > Sent: Monday, June 18, = 2001 2:32 PM
    > > > To: James Kempf
    > > > Cc: = ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary
    > > > [WDLN2:AN10:EXCH]; = seamoby@diameter.org
    > > > Subject: Re: Reactive = CT definition: Was Re: [seamoby] RE:
    > > > Authentication & = Authorization ...
    > > >
    > > >
    > > >
    > > > Hello James,
    > > >
    > > > James Kempf = wrote:
    > > >
    > > > > Rajeev,
    > > > >
    > > > > I don't think we = can require L3 triggering in all cases. We need
    > > > >
    > > >
    > > > Rajeev: Unfortunately, = I think we cannot require that the MN
    > > > do L2 = triggering
    > > > in all cases as = well.
    > > >
    > > > > to make sure that = an MN not need to do L3 triggering, otherwise,
    > > > > as Gary points = out, performance will suffer.
    > > >
    > > > Rajeev: yes in some = links, may be (or no impact) in others.
    > > >
    > > >
    > > > > If there's an L2 = trigger,
    > > > > it should be used = preferentially.
    > > >
    > > > Rajeev: certainly. It = is one thing to say that if there is a
    > > > L2 trigger, it
    > > > should be used = preferentially, but another thing to say that
    > > > we disallow = using
    > > > L3 messages to trigger = CT. We should have the possibility of
    > > > MN requesting = CT.
    > > >
    > > > Regards,
    > > >
    > > > -Rajeev
    > > >
    > > >
    > > > >
    > > > >
    > > > = >           &n= bsp;     jak
    > > > >
    > > > > >Delivered-To: = seamoby-list@charizard.diameter.org
    > > > > >X-mProtect: = Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon
    > > > Valley = Messaging
    > > > > Protection
    > > > > >Date: Fri, 15 = Jun 2001 11:59:37 -0700
    > > > > >From: Rajeev = Koodli <rajeev@IPRG.nokia.com>
    > > > > >To: Singh = Ajoy-ASINGH1 <ASINGH1@motorola.com>
    > > > > >CC: = "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>, Gary = Kenward
    > > > > = <gkenward@nortelnetworks.com>, "'seamoby'" = <seamoby@diameter.org>
    > > > > >Subject: Re: = Reactive CT definition: Was Re: [seamoby] RE:
    > > > Authentication = &
    > > > > Authorization = ...
    > > > > >
    > > > > >
    > > > > >Hello = Ajoy,
    > > > > >
    > > > > >whereas use = of link-layer triggers is very useful, it is
    > > > not something = we
    > > > > >can rely upon = to be present everywhere (as you correctly
    > > > point out for
    > > > > = >Inter-technology handovers). I don't think we ever said we
    > > > disallow link
    > > > > >layer = triggers. We must not say that that's our solution.
    > > > At the IP = layer,
    > > > > >we need to = define IP messages. I think we pretty much agree.
    > > > > >
    > > > > = >Regards,
    > > > > >
    > > > > = >-Rajeev
    > > > > >
    > > > > >
    > > > > >Singh = Ajoy-ASINGH1 wrote:
    > > > > >
    > > > > >> I think = it is possible to receive link layer trigger at the new
    > > > > >> access = router which can be used to initiate context transfer.
    > > > > >> This = will be mostly useful in case of some intra-technology
    > > > > >> = handovers. In case MN moves across different technologies, yes
    > > > > >> some = sort of MN trigger is useful. Having said that is it a
    > > > > >> good = idea to limit the scope of CT protocol? I think we
    > > > > >> should = allow both the options.
    > > > > >> = regards,
    > > > > >> = ajoy
    > > > > >>
    > > >
    > > > [snip, snip]
    > > >
    > > >

------_=_NextPart_001_01C0FA53.94F35B20-- From owner-seamoby@diameter.org Thu Jun 21 09:34: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 JAA28150 for ; Thu, 21 Jun 2001 09:34:12 -0400 (EDT) Received: (qmail 2406 invoked by alias); 21 Jun 2001 13:21:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2400 invoked by uid 200); 21 Jun 2001 13:21:51 -0000 Received: (qmail 2392 invoked by uid 500); 21 Jun 2001 13:21:48 -0000 Date: Thu, 21 Jun 2001 06:21:48 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Phillip Neumiller'" , "'Mark Smith'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology Message-ID: <20010621062148.E1322@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Phillip Neumiller' , 'Mark Smith' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D66@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: <9FBD322B7824D511B36900508BF93C9C9F5D66@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jun 20, 2001 at 02:18:34PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk ok, seeing how this discussion is currently going, I would favor using ARs in the spec. If someone wants to re-use CT for other uses (e.g. transfer context between mobile nodes and foobars), then they are free to use the protocol. I really don't see why the possibility that a protocol could be used for one thing or another should affect terminology used in the requirements spec. (btw, if an AR is mobile, it's still in AR in my mind, but witha special mobile feature). PatC On Wed, Jun 20, 2001 at 02:18:34PM -0400, Gary Kenward wrote: > Phil: > > Interesting thoughts. I just one to be clear that the model you > have described was never the model I was thinking of. For me, > CT happens between "like" nodes. FN was simply a generic term > to described two arbitrary nodes in a network that need to exchange > context. This approach works (I believe) for the problem statement, > it *may* work for the requirements, but something different will > likely be required when we look at the design. > > Consider that one of the goals (I think), was to develop a CT > solution that works in general, and is not specific to a particular > network solution, topology or wireless technology. As much as this > goal was discussed and agreed upon (at least, in my recollection), > everyone still has an image in their mind as to what the network > really looks like. So, for some, CT is happening between > GGSNs/SGSNs/PDSNs/RNCs, > for others it is happening between 802.11 access points (although these > are L2), for others between hosts/subscriber devices, for others, between > MRs. > > In the general situation, a CT between two "like" nodes is a nice > abstract concept. Where we seem to get into trouble is when we try > to bound the problem space - different networks have different requirements. > > I don't believe it does anyone any good to force the restrictions of > one network solution on another network solution through the bias of > an L3 protocol. It is also risky to develop "swiss army knife" protocols > to meet all needs. On the other hand, I hope that we can avoid different > ct solutions for different networks. > > So how do we move forward? If we really knew the differences between the > requirements for different networks, we might be better positioned to > identify > which differences really mattered and which ones could be generalized. > However, > this implies a need to develop (at least) two subsets of requirements - > wireless > access versus all-wireless. As an example, I can imagine a scenario where > two > MRs need to exchange context because one or both of the MRs have move, even > though the subscriber device hasn't; what does this imply about triggers, > AA, > etc.? Certainly many of the assumptions that one could make about an access > network would seem to be suspect in this case. > > Cheers, > Gary > > > -----Original Message----- > > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > > Sent: Wednesday, June 20, 2001 1:35 PM > > To: 'Mark Smith'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > > > > > > > -----Original Message----- > > > From: Mark Smith [mailto:mark.smith@comdev.cc] > > > Sent: Wednesday, June 20, 2001 12:20 PM > > > To: seamoby@cdma-2000.org > > > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > > > > > > > I guess my question is, does it matter if a Forwarding Node > > > (as Gary has > > > defined them) is also a Mobile Node? What effect does it > > have on our > > > design/requirement/problem statement? > > > > > > I think the idea is that, for the sake of a particular CTP > > session, a > > > node is either an MN or an FN. If it's an FN for this CTP > > > session, it > > > may be an MN for another session, but those two sessions are > > > independant > > > of each other and should be viewed as such. > > > > > > -Mark > > > > Hi Mark, > > > > Well, not exactly. It could really be both at once, in that the > > choice in which it makes to route its own MN-like traffic is the > > same choice made for its routed traffic. Forwarding is not a > > strong enough term for me since almost any edge device, even those > > running Windoze 2000, can be forwarding nodes. Its quite different > > if you are actually a full blown mobile router. Then again, the > > choice for its own traffic could be completely different from the > > choices made for its routed traffic. The MR is keeping up multiple > > simultaneous link layers that it routes over. It adds and drops > > these link layers frequently. For this reason, CTP must be sent > > the MINIMUM number of times necessary, and splitting them into > > orthogonal causes like you suggest would probably be a bad idea. > > > > One thing I am worrying about right now is path context transitivity. > > I am not completely sure I understand the implications for it yet > > myself, but allow me to try to explain it. Since we have mobile nodes > > that are full blow SeaMoby ARs in many respects, CT may need to be > > daisy chained along the route until a fixed AR is hit. At this > > point fixed network QoS and aggragation take over. Its like the > > MANET has to compensate QoS and CT-wise, until the traffic hits a > > "real" AR. So what I am worrying about a lot is if CT has to be > > passed down the whole router chain end-to-end to work properly in > > mobile ad hoc networks. I don't have the answer yet. > > > > Thanks, > > > > Phil > > From owner-seamoby@diameter.org Thu Jun 21 09:44: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 JAA28628 for ; Thu, 21 Jun 2001 09:44:49 -0400 (EDT) Received: (qmail 2920 invoked by alias); 21 Jun 2001 13:32:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2913 invoked by uid 200); 21 Jun 2001 13:32:20 -0000 Received: (qmail 2903 invoked by uid 500); 21 Jun 2001 13:32:17 -0000 Date: Thu, 21 Jun 2001 06:32:17 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Pat Calhoun , Gary Kenward , "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Message-ID: <20010621063217.G1322@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Pat Calhoun , Gary Kenward , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> <20010618135157.Z17928@charizard.diameter.org> <3B3140EC.9EB61F89@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3140EC.9EB61F89@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Wed, Jun 20, 2001 at 05:33:48PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 20, 2001 at 05:33:48PM -0700, Rajeev Koodli wrote: > > Hi Pat, > > consider that the MN just shows up at new AR. I mean it looses its current link, > and gets a new one with new AR. After it establishes the link, the MN sends an > IP message (just as it would send a Binding Update) to the new AR providing its > previous IP address and previous AR address. The new AR contacts the old AR to > fetch contexts. > > How's that ? then why wouldn't the authenticated binding update simply cause CT to occur? Patc > > -Rajeev > > > Pat Calhoun wrote: > > > Rajeev, > > > > I believe I've already asked for this, but let me try again. > > > > Could you please provide me with an example of when this would be > > necessary? Some justification would be useful in my mind. > > > > PatC > > On Mon, Jun 18, 2001 at 04:56:13PM -0400, Gary Kenward wrote: > > > Rajeev: > > > > > > The current requirements in no way prohibit signalling from the MN. > > > Myself and others have re-iterated this many times on the list. > > > > > > o the trigger arrives at an AR at L3; the source is not specified, > > > and considered out of scope for CT. > > > > > > o CT must provide the mechanisms to allow per microflow enable/disable; > > > the control protocols are not specified and considered out of scope for > > > CT. > > > > > > Nothing you have said contradicts the above requirements. The only issue > > > seems to be that you and others want an explicit requirement so that the > > > design > > > task for these protocols are explicitly part of CT. This would mean not only > > > that > > > we will have to add MN signalling, but also signalling from other sources, > > > including > > > L2 (?). Sounds like a lot of effort to me, and the solutions could > > > unnecessarily > > > constrain CT. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Monday, June 18, 2001 2:32 PM > > > > To: James Kempf > > > > Cc: ASINGH1@motorola.com; kulwinder.atwal@zucotto.com; Kenward, Gary > > > > [WDLN2:AN10:EXCH]; seamoby@diameter.org > > > > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > > Authentication & Authorization ... > > > > > > > > > > > > > > > > Hello James, > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I don't think we can require L3 triggering in all cases. We need > > > > > > > > > > > > > Rajeev: Unfortunately, I think we cannot require that the MN > > > > do L2 triggering > > > > in all cases as well. > > > > > > > > > to make sure that an MN not need to do L3 triggering, otherwise, > > > > > as Gary points out, performance will suffer. > > > > > > > > Rajeev: yes in some links, may be (or no impact) in others. > > > > > > > > > > > > > If there's an L2 trigger, > > > > > it should be used preferentially. > > > > > > > > Rajeev: certainly. It is one thing to say that if there is a > > > > L2 trigger, it > > > > should be used preferentially, but another thing to say that > > > > we disallow using > > > > L3 messages to trigger CT. We should have the possibility of > > > > MN requesting CT. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > >Delivered-To: seamoby-list@charizard.diameter.org > > > > > >X-mProtect: Fri, 15 Jun 2001 11:59:37 -0700 Nokia Silicon > > > > Valley Messaging > > > > > Protection > > > > > >Date: Fri, 15 Jun 2001 11:59:37 -0700 > > > > > >From: Rajeev Koodli > > > > > >To: Singh Ajoy-ASINGH1 > > > > > >CC: "'Kulwinder Atwal'" , Gary Kenward > > > > > , "'seamoby'" > > > > > >Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > > > > Authentication & > > > > > Authorization ... > > > > > > > > > > > > > > > > > >Hello Ajoy, > > > > > > > > > > > >whereas use of link-layer triggers is very useful, it is > > > > not something we > > > > > >can rely upon to be present everywhere (as you correctly > > > > point out for > > > > > >Inter-technology handovers). I don't think we ever said we > > > > disallow link > > > > > >layer triggers. We must not say that that's our solution. > > > > At the IP layer, > > > > > >we need to define IP messages. I think we pretty much agree. > > > > > > > > > > > >Regards, > > > > > > > > > > > >-Rajeev > > > > > > > > > > > > > > > > > >Singh Ajoy-ASINGH1 wrote: > > > > > > > > > > > >> I think it is possible to receive link layer trigger at the new > > > > > >> access router which can be used to initiate context transfer. > > > > > >> This will be mostly useful in case of some intra-technology > > > > > >> handovers. In case MN moves across different technologies, yes > > > > > >> some sort of MN trigger is useful. Having said that is it a > > > > > >> good idea to limit the scope of CT protocol? I think we > > > > > >> should allow both the options. > > > > > >> regards, > > > > > >> ajoy > > > > > >> > > > > > > > > [snip, snip] > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 09:47: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 JAA28735 for ; Thu, 21 Jun 2001 09:47:48 -0400 (EDT) Received: (qmail 3389 invoked by alias); 21 Jun 2001 13:36:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3383 invoked by uid 200); 21 Jun 2001 13:36:33 -0000 Received: (qmail 3378 invoked by uid 500); 21 Jun 2001 13:36:31 -0000 Date: Thu, 21 Jun 2001 06:36:31 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] How to address issues Message-ID: <20010621063631.H1322@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, There appears to be some confusion on how issues are addressed. The issues list is for the WG only, and will help us in tracking changes in the next revision. Given the contention of certain change requests, this will also help me gauge consensus. So, once an issue is opened, you may discuss it. It would be REALLY useful if you also include Issue nn in the subject of the e-mail (replace nn with issue number please). This isn't intended to be complicated, so let's make sure it isn't. If folks have suggestions on how to improve this short-term solution, please let me know. Thanks, Patc From owner-seamoby@diameter.org Thu Jun 21 11:14: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 LAA01964 for ; Thu, 21 Jun 2001 11:14:37 -0400 (EDT) Received: (qmail 4035 invoked by alias); 21 Jun 2001 14:58:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4030 invoked by uid 200); 21 Jun 2001 14:58:36 -0000 Received: (qmail 4025 invoked from network); 21 Jun 2001 14:58:34 -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; 21 Jun 2001 14:58:34 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5LF8o002268 for ; Thu, 21 Jun 2001 11:08:51 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 21 Jun 2001 11:08:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:08:35 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD102@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Pat Calhoun'" , "Gary Kenward" Cc: "'Phillip Neumiller'" , "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Thu, 21 Jun 2001 11:08:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA64.0828A950" 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_01C0FA64.0828A950 Content-Type: text/plain; charset="iso-8859-1" I agree. Lets keep the definition of AR as it is. -Hamid > -----Original Message----- > From: Pat Calhoun [SMTP:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 9:22 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Phillip Neumiller'; 'Mark Smith'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > ok, seeing how this discussion is currently going, I would favor using > ARs in the spec. If someone wants to re-use CT for other uses (e.g. > transfer context between mobile nodes and foobars), then they are free > to use the protocol. I really don't see why the possibility that a > protocol could be used for one thing or another should affect terminology > used in the requirements spec. > > (btw, if an AR is mobile, it's still in AR in my mind, but witha special > mobile feature). > > PatC > > On Wed, Jun 20, 2001 at 02:18:34PM -0400, Gary Kenward wrote: > > Phil: > > > > Interesting thoughts. I just one to be clear that the model you > > have described was never the model I was thinking of. For me, > > CT happens between "like" nodes. FN was simply a generic term > > to described two arbitrary nodes in a network that need to exchange > > context. This approach works (I believe) for the problem statement, > > it *may* work for the requirements, but something different will > > likely be required when we look at the design. > > > > Consider that one of the goals (I think), was to develop a CT > > solution that works in general, and is not specific to a particular > > network solution, topology or wireless technology. As much as this > > goal was discussed and agreed upon (at least, in my recollection), > > everyone still has an image in their mind as to what the network > > really looks like. So, for some, CT is happening between > > GGSNs/SGSNs/PDSNs/RNCs, > > for others it is happening between 802.11 access points (although these > > are L2), for others between hosts/subscriber devices, for others, > between > > MRs. > > > > In the general situation, a CT between two "like" nodes is a nice > > abstract concept. Where we seem to get into trouble is when we try > > to bound the problem space - different networks have different > requirements. > > > > I don't believe it does anyone any good to force the restrictions of > > one network solution on another network solution through the bias of > > an L3 protocol. It is also risky to develop "swiss army knife" protocols > > to meet all needs. On the other hand, I hope that we can avoid different > > ct solutions for different networks. > > > > So how do we move forward? If we really knew the differences between > the > > requirements for different networks, we might be better positioned to > > identify > > which differences really mattered and which ones could be generalized. > > However, > > this implies a need to develop (at least) two subsets of requirements - > > wireless > > access versus all-wireless. As an example, I can imagine a scenario > where > > two > > MRs need to exchange context because one or both of the MRs have move, > even > > though the subscriber device hasn't; what does this imply about > triggers, > > AA, > > etc.? Certainly many of the assumptions that one could make about an > access > > network would seem to be suspect in this case. > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > > > Sent: Wednesday, June 20, 2001 1:35 PM > > > To: 'Mark Smith'; seamoby@cdma-2000.org > > > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mark Smith [mailto:mark.smith@comdev.cc] > > > > Sent: Wednesday, June 20, 2001 12:20 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > > > > > > > > > > I guess my question is, does it matter if a Forwarding Node > > > > (as Gary has > > > > defined them) is also a Mobile Node? What effect does it > > > have on our > > > > design/requirement/problem statement? > > > > > > > > I think the idea is that, for the sake of a particular CTP > > > session, a > > > > node is either an MN or an FN. If it's an FN for this CTP > > > > session, it > > > > may be an MN for another session, but those two sessions are > > > > independant > > > > of each other and should be viewed as such. > > > > > > > > -Mark > > > > > > Hi Mark, > > > > > > Well, not exactly. It could really be both at once, in that the > > > choice in which it makes to route its own MN-like traffic is the > > > same choice made for its routed traffic. Forwarding is not a > > > strong enough term for me since almost any edge device, even those > > > running Windoze 2000, can be forwarding nodes. Its quite different > > > if you are actually a full blown mobile router. Then again, the > > > choice for its own traffic could be completely different from the > > > choices made for its routed traffic. The MR is keeping up multiple > > > simultaneous link layers that it routes over. It adds and drops > > > these link layers frequently. For this reason, CTP must be sent > > > the MINIMUM number of times necessary, and splitting them into > > > orthogonal causes like you suggest would probably be a bad idea. > > > > > > One thing I am worrying about right now is path context transitivity. > > > I am not completely sure I understand the implications for it yet > > > myself, but allow me to try to explain it. Since we have mobile nodes > > > that are full blow SeaMoby ARs in many respects, CT may need to be > > > daisy chained along the route until a fixed AR is hit. At this > > > point fixed network QoS and aggragation take over. Its like the > > > MANET has to compensate QoS and CT-wise, until the traffic hits a > > > "real" AR. So what I am worrying about a lot is if CT has to be > > > passed down the whole router chain end-to-end to work properly in > > > mobile ad hoc networks. I don't have the answer yet. > > > > > > Thanks, > > > > > > Phil > > > ------_=_NextPart_001_01C0FA64.0828A950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] Issue 1: Change access network terminology

I agree. Lets keep = the definition of AR as it is.

-Hamid

    -----Original Message-----
    From:   Pat Calhoun [SMTP:pcalhoun@diameter.org]
    Sent:   Thursday, June 21, 2001 9:22 AM
    To:     Kenward, Gary [WDLN2:AN10:EXCH]
    Cc:     'Phillip Neumiller'; 'Mark Smith'; = seamoby@cdma-2000.org
    Subject:       = Re: [seamoby] Issue 1: Change access = network terminology

    ok, seeing how this discussion is = currently going, I would favor using
    ARs in the spec. If someone wants to = re-use CT for other uses (e.g.
    transfer context between mobile nodes = and foobars), then they are free
    to use the protocol. I really don't = see why the possibility that a
    protocol could be used for one thing = or another should affect terminology
    used in the requirements spec.

    (btw, if an AR is mobile, it's still = in AR in my mind, but witha special
    mobile feature).

    PatC

    On Wed, Jun 20, 2001 at 02:18:34PM = -0400, Gary Kenward wrote:
    > Phil:
    >
    >   Interesting = thoughts. I just one to be clear that the model you
    > have described was never the = model I was thinking of. For me,
    > CT happens between = "like" nodes. FN was simply a generic term
    > to described two arbitrary nodes = in a network that need to exchange
    > context. This approach works (I = believe) for the problem statement,
    > it *may* work for the = requirements, but something different will
    > likely be required when we look = at the design.
    >
    >   Consider that one of = the goals (I think), was to develop a CT
    > solution that works in general, = and is not specific to a particular
    > network solution, topology or = wireless technology. As much as this
    > goal was discussed and agreed = upon (at least, in my recollection),
    > everyone still has an image in = their mind as to what the network
    > really looks like. So, for some, = CT is happening between
    > GGSNs/SGSNs/PDSNs/RNCs,
    > for others it is happening = between 802.11 access points (although these
    > are L2), for others between = hosts/subscriber devices, for others, between
    > MRs.
    >
    >   In the general = situation, a CT between two "like" nodes is a nice
    > abstract concept. Where we seem = to get into trouble is when we try
    > to bound the problem space - = different networks have different requirements.
    >
    >   I don't believe it = does anyone any good to force the restrictions of
    > one network solution on another = network solution through the bias of
    > an L3 protocol. It is also risky = to develop "swiss army knife" protocols
    > to meet all needs. On the other = hand, I hope that we can avoid different
    > ct solutions for different = networks.
    >
    >   So how do we move = forward? If we really knew the differences between the
    > requirements for different = networks, we might be better positioned to
    > identify
    > which differences really = mattered and which ones could be generalized.
    > However,
    > this implies a need to develop = (at least) two subsets of requirements -
    > wireless
    > access versus all-wireless. As = an example, I can imagine a scenario where
    > two
    > MRs need to exchange context = because one or both of the MRs have move, even
    > though the subscriber device = hasn't; what does this imply about triggers,
    > AA,
    > etc.? Certainly many of the = assumptions that one could make about an access
    > network would seem to be suspect = in this case.
    >
    > Cheers,
    > Gary
    >
    > > -----Original = Message-----
    > > From: Phillip Neumiller = [mailto:PNeumiller@MeshNetwor= ks.com]
    > > Sent: Wednesday, June 20, = 2001 1:35 PM
    > > To: 'Mark Smith'; = seamoby@cdma-2000.org
    > > Subject: RE: [seamoby] = Issue 1: Change access network terminology
    > >
    > >
    > >
    > >
    > > > -----Original = Message-----
    > > > From: Mark Smith = [mailto:mark.smith@comdev.cc]
    > > > Sent: Wednesday, June = 20, 2001 12:20 PM
    > > > To: = seamoby@cdma-2000.org
    > > > Subject: Re: [seamoby] = Issue 1: Change access network terminology
    > > >
    > > >
    > > > I guess my question = is, does it matter if a Forwarding Node
    > > > (as Gary has
    > > > defined them) is also = a Mobile Node?  What effect does it
    > > have on our
    > > > = design/requirement/problem statement?
    > > >
    > > > I think the idea is = that, for the sake of a particular CTP
    > > session, a
    > > > node is either an MN = or an FN.  If it's an FN for this CTP
    > > > session, it
    > > > may be an MN for = another session, but those two sessions are
    > > > independant
    > > > of each other and = should be viewed as such.
    > > >
    > > > -Mark
    > >
    > > Hi Mark,
    > >
    > > Well, not exactly.  It = could really be both at once, in that the
    > > choice in which it makes to = route its own MN-like traffic is the
    > > same choice made for its = routed traffic.  Forwarding is not a
    > > strong enough term for me = since almost any edge device, even those
    > > running Windoze 2000, can = be forwarding nodes.  Its quite different
    > > if you are actually a full = blown mobile router.  Then again, the
    > > choice for its own traffic = could be completely different from the
    > > choices made for its routed = traffic.  The MR is keeping up multiple
    > > simultaneous link layers = that it routes over.  It adds and drops
    > > these link layers = frequently.  For this reason, CTP must be sent
    > > the MINIMUM number of times = necessary, and splitting them into
    > > orthogonal causes like you = suggest would probably be a bad idea.
    > >
    > > One thing I am worrying = about right now is path context transitivity.
    > > I am not completely sure I = understand the implications for it yet
    > > myself, but allow me to try = to explain it.  Since we have mobile nodes
    > > that are full blow SeaMoby = ARs in many respects, CT may need to be
    > > daisy chained along the = route until a fixed AR is hit.  At this
    > > point fixed network QoS and = aggragation take over.  Its like the
    > > MANET has to compensate QoS = and CT-wise, until the traffic hits a
    > > "real" AR.  = So what I am worrying about a lot is if CT has to be
    > > passed down the whole = router chain end-to-end to work properly in
    > > mobile ad hoc = networks.  I don't have the answer yet.
    > >
    > > Thanks,
    > >
    > > Phil
    > >

------_=_NextPart_001_01C0FA64.0828A950-- From owner-seamoby@diameter.org Thu Jun 21 11:24: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 LAA02355 for ; Thu, 21 Jun 2001 11:24:10 -0400 (EDT) Received: (qmail 4342 invoked by alias); 21 Jun 2001 15:05:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4336 invoked by uid 200); 21 Jun 2001 15:05:18 -0000 Received: (qmail 4331 invoked from network); 21 Jun 2001 15:05:14 -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; 21 Jun 2001 15:05:14 -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 f5LFFR003483 for ; Thu, 21 Jun 2001 11:15:27 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 21 Jun 2001 11:15:19 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:15:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D71@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 11:15:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA64.F82B8850" 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_01C0FA64.F82B8850 Content-Type: text/plain; charset="iso-8859-1" Rajeev: > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, June 20, 2001 5:40 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > Gary Kenward wrote: > > > > > > > This is essentially the same definitions I proposed during > > the discussion over proactive and reactive a few months back. > > And, as someone pointed out, it was mistaken. > > > > The first question that was asked then, and is still apropos: > > what benefit is derived from focussing on the specific arrival > > event as the delineator? > > > > Rajeev: The benefit is a clear starting point for the CT > process. (i.e., > when to initiate CT) True enough, but the problem is that it is an event that happens too late. Certainly, for some networks, this may be the only handover event that is visible at L3. But, for many networks, there are L2 triggers, and mobility events that can be forwarded to CT. In this sense, the definition you have provided is too limited. Perhaps the answer is to define another phase. I have no real ideas on this at the moment: how about proactive, reactive and panic ;^} > > > > > To explain further, let me illustrate with a scenario: suppose that > > it takes 10ms to complete a context transfer; now suppose > > that the ct trigger event happens in less then 10ms from the > > actual first packet arrival, say 9 ms - is this a proactive or > > reactive ct? The ct that occurs fulfills neither of the offered > > definitions. > > Rajeev: The offered definition does not say anything about how long > context transfer takes place. The _start_ of CT request is > the issue. A > packet arrives at the new AR (e.g., a MN request for CT), there is no > context there, then you fetch it. Ok. How CT starts is important. But as important is when it finishes. Indeed, it is more important to me, as I see too little value in ct that finishes after 3 or 4 packets have been forwarded. I want ct to make real-time handovers opaque to the end-user. > > > > > > > > If the context is not in place for the first packet forwarding, then > > the transfer is reactive; meaning that at this point, the goal is to > > complete the transfer as fast as possible to minimize the delay in > > forwarding that first packet. > > > > Rajeev: Exactly. This is what I am proposing to be added. But this is in the current requirements. It just doesn't say that reactive starts with the first packet forwarding, accounting for the fact that in some networks, reactive mode can occur before that event. > > > > > Reactive CT is when I either choose not to perform proactive CT, or > > I fail to meet the goal of being proactive. > > Rajeev: Agreed. Can we add the text then ? What do others think ? It seems to me that the only part that we disagree on is what indicates that "reactive mode" is occurring. > > Regards, Onwards and upwards, Gary > > -Rajeev > > > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > Submitter name: Rajeev Koodli > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > Date first submitted: June 20, 2001 > > > > > > Comment type: 'T'echnical > > > > > > Priority: ''S'/MUST fix > > > > > > Section: 4.5 > > > > > > Rationale/Explanation of issue: > > > > > > The section provides the description of proactive and reactive > > > CT without properly defining what they are. We need the > definitions. > > > > > > > > Requested Change: > > > > > > Reactive CT: The context transfer process which takes place > > subsequent > > > to arrival of a MN's packet at the target AR > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > context transfer > > > process in which the required contexts are in place at > the target AR > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > ------_=_NextPart_001_01C0FA64.F82B8850 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] proactive and reactive CT definitions

Rajeev:

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Wednesday, June 20, 2001 5:40 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] proactive and reactive CT definitions
>
>
> Gary Kenward wrote:
>
> >
> >
> > This is essentially the same definitions I proposed during
> > the discussion over proactive and reactive a few months back.
> > And, as someone pointed out, it was mistaken.
> >
> > The first question that was asked then, and is still apropos:
> > what benefit is derived from focussing on the specific arrival
> > event as the delineator?
> >
>
> Rajeev: The benefit is a clear starting point for the CT
> process. (i.e.,
> when to initiate CT)

True enough, but the problem is that it is an event that happens too late.
Certainly, for some networks, this may be the only handover event that
is visible at L3. But, for many networks, there are L2 triggers, and mobility
events that can be forwarded to CT.

In this sense, the definition you have provided is too limited. Perhaps
the answer is to define another phase. I have no real ideas on this at the
moment: how about proactive, reactive and panic ;^}

>
> >
> > To explain further, let me illustrate with a scenario: suppose that
> > it takes 10ms to complete a context transfer; now suppose
> > that the ct trigger event happens  in less then 10ms from the
> > actual first packet arrival, say 9 ms - is this a proactive or
> > reactive ct? The ct that occurs fulfills neither of the offered
> > definitions.
>
> Rajeev: The offered definition does not say anything about how long
> context transfer takes place. The _start_ of CT request is
> the issue. A
> packet arrives at the new AR (e.g., a MN request for CT), there is no
> context there, then you fetch it.

Ok. How CT starts is important. But as important is when it finishes.
Indeed, it is more important to me, as I see too little value in ct that
finishes after 3 or 4 packets have been forwarded. I want ct to make real-time
handovers opaque to the end-user.

>
>
> >
> >
> > If the context is not in place for the first packet forwarding, then
> > the transfer is reactive; meaning that at this point, the goal is to
> > complete the transfer as fast as possible to minimize the delay in
> > forwarding that first packet.
> >
>
> Rajeev: Exactly. This is what I am proposing to be added.

But this is in the current requirements. It just doesn't say that reactive
starts with the first packet forwarding, accounting for the fact that in some
networks, reactive mode can occur before that event.

>
> >
> > Reactive CT is when I either choose not to perform proactive CT, or
> > I fail to meet the goal of being proactive.
>
> Rajeev: Agreed.  Can we add the text then ? What do others think ?

It seems to me that the only part that we disagree on is what indicates that "reactive mode" is occurring.

>
> Regards,

Onwards and upwards,
Gary

>
> -Rajeev
>
>
>
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> > > Sent: Wednesday, June 20, 2001 2:49 PM
> > > To: seamoby@cdma-2000.org
> > > Subject: [seamoby] proactive and reactive CT definitions
> > >
> > >
> > >
> > > Description of issue :Clear, unambiguous definitions are missing.
> > >
> > > Submitter name: Rajeev Koodli
> > >
> > > Submitter email address: rajeev@iprg.nokia.com
> > >
> > > Date first submitted: June 20, 2001
> > >
> > > Comment type: 'T'echnical
> > >
> > > Priority:  ''S'/MUST fix
> > >
> > > Section:  4.5
> > >
> > > Rationale/Explanation of issue:
> > >
> > > The section provides the description of proactive and reactive
> > > CT without properly defining what they are. We need the
> definitions.
> >
> > >
> > > Requested Change:
> > >
> > > Reactive CT: The context transfer process which takes place
> > subsequent
> > > to arrival of a MN's packet at the target AR
> > >
> > > Proactive (I prfer Charlie's Predictive better) CT: The
> > > context transfer
> > > process in which the required contexts are in place at
> the target AR
> >
> > > prior to the arrival of MN's packet at target AR.
> > >
> > >
> > >
> > >
>
>

------_=_NextPart_001_01C0FA64.F82B8850-- From owner-seamoby@diameter.org Thu Jun 21 11:59:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03887 for ; Thu, 21 Jun 2001 11:59:51 -0400 (EDT) Received: (qmail 5162 invoked by alias); 21 Jun 2001 15:47:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5156 invoked by uid 200); 21 Jun 2001 15:47:27 -0000 Received: (qmail 5150 invoked from network); 21 Jun 2001 15:47:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 15:47:25 -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 IAA15214; Thu, 21 Jun 2001 08:57:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LFvsp28535; Thu, 21 Jun 2001 08:57:54 -0700 X-mProtect: Thu, 21 Jun 2001 08:57:54 -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 smtpdxVLLCH; Thu, 21 Jun 2001 08:57:53 PDT Message-ID: <3B321981.636DBA6E@iprg.nokia.com> Date: Thu, 21 Jun 2001 08:57:53 -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: Gary Kenward CC: Seamless Mobility Working Group Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D71@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, I think that, even if context transfer begins AFTER a node finds a new point attachement, it is by no means necessarily too late. This can be made obvious by a simple example: - What if a node does context transfer after a link establishment which finalizes .0001 second after the previous link is dropped? If you agree with this, but have concerns about the .1ms latency, then we are just haggling over numbers. It shouldn't be the place of the context framework document (for arbitrary media!) to arbitrate this, as long as there are media for which the context transfer can occur within meaningful time constraints. I think it's clear that such media will exist. So, I claim that the proposed definition for reactive is very beneficial. A reactive transfer is initiated after the new link is established. A predictive transfer is initiated before the new link is established. These definitions are easy, clear, and useful. Since even the definition of handover seems to be too muddy, perhaps the definition for reactive/predictive (or, if we must use it, the non-English word "proactive") should depend only on link establishment. Regards, Charlie P. > Gary Kenward wrote: > > Rajeev: > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, June 20, 2001 5:40 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > Gary Kenward wrote: > > > > > > > > > > > This is essentially the same definitions I proposed during > > > the discussion over proactive and reactive a few months back. > > > And, as someone pointed out, it was mistaken. > > > > > > The first question that was asked then, and is still apropos: > > > what benefit is derived from focussing on the specific arrival > > > event as the delineator? > > > > > > > Rajeev: The benefit is a clear starting point for the CT > > process. (i.e., > > when to initiate CT) > > True enough, but the problem is that it is an event that happens too late. > Certainly, for some networks, this may be the only handover event that > is visible at L3. But, for many networks, there are L2 triggers, and mobility > events that can be forwarded to CT. > > In this sense, the definition you have provided is too limited. Perhaps > the answer is to define another phase. I have no real ideas on this at the > moment: how about proactive, reactive and panic ;^} > > > > > > > > > To explain further, let me illustrate with a scenario: suppose that > > > it takes 10ms to complete a context transfer; now suppose > > > that the ct trigger event happens in less then 10ms from the > > > actual first packet arrival, say 9 ms - is this a proactive or > > > reactive ct? The ct that occurs fulfills neither of the offered > > > definitions. > > > > Rajeev: The offered definition does not say anything about how long > > context transfer takes place. The _start_ of CT request is > > the issue. A > > packet arrives at the new AR (e.g., a MN request for CT), there is no > > context there, then you fetch it. > > Ok. How CT starts is important. But as important is when it finishes. > Indeed, it is more important to me, as I see too little value in ct that > finishes after 3 or 4 packets have been forwarded. I want ct to make real-time > > handovers opaque to the end-user. > > > > > > > > > > > > > > If the context is not in place for the first packet forwarding, then > > > the transfer is reactive; meaning that at this point, the goal is to > > > complete the transfer as fast as possible to minimize the delay in > > > forwarding that first packet. > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > But this is in the current requirements. It just doesn't say that reactive > starts with the first packet forwarding, accounting for the fact that in some > networks, reactive mode can occur before that event. > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, or > > > I fail to meet the goal of being proactive. > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > It seems to me that the only part that we disagree on is what indicates that > "reactive mode" is occurring. > > > > > Regards, > > Onwards and upwards, > Gary > > > > > -Rajeev > > > > > > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > Comment type: 'T'echnical > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > Section: 4.5 > > > > > > > > Rationale/Explanation of issue: > > > > > > > > The section provides the description of proactive and reactive > > > > CT without properly defining what they are. We need the > > definitions. > > > > > > > > > > > Requested Change: > > > > > > > > Reactive CT: The context transfer process which takes place > > > subsequent > > > > to arrival of a MN's packet at the target AR > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > context transfer > > > > process in which the required contexts are in place at > > the target AR > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 12:31: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 MAA05338 for ; Thu, 21 Jun 2001 12:30:24 -0400 (EDT) Received: (qmail 5704 invoked by alias); 21 Jun 2001 16:13:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5698 invoked by uid 200); 21 Jun 2001 16:13:44 -0000 Received: (qmail 5693 invoked from network); 21 Jun 2001 16:13:42 -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; 21 Jun 2001 16:13:42 -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 f5LGNt013680 for ; Thu, 21 Jun 2001 12:23:55 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 21 Jun 2001 12:23:53 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:23:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D75@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: Seamless Mobility Working Group Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 12:23:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA6E.8FEFD520" 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_01C0FA6E.8FEFD520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Charlie: The issue isn't whether such a ct is useful or not, the issue is whether the use of the even of the first packet "arrival"=20 should be embedded in the requirements. As I tried to explain in my response to Ranjeev, the fpa is useful in some situations, but it's not exclusive - some networks will want to use different triggers.=20 And so, perhaps we are back to the debate over what constitutes a trigger for a ct - in this case a reactive ct. The definition must be open to accommodate different networking technologies, different=20 topologies and different operational styles. BTW, from Merriam-Webster: Main Entry: pro=B7ac=B7tive=20 Pronunciation: (")prO-'ak-tiv Function: adjective Date: 1933 1 [1pro-] : relating to, caused by, or being interference between = previous learning and the recall or performance of later learning 2 [2pro- + reactive] : acting in anticipation of future problems, = needs, or changes=20 (I would quote OED, if I had access). Cheers, Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Thursday, June 21, 2001 11:58 AM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Seamless Mobility Working Group > Subject: Re: [seamoby] proactive and reactive CT definitions >=20 >=20 >=20 > Hello Gary, >=20 > I think that, even if context transfer begins AFTER a node > finds a new point attachement, it is by no means necessarily > too late. This can be made obvious by a simple example: > - What if a node does context transfer after a link establishment > which finalizes .0001 second after the previous link is dropped? > If you agree with this, but have concerns about the .1ms latency, > then we are just haggling over numbers. It shouldn't be the > place of the context framework document (for arbitrary media!) > to arbitrate this, as long as there are media for which the > context transfer can occur within meaningful time constraints. > I think it's clear that such media will exist. >=20 > So, I claim that the proposed definition for reactive is very > beneficial. A reactive transfer is initiated after the new > link is established. A predictive transfer is initiated > before the new link is established. These definitions are > easy, clear, and useful. >=20 > Since even the definition of handover seems to be too muddy, > perhaps the definition for reactive/predictive (or, if we must > use it, the non-English word "proactive") should depend only > on link establishment. >=20 > Regards, > Charlie P. >=20 >=20 >=20 >=20 >=20 > > Gary Kenward wrote: > >=20 > > Rajeev: > >=20 > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Wednesday, June 20, 2001 5:40 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: seamoby@cdma-2000.org > > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > This is essentially the same definitions I proposed during > > > > the discussion over proactive and reactive a few months back. > > > > And, as someone pointed out, it was mistaken. > > > > > > > > The first question that was asked then, and is still apropos: > > > > what benefit is derived from focussing on the specific arrival > > > > event as the delineator? > > > > > > > > > > Rajeev: The benefit is a clear starting point for the CT > > > process. (i.e., > > > when to initiate CT) > >=20 > > True enough, but the problem is that it is an event that=20 > happens too late. > > Certainly, for some networks, this may be the only handover=20 > event that > > is visible at L3. But, for many networks, there are L2=20 > triggers, and mobility > > events that can be forwarded to CT. > >=20 > > In this sense, the definition you have provided is too=20 > limited. Perhaps > > the answer is to define another phase. I have no real ideas=20 > on this at the > > moment: how about proactive, reactive and panic ;^} > >=20 > > > > > > > > > > > To explain further, let me illustrate with a scenario:=20 > suppose that > > > > it takes 10ms to complete a context transfer; now suppose > > > > that the ct trigger event happens in less then 10ms from the > > > > actual first packet arrival, say 9 ms - is this a proactive or > > > > reactive ct? The ct that occurs fulfills neither of the offered > > > > definitions. > > > > > > Rajeev: The offered definition does not say anything=20 > about how long > > > context transfer takes place. The _start_ of CT request is > > > the issue. A > > > packet arrives at the new AR (e.g., a MN request for CT),=20 > there is no > > > context there, then you fetch it. > >=20 > > Ok. How CT starts is important. But as important is when it=20 > finishes. > > Indeed, it is more important to me, as I see too little=20 > value in ct that > > finishes after 3 or 4 packets have been forwarded. I want=20 > ct to make real-time > >=20 > > handovers opaque to the end-user. > >=20 > > > > > > > > > > > > > > > > > > If the context is not in place for the first packet=20 > forwarding, then > > > > the transfer is reactive; meaning that at this point,=20 > the goal is to > > > > complete the transfer as fast as possible to minimize=20 > the delay in > > > > forwarding that first packet. > > > > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > >=20 > > But this is in the current requirements. It just doesn't=20 > say that reactive > > starts with the first packet forwarding, accounting for the=20 > fact that in some > > networks, reactive mode can occur before that event. > >=20 > > > > > > > > > > > Reactive CT is when I either choose not to perform=20 > proactive CT, or > > > > I fail to meet the goal of being proactive. > > > > > > Rajeev: Agreed. Can we add the text then ? What do others think = ? > >=20 > > It seems to me that the only part that we disagree on is=20 > what indicates that > > "reactive mode" is occurring. > >=20 > > > > > > Regards, > >=20 > > Onwards and upwards, > > Gary > >=20 > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > > To: seamoby@cdma-2000.org > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions=20 > are missing. > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > Section: 4.5 > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > The section provides the description of proactive and = reactive > > > > > CT without properly defining what they are. We need the > > > definitions. > > > > > > > > > > > > > > Requested Change: > > > > > > > > > > Reactive CT: The context transfer process which takes place > > > > subsequent > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > context transfer > > > > > process in which the required contexts are in place at > > > the target AR > > > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 ------_=_NextPart_001_01C0FA6E.8FEFD520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] proactive and reactive CT definitions

Charlie:

  The issue isn't whether such a ct is useful or = not, the issue
is whether the use of the even of the first packet = "arrival"
should be embedded in the requirements. As I tried = to explain
in my response to Ranjeev, the fpa is useful in some = situations,
but it's not exclusive - some networks will want to = use different
triggers.

And so, perhaps we are back to the debate over what = constitutes
a trigger for a ct - in this case a reactive ct. The = definition must
be open to accommodate different networking = technologies, different
topologies and different operational styles.

BTW, from Merriam-Webster:

Main Entry: pro=B7ac=B7tive
Pronunciation: (")prO-'ak-tiv
Function: adjective
Date: 1933

1 [1pro-] : relating to, caused by, or being = interference between previous learning and the recall or performance of = later learning <proactive inhibition of memory>

2 [2pro- + reactive] : acting in anticipation of = future problems, needs, or changes

(I would quote OED, if I had access).

Cheers,
Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Thursday, June 21, 2001 11:58 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Seamless Mobility Working Group
> Subject: Re: [seamoby] proactive and reactive = CT definitions
>
>
>
> Hello Gary,
>
> I think that, even if context transfer begins = AFTER a node
> finds a new point attachement, it is by no = means necessarily
> too late.  This can be made obvious by a = simple example:
> - What if a node does context transfer after a = link establishment
>   which finalizes .0001 second after = the previous link is dropped?
> If you agree with this, but have concerns about = the .1ms latency,
> then we are just haggling over numbers.  = It shouldn't be the
> place of the context framework document (for = arbitrary media!)
> to arbitrate this, as long as there are media = for which the
> context transfer can occur within meaningful = time constraints.
> I think it's clear that such media will = exist.
>
> So, I claim that the proposed definition for = reactive is very
> beneficial.  A reactive transfer is = initiated after the new
> link is established.  A predictive = transfer is initiated
> before the new link is established.  These = definitions are
> easy, clear, and useful.
>
> Since even the definition of handover seems to = be too muddy,
> perhaps the definition for reactive/predictive = (or, if we must
> use it, the non-English word = "proactive") should depend only
> on link establishment.
>
> Regards,
> Charlie P.
>
>
>
>
>
> > Gary Kenward wrote:
> >
> > Rajeev:
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> > > Sent: Wednesday, June 20, 2001 5:40 = PM
> > > To: Kenward, Gary = [WDLN2:AN10:EXCH]
> > > Cc: seamoby@cdma-2000.org
> > > Subject: Re: [seamoby] proactive and = reactive CT definitions
> > >
> > >
> > > Gary Kenward wrote:
> > >
> > > >
> > > >
> > > > This is essentially the same = definitions I proposed during
> > > > the discussion over proactive = and reactive a few months back.
> > > > And, as someone pointed out, it = was mistaken.
> > > >
> > > > The first question that was = asked then, and is still apropos:
> > > > what benefit is derived from = focussing on the specific arrival
> > > > event as the delineator?
> > > >
> > >
> > > Rajeev: The benefit is a clear = starting point for the CT
> > > process. (i.e.,
> > > when to initiate CT)
> >
> > True enough, but the problem is that it is = an event that
> happens too late.
> > Certainly, for some networks, this may be = the only handover
> event that
> > is visible at L3. But, for many networks, = there are L2
> triggers, and mobility
> > events that can be forwarded to CT.
> >
> > In this sense, the definition you have = provided is too
> limited. Perhaps
> > the answer is to define another phase. I = have no real ideas
> on this at the
> > moment: how about proactive, reactive and = panic ;^}
> >
> > >
> > > >
> > > > To explain further, let me = illustrate with a scenario:
> suppose that
> > > > it takes 10ms to complete a = context transfer; now suppose
> > > > that the ct trigger event = happens  in less then 10ms from the
> > > > actual first packet arrival, say = 9 ms - is this a proactive or
> > > > reactive ct? The ct that occurs = fulfills neither of the offered
> > > > definitions.
> > >
> > > Rajeev: The offered definition does = not say anything
> about how long
> > > context transfer takes place. The = _start_ of CT request is
> > > the issue. A
> > > packet arrives at the new AR (e.g., a = MN request for CT),
> there is no
> > > context there, then you fetch = it.
> >
> > Ok. How CT starts is important. But as = important is when it
> finishes.
> > Indeed, it is more important to me, as I = see too little
> value in ct that
> > finishes after 3 or 4 packets have been = forwarded. I want
> ct to make real-time
> >
> > handovers opaque to the end-user.
> >
> > >
> > >
> > > >
> > > >
> > > > If the context is not in place = for the first packet
> forwarding, then
> > > > the transfer is reactive; = meaning that at this point,
> the goal is to
> > > > complete the transfer as fast as = possible to minimize
> the delay in
> > > > forwarding that first = packet.
> > > >
> > >
> > > Rajeev: Exactly. This is what I am = proposing to be added.
> >
> > But this is in the current requirements. = It just doesn't
> say that reactive
> > starts with the first packet forwarding, = accounting for the
> fact that in some
> > networks, reactive mode can occur before = that event.
> >
> > >
> > > >
> > > > Reactive CT is when I either = choose not to perform
> proactive CT, or
> > > > I fail to meet the goal of being = proactive.
> > >
> > > Rajeev: Agreed.  Can we add the = text then ? What do others think ?
> >
> > It seems to me that the only part that we = disagree on is
> what indicates that
> > "reactive mode" is = occurring.
> >
> > >
> > > Regards,
> >
> > Onwards and upwards,
> > Gary
> >
> > >
> > > -Rajeev
> > >
> > >
> > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]<= /FONT>
> > > > > Sent: Wednesday, June 20, = 2001 2:49 PM
> > > > > To: = seamoby@cdma-2000.org
> > > > > Subject: [seamoby] = proactive and reactive CT definitions
> > > > >
> > > > >
> > > > >
> > > > > Description of issue = :Clear, unambiguous definitions
> are missing.
> > > > >
> > > > > Submitter name: Rajeev = Koodli
> > > > >
> > > > > Submitter email address: = rajeev@iprg.nokia.com
> > > > >
> > > > > Date first submitted: June = 20, 2001
> > > > >
> > > > > Comment type: = 'T'echnical
> > > > >
> > > > > Priority:  ''S'/MUST = fix
> > > > >
> > > > > Section:  4.5
> > > > >
> > > > > Rationale/Explanation of = issue:
> > > > >
> > > > > The section provides the = description of proactive and reactive
> > > > > CT without properly = defining what they are. We need the
> > > definitions.
> > > >
> > > > >
> > > > > Requested Change:
> > > > >
> > > > > Reactive CT: The context = transfer process which takes place
> > > > subsequent
> > > > > to arrival of a MN's packet = at the target AR
> > > > >
> > > > > Proactive (I prfer = Charlie's Predictive better) CT: The
> > > > > context transfer
> > > > > process in which the = required contexts are in place at
> > > the target AR
> > > >
> > > > > prior to the arrival of = MN's packet at target AR.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
>

------_=_NextPart_001_01C0FA6E.8FEFD520-- From owner-seamoby@diameter.org Thu Jun 21 12:39: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 MAA05816 for ; Thu, 21 Jun 2001 12:39:21 -0400 (EDT) Received: (qmail 6185 invoked by alias); 21 Jun 2001 16:27:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6179 invoked by uid 200); 21 Jun 2001 16:27:14 -0000 Received: (qmail 6174 invoked from network); 21 Jun 2001 16:27:13 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 16:27:13 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA28784 for ; Thu, 21 Jun 2001 09:38:12 -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 JAA16059 for ; Thu, 21 Jun 2001 09:38:10 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:38:10 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DDE@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Thu, 21 Jun 2001 11:38:02 -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 Mark, Well, it seems like we are going with ARs (which I like). I don't know much about MRs and Manet, however I think AR has a more precise scope than FN. Does AR imply that the router cannot be mobile? i.e. MR cannot be a subset of AR? I don't care too much about the physical or software definition of a node as Kulwinder described (although, from the implementation point, it is important :) I care about the functionality. For the neutralness in this discussion I use my own favorite term CT peer instead of FN or AR. Now, But To answer your question:: of course if the node offering CT is mobile, it makes a lot of difference, 1-how would you handle the security associations for pre-authentication between CT peers, if the CT peer is mobile? 2-How would you handle the associations in case you are using a transport protocol like SCTP? 3- The context also needs to be available at the CT peer prior to the CT, so whatever network element that wants to make sure CT peer has enough supply for the next CT, needs to track the CT peer to feed it. These are problems that do need a WHOLE lot of consideration when the CT peer is mobile. Madjid -----Original Message----- From: Mark Smith [mailto:mark.smith@comdev.cc] Sent: Wednesday, June 20, 2001 3:57 PM To: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology Thank you, yes, that summarizes quite nicely what I was trying to say. I'm not trying to say that this isn't a problem, I'm asking if anyone can see why it would be. I can't, but I don't claim to be all knowing. :) -Mark Kulwinder Atwal wrote: > To expand on Mark's comment: > > If we think of an AR or MN as a software thread/task/process with its own AR > context/MN context, instead of physical devices, then we should be able to > keep the terms AR and MN seperate. > > 1. A physical device may have just the AR task running, in which case it is > only an AR. > > 2. A physical device may have just the MN task running, in which case it is > only an MN. > > 3. A physical device may have a MN task and an AR task running in which case > it is both, but the functionality is modularized. > > With the AR discovery protocol is possible to learn in a mobile environment > which mobile device nearby has an AR task running before attempting CT. > > - Kulwinder. > > >>-----Original Message----- >>From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] >>Sent: Wednesday, June 20, 2001 3:06 PM >>To: Mark Smith >>Cc: seamoby@cdma-2000.org >>Subject: Re: [seamoby] Issue 1: Change access network terminology >> >> >> >>Perhaps I am missing something.. Aren't we concerned about >>the "entity" which offers >>different features (QoS, HC,..) ? I guess we went with AR >>because that's the entity >>that typically offers the features. >> >>Regards, >> >>-Rajeev >> >> >>Mark Smith wrote: >> >> >>>I guess my question is, does it matter if a Forwarding Node >>> >>(as Gary has >> >>>defined them) is also a Mobile Node? What effect does it >>> >>have on our >> >>>design/requirement/problem statement? >>> >>>I think the idea is that, for the sake of a particular CTP >>> >>session, a >> >>>node is either an MN or an FN. If it's an FN for this CTP >>> >>session, it >> >>>may be an MN for another session, but those two sessions >>> >>are independant >> >>>of each other and should be viewed as such. >>> >>>-Mark >>> >>>Pat Calhoun wrote: >>> >>> >>>>On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: >>>> >>>> >>>>>If we do this (which would be find for me, regardless of >>>>> >>what my last >> >>>>>post said :), make sure we define it to address Phil's >>>>> >>requests. I >> >>>>>think if we were to specify that an AR, in our case, is >>>>> >>not neccessarily >> >>>>>a fixed, wired device, that it can, infact, be an MN >>>>> >>itself, that should >> >>>>>do the trick. >>>>> >>>>>Whatever we call it, it should be defined. >>>>> >>>>> >>>>yes, you posts crossed each other :) >>>> >>>>Well, if a CT peer can be an MN, then the use of AR is >>>> >>clearly innapropriate. >> >>>>AR is an access router, and this is typically where I see >>>> >>CT being used, but >> >>>>I understand that there are others, such as Phil, that >>>> >>see CT as having many >> >>>>other uses. >>>> >>>>Perhaps we should first have someone open an issue on >>>> >>whether an MN can in fact >> >>>>be a CT peer, and the result of that issue would dictate >>>> >>the future of this one. >> >>>>PatC >>>> >>>> From owner-seamoby@diameter.org Thu Jun 21 12:56:51 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06716 for ; Thu, 21 Jun 2001 12:56:43 -0400 (EDT) Received: (qmail 6731 invoked by alias); 21 Jun 2001 16:43:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6725 invoked by uid 200); 21 Jun 2001 16:43:44 -0000 Received: (qmail 6720 invoked from network); 21 Jun 2001 16:43:42 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 16:43:42 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA07529 for ; Thu, 21 Jun 2001 09:54:42 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA07388 for ; Thu, 21 Jun 2001 09:47:55 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:54:41 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 11:54:17 -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 Hello Rajeev: Sorry for late response. Please see my inline response. regards., ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 7:00 PM To: Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Ajoy, see my replies in-line. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > Hello Rajeev: > Please find my clarification. > regards, > ajoy > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > Ajoy: In some network, it is easier to receive link layer trigger > at the target access network much before the completion of link layer and > network > layer handoff. The trigger is available when link layer handover > is in progress. For example, the target trigger can be available > due to exchange of some link layer message from oldAR to newAR or may be > from > MN to newAR. Rajeev: I guess what you describe could be called a "link-layer triggered CT". This is fine on those links where the link-layer trigger is available. Would go as far as saying that such a CT is reactive CT ? I would not.. Ajoy:-> The reason I called this reactive because link layer trigger is available when handoff is in progress. I guess you can call some thing predictive when handover is not yet started. In predictive case you are predicting based upon power management or something else that handoff is likely to happen but may not eventually happen. > I suppose this target trigger can be used to > initiate so called reactive CT. Please note that there is big > benefit of doing this. Rajeev: I agree that there are benefits in using link layer triggers. There are also pitfalls. When you transfer context due to a link-layer trigger while the old AR is still forwarding packets, the contexts (on the new AR and old AR) are out of sync. Ajoy: -> In what way it is different in case of predictive handover. I hope these race conditions if any should be taken care of in protocol design not in requirement. > In this case, you know that MN is moving > to a particular destination network, so you don't end up sending > Context to unwanted ARs. In case of proactive CT, CT is initiated > based upon some prediction which may not be always correct. Rajeev: Well, proactive need not mean that we don't know where the MN is going (and thus we will CT to many ARs). Anyway, let me indicate to you the two cases below. 1. We know well in advance the MN is going to new AR. So we do the CT to that AR so that all the contexts are in place before the first packet arrives at new AR. You could make use of link-layer triggers here. 2. Due to network conditions, the MN looses its link with old AR and shows up (after a while) at new AR. You could do CT here after the first packet from the MN arrives. Perhaps you could make use of link-layer triggers here as well. -> I think you got my point. We should rather prefer to use link layer trigger because this will be available before IP packet is received by newAR. Any context transfer based upon this will be faster. So I think we should not eliminate the case where reactive handover can be initiated based upon some link layer trigger at newAR. We could call 1> proactive or predictive, and 2> reactive. How's that ? Ok. > > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 5:11 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > Rajeev: It's a good going trend to straighten things out. > > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in agreement that > > reactive CT, does not always mean that CT cannot start until after the > MN's > > packets have arrived. > > > > Rajeev: Reactive CT means that there is no context at the new AR when MN's > packets arrive. If we want to do CT, I would think that that's a good time > to > start. > Going by your argument, when do you start a reactive CT ? If we both agree > that > there is no context in place when the MN's packets arrive, what do you do ? > If > you had started CT before, that's proactive, but not working very well. > Claiming that reactive CT is the "proactive CT gone bad" is extremely poor > definition. I don't believe that I agreed at all to such a definition. > Please > enlighten me! > > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > Rajeev: Where is this definition ? This can take another avatar of its own > :-) > > > > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > Rajeev: If the context is not present when the MN's packet arrive, you try > to > get it. Right ? Why is that not reactive CT ? If CT is not there, and while > I try to fetch it, why can't I forward the packets if it is possible ? If > I *don't* forward packets, what do I do ? Drop them ? How's that good for > TCP/RTP's performance ? Consider the ability to send and receive normal IP > packets as a service (aka connectivity) upon which the rest of the CT > features > are based. > > For HC, you could forward on downlink. For security, you could forward the > packets in both the directions until you receive the appropriate contexts. > You > may not have a packet *treated* with require feature, but you can still > forward > packets. If CT fails all together, what do you do ? You could require the MN > to > re-authenticate itself. How do you do that ? You need connectivity to send > and > receive IP packets. > In a nut shell, if there are no contexts, you can always go fetch them *or* > require the MN to re-establish them. > > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > I understand that when a packet arrives at new AR, the CT may be already "in > progress", as indicated by the signaling that has taken place. The new AR > may > *still* initiate CT signaling and the old AR must be able to handle requests > that come in sequence. It is called "idempotent" operation. > > Regards, > > -Rajeev > > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Thu Jun 21 13:01: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 NAA07134 for ; Thu, 21 Jun 2001 13:01:54 -0400 (EDT) Received: (qmail 6868 invoked by alias); 21 Jun 2001 16:44:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6861 invoked by uid 200); 21 Jun 2001 16:44:55 -0000 Received: (qmail 6840 invoked from network); 21 Jun 2001 16:44:47 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 16:44:47 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA08738 for ; Thu, 21 Jun 2001 09:55:40 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA07925 for ; Thu, 21 Jun 2001 09:48:53 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 11:55:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DDF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 11:55:38 -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 Hello Rajeev, See responses below. I will send another email shortly. Regards, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 5:11 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > Rajeev: It's a good going trend to straighten things out. MN>> Cool. However, I think we are revisiting old stuff, without adding new information. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > Rajeev: Reactive CT means that there is no context at the new AR when MN's packets arrive. If we want to do CT, I would think that that's a good time to start. MN>> No, it means the CT is not complete, there might be some context there already (whether you can use it or not, depends on how you design the CTP, to handle partial context). Also it does not mean that you have not started CT. Going by your argument, when do you start a reactive CT ? If we both agree that there is no context in place when the MN's packets arrive, what do you do ? If you had started CT before, that's proactive, but not working very well. MN>> who said it is not working very well? Claiming that reactive CT is the "proactive CT gone bad" is extremely poor definition. I don't believe that I agreed at all to such a definition. Please enlighten me! MN>> That is your own interpretation. Nobody claimed that reactive=proactive gone bad (that is only one subset of reactive). If your network or L2 does not provide good CT triggers, you can't blame CTP for it. Remember Kulwinder's second point: CT signaling is different from CT triggers. > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. Rajeev: Where is this definition ? This can take another avatar of its own :-) MN>> I offerred an interpretation not a text segment from the draft. If you go back to the archives, you see that this has been mentioned many times, maybe even by yourself :) > > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > Rajeev: If the context is not present when the MN's packet arrive, you try to get it. Right ? Why is that not reactive CT ? If CT is not there, and while I try to fetch it, why can't I forward the packets if it is possible ? If I *don't* forward packets, what do I do ? Drop them ? How's that good for TCP/RTP's performance ? Consider the ability to send and receive normal IP packets as a service (aka connectivity) upon which the rest of the CT features are based. MN>> Rajeev, Packet forwarding, buffering, dropping, routing changes are not CT issues, they are routing and Mobile IP issues. There was a big discussion on forwarding and buffering of packets on MIP list, I suggest you take a look at it. Buffering and forwarding is not the issue CT needs to solve but it is an issue for a fast or smooth handover team :) We are not working to make L3 HO faster or with less packet loss, that is MIP fast handover group's job. Our job is to make a fast and "reliable CT (a Context than newAR can beleive in)". However, if MObile IP defines our mobility scope, then we strive on doing CT within the time budget that Mobile IP (or its fast handoff syster) provides, if we make it, it is proactive. If HO is very fast and/or oldAR or newAR start CT too late, then CT might not finish before HO completion, then it is reactive, it is our disclaimer!! Now I did discussion the possibility of having high priority context and low priority context, so that the former should be completed prior to deadline and latter after. This would alleviate the CT delay issues. \MN>> For HC, you could forward on downlink. For security, you could forward the packets in both the directions until you receive the appropriate contexts. You may not have a packet *treated* with require feature, but you can still forward packets. If CT fails all together, what do you do ? You could require the MN to re-authenticate itself. How do you do that ? You need connectivity to send and receive IP packets. In a nut shell, if there are no contexts, you can always go fetch them *or* require the MN to re-establish them. MN>>It seems you are questioning the usefulness of CT and its role on the timing of the events, if you think the packets can be delivered and then you establish HC context and re-negotiate authentication and other things, then why is CT timing so critical, you are contradicting yourself. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > Rajeev: When would you start CT in this case ? When does new AR receive L2 trigger ? Is it trying to do CT when it receives a HI ? MN>> This is a CT trigger question. See my next email. I understand that when a packet arrives at new AR, the CT may be already "in progress", as indicated by the signaling that has taken place. The new AR may *still* initiate CT signaling and the old AR must be able to handle requests that come in sequence. It is called "idempotent" operation. Regards, -Rajeev > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Thu Jun 21 13:10: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 NAA07620 for ; Thu, 21 Jun 2001 13:10:04 -0400 (EDT) Received: (qmail 7748 invoked by alias); 21 Jun 2001 16:57:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7742 invoked by uid 200); 21 Jun 2001 16:57:01 -0000 Received: (qmail 7737 invoked from network); 21 Jun 2001 16:56:59 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 16:56:59 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA24375 for ; Thu, 21 Jun 2001 10:07:59 -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 KAA04475 for ; Thu, 21 Jun 2001 10:07:58 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:07:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE0@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: [seamoby] CT trigger or CT completion? was: proactive and reactive CT defi nitions Date: Thu, 21 Jun 2001 12:07:52 -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 Rajeev, I think, I know what the problem is: The draft bases the definition of Proactive and reactive on when the handover (packet arrival) COMPLETE S. You, on the other hand, are basing you definition on the START of CT, i.e. CT trigger. I think the drafts approach is better FOR NOW since, we have not completed the frame work discussion yet (we did have a discussion about Mobility framework, and I did ask the question of whether the scope is Mobile IP or not, of the very same reason). When you don't know what your underlying layer 2 technology or your Layer 3 mobility baseline is, then you have to speak in common, general terms, such as packet arrival. Start of CT can be based on all kinds of things: Example From Mobile IP fast handover perspective: 1-Solicitation for proxy router 2-Binding update 3-Neighbor advertisement from Mobile Example From a link layer perspective 1-Pilot beacon/ signal strenght measurement 2-RLC/P/ RNC scheduler directive 3-Mobility management unit ...... From a CNP network that is doing more advance next router discovery there could be other types of signals, especially for proactive, you are understimating the beyond 3G scenarios. So which CT trigger do you want to pick? Earlier trigger + less amount context + higher AR-AR bandwith leads to a faster CT (more chance for proactive). A slow handover solution (base Mobile IP) waits for L2 HO completion and then starts L3 signaling, a faster handover solution starts earlier. So we are talking about a race condition between CT and HO if we don't know the details of the system, so we base the definition on CT completion and that is why we simply say, if the CT is done prior to packet arrival, then it is proactive, if not it is reactive. two months ago, I was screaming for an event sequence out of the handoveer procedure for timing requierement, I suggested to define CT triggers and CT deadline based on the event sequence I asked YOU for a HC based CT deadline event, I don't remember you offering any? I also suggested that we would prioritize features and then set a halfway CT deadline for reactive, so that by that deadline only the time critical feature contexts are through and again used HC as example. So why are we in a different situation now? ****Unless you offer a clear event sequence and show different Handover stages and the need of packet delivery for various feature context, I don't think we can change our definition and base it on an start event.***** ****Furthermore, I think Kulwinder issue #2 covers this aspect. Unless you want to As I said in my other email: It seems you are questioning the usefulness of CT and its role on the timing of the events, if you think the packets can be delivered and then you establish HC context and re-negotiate authentication and other things, then why is CT timing so critical, you are contradicting yourself. Regards, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 5:11 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > I still don't know whether I should respond to these issues or not, > but it seems that is the going trend. > Rajeev: It's a good going trend to straighten things out. > > For Proactive, your definition works, and actually it is the same > as in the draft. > > I think this definition of reactive is going backward a bit. > We did discuss this issue at length and I think you were in agreement that > reactive CT, does not always mean that CT cannot start until after the MN's > packets have arrived. > Rajeev: Reactive CT means that there is no context at the new AR when MN's packets arrive. If we want to do CT, I would think that that's a good time to start. Going by your argument, when do you start a reactive CT ? If we both agree that there is no context in place when the MN's packets arrive, what do you do ? If you had started CT before, that's proactive, but not working very well. Claiming that reactive CT is the "proactive CT gone bad" is extremely poor definition. I don't believe that I agreed at all to such a definition. Please enlighten me! > > For reactive, CT can happens simultaneous as Handover signaling > but it might not finish when handover signaling is complete. Rajeev: Where is this definition ? This can take another avatar of its own :-) > > > What you are suggesting, means that you don't need CT to deliver > packets the mobile and are totally moving CT out of the critical > path for timing. I guess say for header compression > it means that the newAR does not have HC states for a while, > assuming it can receive uncompressed packets, > But would this work for security and authentication, I don't think so. > Rajeev: If the context is not present when the MN's packet arrive, you try to get it. Right ? Why is that not reactive CT ? If CT is not there, and while I try to fetch it, why can't I forward the packets if it is possible ? If I *don't* forward packets, what do I do ? Drop them ? How's that good for TCP/RTP's performance ? Consider the ability to send and receive normal IP packets as a service (aka connectivity) upon which the rest of the CT features are based. For HC, you could forward on downlink. For security, you could forward the packets in both the directions until you receive the appropriate contexts. You may not have a packet *treated* with require feature, but you can still forward packets. If CT fails all together, what do you do ? You could require the MN to re-authenticate itself. How do you do that ? You need connectivity to send and receive IP packets. In a nut shell, if there are no contexts, you can always go fetch them *or* require the MN to re-establish them. > > I like the current definition for reactive: > "doing CT when handover is imminent" and that means that oldAR or > newAR are already engaged in handover signaling, now this could be > a L2 trigger that newAR has received or a HI or something else, but > it does not mean completion of handover signaling and packet routing > change. > Rajeev: When would you start CT in this case ? When does new AR receive L2 trigger ? Is it trying to do CT when it receives a HI ? I understand that when a packet arrives at new AR, the CT may be already "in progress", as indicated by the signaling that has taken place. The new AR may *still* initiate CT signaling and the old AR must be able to handle requests that come in sequence. It is called "idempotent" operation. Regards, -Rajeev > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 1:49 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] proactive and reactive CT definitions > > Description of issue :Clear, unambiguous definitions are missing. > > Submitter name: Rajeev Koodli > > Submitter email address: rajeev@iprg.nokia.com > > Date first submitted: June 20, 2001 > > Comment type: 'T'echnical > > Priority: ''S'/MUST fix > > Section: 4.5 > > Rationale/Explanation of issue: > > The section provides the description of proactive and reactive > CT without properly defining what they are. We need the definitions. > > Requested Change: > > Reactive CT: The context transfer process which takes place subsequent > to arrival of a MN's packet at the target AR > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > process in which the required contexts are in place at the target AR > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Thu Jun 21 13:19: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 NAA08099 for ; Thu, 21 Jun 2001 13:19:18 -0400 (EDT) Received: (qmail 8690 invoked by alias); 21 Jun 2001 17:06:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8683 invoked by uid 200); 21 Jun 2001 17:06:07 -0000 Received: (qmail 8671 invoked from network); 21 Jun 2001 17:06:04 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 17:06:04 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA27545 for ; Thu, 21 Jun 2001 10:16:57 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA20902 for ; Thu, 21 Jun 2001 10:10:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:16:54 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE2@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 12:16:52 -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 Rajeev, Ajoy, This is a prime example of why basing the definition on a CT trigger is a tricky business when not knowing Mobility protocol, L2 signaling and the amount of context. We can also get into the discussion of whether to use L2 source or target trigger, loss of L2 to oldAR or connectivity to newAR and all sort of things. Please see below for some other comments, Regards, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 7:00 PM To: Singh Ajoy-ASINGH1 Cc: Nakhjiri Madjid-MNAKHJI1; seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Ajoy, see my replies in-line. Regards, -Rajeev Singh Ajoy-ASINGH1 wrote: > Hello Rajeev: > Please find my clarification. > regards, > ajoy > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > Ajoy: In some network, it is easier to receive link layer trigger > at the target access network much before the completion of link layer and > network > layer handoff. The trigger is available when link layer handover > is in progress. For example, the target trigger can be available > due to exchange of some link layer message from oldAR to newAR or may be > from > MN to newAR. Rajeev: I guess what you describe could be called a "link-layer triggered CT". This is fine on those links where the link-layer trigger is available. Would go as far as saying that such a CT is reactive CT ? I would not.. > I suppose this target trigger can be used to > initiate so called reactive CT. Please note that there is big > benefit of doing this. Rajeev: I agree that there are benefits in using link layer triggers. There are also pitfalls. When you transfer context due to a link-layer trigger while the old AR is still forwarding packets, the contexts (on the new AR and old AR) are out of sync. > In this case, you know that MN is moving > to a particular destination network, so you don't end up sending > Context to unwanted ARs. In case of proactive CT, CT is initiated > based upon some prediction which may not be always correct. Rajeev: Well, proactive need not mean that we don't know where the MN is going (and thus we will CT to many ARs). Anyway, let me indicate to you the two cases below. MN>> Actually Rajeev, one of the intentions of Proactive was to cover the case, in which we don't know where the MN is going. We wanted to move CT out of the critical path when making Handover decisions (which AR to handover to, I don't think this problem is solved yet). 1. We know well in advance the MN is going to new AR. So we do the CT to that AR so that all the contexts are in place before the first packet arrives at new AR. You could make use of link-layer triggers here. 2. Due to network conditions, the MN looses its link with old AR and shows up (after a while) at new AR. You could do CT here after the first packet from the MN arrives. Perhaps you could make use of link-layer triggers here as well. We could call 1> proactive or predictive, and 2> reactive. How's that ? > > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 20, 2001 5:11 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > Rajeev: It's a good going trend to straighten things out. > > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in agreement that > > reactive CT, does not always mean that CT cannot start until after the > MN's > > packets have arrived. > > > > Rajeev: Reactive CT means that there is no context at the new AR when MN's > packets arrive. If we want to do CT, I would think that that's a good time > to > start. > Going by your argument, when do you start a reactive CT ? If we both agree > that > there is no context in place when the MN's packets arrive, what do you do ? > If > you had started CT before, that's proactive, but not working very well. > Claiming that reactive CT is the "proactive CT gone bad" is extremely poor > definition. I don't believe that I agreed at all to such a definition. > Please > enlighten me! > > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > Rajeev: Where is this definition ? This can take another avatar of its own > :-) > > > > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > Rajeev: If the context is not present when the MN's packet arrive, you try > to > get it. Right ? Why is that not reactive CT ? If CT is not there, and while > I try to fetch it, why can't I forward the packets if it is possible ? If > I *don't* forward packets, what do I do ? Drop them ? How's that good for > TCP/RTP's performance ? Consider the ability to send and receive normal IP > packets as a service (aka connectivity) upon which the rest of the CT > features > are based. > > For HC, you could forward on downlink. For security, you could forward the > packets in both the directions until you receive the appropriate contexts. > You > may not have a packet *treated* with require feature, but you can still > forward > packets. If CT fails all together, what do you do ? You could require the MN > to > re-authenticate itself. How do you do that ? You need connectivity to send > and > receive IP packets. > In a nut shell, if there are no contexts, you can always go fetch them *or* > require the MN to re-establish them. > > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > I understand that when a packet arrives at new AR, the CT may be already "in > progress", as indicated by the signaling that has taken place. The new AR > may > *still* initiate CT signaling and the old AR must be able to handle requests > that come in sequence. It is called "idempotent" operation. > > Regards, > > -Rajeev > > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Thu Jun 21 13:23: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 NAA08341 for ; Thu, 21 Jun 2001 13:23:05 -0400 (EDT) Received: (qmail 9079 invoked by alias); 21 Jun 2001 17:10:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9071 invoked by uid 200); 21 Jun 2001 17:10:01 -0000 Received: (qmail 9059 invoked from network); 21 Jun 2001 17:09:57 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 17:09:57 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA23108 for ; Thu, 21 Jun 2001 10:14:00 -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 KAA06831 for ; Thu, 21 Jun 2001 10:20:44 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:20:44 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE3@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Gary Kenward Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Thu, 21 Jun 2001 12:20:15 -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 Rajeev: why would we have to add L2 signaling ? An IP message to initiate CT would be needed for the MN and is perhaps useful for other entities. I think it is doable. MN>> This IP layer CT is starting to sound like Alchemy :) Everybody talks about it, nobody is providing it. Say you are using MIPv6 fast handoff, Which message is it, that triggers CT? Madjid From owner-seamoby@diameter.org Thu Jun 21 13:25: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 NAA08577 for ; Thu, 21 Jun 2001 13:25:25 -0400 (EDT) Received: (qmail 9300 invoked by alias); 21 Jun 2001 17:11:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9292 invoked by uid 200); 21 Jun 2001 17:11:48 -0000 Received: (qmail 9270 invoked from network); 21 Jun 2001 17:11:44 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 17:11:44 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA24489 for ; Thu, 21 Jun 2001 10:15:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA24129 for ; Thu, 21 Jun 2001 10:15:57 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:22:43 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Thu, 21 Jun 2001 12:22: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 Hi John, Why is explicit messaging so important, it might even add more delay. I think we should go after the event that triggers this signaling (implicit or explicit is less important IMHO). Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, June 21, 2001 1:11 AM To: Madjid.Nakhjiri Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Hi Madjid, > What is a "common" IP level trigger mean here? common with what? Common might not be the correct term, perhaps standard would be better? Of course, going into standard IP triggers gets into an API issue. Should we go down that road already? > What is the difference between "signalling to initiate context tranfer > (which is a CT trigger)" and "common IP level triggers". I am making a seperation between an explicit message (i.e. - signaling) and the arrival of some data (which could be a trigger). > Don't get me wrong, I think I was among the very first people who > talked about CT trigger, but I am not sure I see the > difference the two. I think the difference (in my mind) is whether we have implicit signaling or explicit signaling. More comments in my next mail. John From owner-seamoby@diameter.org Thu Jun 21 13:27:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08703 for ; Thu, 21 Jun 2001 13:27:38 -0400 (EDT) Received: (qmail 9629 invoked by alias); 21 Jun 2001 17:13:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9618 invoked by uid 200); 21 Jun 2001 17:13:22 -0000 Received: (qmail 9595 invoked from network); 21 Jun 2001 17:13:17 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 17:13:17 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA25325 for ; Thu, 21 Jun 2001 10:17:29 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA21211 for ; Thu, 21 Jun 2001 10:24:13 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:24:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Date: Thu, 21 Jun 2001 12:24:13 -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 like this idea. Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, June 21, 2001 1:34 AM To: pcalhoun@diameter.org; seamoby@cdma-2000.org Subject: RE: [seamoby] Question on CT req 4.9 Hi Pat > This require appears to imply that a context transfer is a > one-shot event. The whole > enchalada is sent when handoff occurs. Although I tend to > agree with this, I would > claim that in my mind (at least) it seems feasible for high > priority data to be > collected and transferred (e.g. HC state), while lower > priority data be sent > a few seconds later (e.g. AAA accounting information). I agree with you. I think 4.9 should be rewritten so that the whole enchalada can be sent at once, but does not have to be. br, John From owner-seamoby@diameter.org Thu Jun 21 13:34: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 NAA09176 for ; Thu, 21 Jun 2001 13:34:48 -0400 (EDT) Received: (qmail 8062 invoked by alias); 21 Jun 2001 17:00:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8055 invoked by uid 200); 21 Jun 2001 17:00:18 -0000 Received: (qmail 8045 invoked from network); 21 Jun 2001 17:00:14 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 17:00:14 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA28250 for ; Thu, 21 Jun 2001 10:11:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA17566 for ; Thu, 21 Jun 2001 10:04:26 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 12:11:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DE1@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 12:11:12 -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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, June 20, 2001 5:55 PM To: Kulwinder Atwal Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Kulwinder Atwal wrote: > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, June 20, 2001 6:16 PM > > To: Kulwinder Atwal > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > Hello Kulwinder, > > > > Kulwinder Atwal wrote: > > > > > I also like the definition as stated in the draft, becuase > > if the MN has no > > > real-time traffic, then the AR can choose to conserve > > scarce bandwidth by > > > doing Reactive CT with no percievable impact for the End-user. > > > > > > > Rajeev: does this mean that reactive CT is only for the non > > real-time traffic > > ? > >What happens if I cannot do proactive CT and I _do_ have > > real-time traffic ? > > Would you not do any CT at all then ? > > > > If we can prioritize context, and provide partial context updates of > real-time context, then I am fine with your request to change the text. > > Rajeev: May be you would like to bring this up a separate issue ? Coming back to the point I have raised, I hope you would agree that we have to consider reactive CT independent of real-time nature of the traffic. Sometimes, all you have is basic connectivity, and you could use it to reactively fetch contexts. MN>> Again I think reactive-ness has more to do with CT-handover timing, which is a result of network/ handover design rather than the nature of the application traffic. my 2/100, Madjid Regards, -Rajeev > - Kulwinder. > > > > > > > > > If I am doing a file download and loose 60mSec lets say to > > Reactive CT, I > > > will not notice as an End-User. > > > > > > > Rajeev: good example. Not sufficient :-) > > > > Regards, > > > > -Rajeev > > > > > > > > > > - Kulwinder. > > > > > > > -----Original Message----- > > > > From: Nakhjiri Madjid-MNAKHJI1 > > [mailto:Madjid.Nakhjiri@motorola.com] > > > > Sent: Wednesday, June 20, 2001 5:30 PM > > > > To: 'Rajeev Koodli'; seamoby@cdma-2000.org > > > > Subject: RE: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > I still don't know whether I should respond to these > > issues or not, > > > > but it seems that is the going trend. > > > > > > > > For Proactive, your definition works, and actually it is the same > > > > as in the draft. > > > > > > > > I think this definition of reactive is going backward a bit. > > > > We did discuss this issue at length and I think you were in > > > > agreement that > > > > reactive CT, does not always mean that CT cannot start until > > > > after the MN's > > > > packets have arrived. > > > > > > > > For reactive, CT can happens simultaneous as Handover signaling > > > > but it might not finish when handover signaling is complete. > > > > > > > > What you are suggesting, means that you don't need CT to deliver > > > > packets the mobile and are totally moving CT out of the critical > > > > path for timing. I guess say for header compression > > > > it means that the newAR does not have HC states for a while, > > > > assuming it can receive uncompressed packets, > > > > But would this work for security and authentication, I > > don't think so. > > > > > > > > I like the current definition for reactive: > > > > "doing CT when handover is imminent" and that means that oldAR or > > > > newAR are already engaged in handover signaling, now this could be > > > > a L2 trigger that newAR has received or a HI or something > > else, but > > > > it does not mean completion of handover signaling and > > packet routing > > > > change. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 20, 2001 1:49 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > Comment type: 'T'echnical > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > Section: 4.5 > > > > > > > > Rationale/Explanation of issue: > > > > > > > > The section provides the description of proactive and reactive > > > > CT without properly defining what they are. We need the > > definitions. > > > > > > > > Requested Change: > > > > > > > > Reactive CT: The context transfer process which takes > > place subsequent > > > > to arrival of a MN's packet at the target AR > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > context transfer > > > > process in which the required contexts are in place at > > the target AR > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 15:33: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 PAA15334 for ; Thu, 21 Jun 2001 15:33:13 -0400 (EDT) Received: (qmail 11177 invoked by alias); 21 Jun 2001 19:21:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11171 invoked by uid 200); 21 Jun 2001 19:21:27 -0000 Received: (qmail 11166 invoked from network); 21 Jun 2001 19:21:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 19:21:25 -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 MAA01357; Thu, 21 Jun 2001 12:31:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LJVtI30083; Thu, 21 Jun 2001 12:31:55 -0700 X-mProtect: Thu, 21 Jun 2001 12:31:55 -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 smtpdFRmuyj; Thu, 21 Jun 2001 12:31:53 PDT Message-ID: <3B324BAA.C4A297FB@iprg.nokia.com> Date: Thu, 21 Jun 2001 12:31:54 -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: Gary Kenward CC: Seamless Mobility Working Group Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D75@zcard031.ca.nortel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit Hello Gary, You wrote: > The issue isn't whether such a ct is useful or not, the issue > is whether the use of the even of the first packet "arrival" > should be embedded in the requirements. As I tried to explain > in my response to Rajeev, the fpa is useful in some situations, > but it's not exclusive - some networks will want to use different > triggers. Yes, we agree on this. (I fixed Rajeev's name) > And so, perhaps we are back to the debate over what constitutes > a trigger for a ct - in this case a reactive ct. The definition must > be open to accommodate different networking technologies, different > topologies and different operational styles. No, I don't think that this is the central issue. I think the central issue for the trigger is the link establishment, and that the central issue for the definition of reactive vs. predictive is whether the context transfer is initiated after vs. before the new link is established. I'm going to be careful not to use the word "handover" for a while, because it seems to have too much baggage. > BTW, from Merriam-Webster: > > Main Entry: pro·ac·tive ..... > 2 [2pro- + reactive] : acting in anticipation of future problems, needs, or > changes Thanks for the lookup -- it's not there in my desk reference, which probably just means that the word isn't as common as, say, predictive. However, given that some dictionaries have it, I'll be happy to soften my objection to its use. Regards, Charlie P. From owner-seamoby@diameter.org Thu Jun 21 16:31: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 QAA16979 for ; Thu, 21 Jun 2001 16:31:20 -0400 (EDT) Received: (qmail 12399 invoked by alias); 21 Jun 2001 20:18:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12393 invoked by uid 200); 21 Jun 2001 20:18:33 -0000 Received: (qmail 12388 invoked from network); 21 Jun 2001 20:18:31 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 20:18:31 -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 NAA06330; Thu, 21 Jun 2001 13:29:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LKT1q09533; Thu, 21 Jun 2001 13:29:01 -0700 X-mProtect: Thu, 21 Jun 2001 13:29:01 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdS3CF5E; Thu, 21 Jun 2001 13:29:00 PDT Message-ID: <3B32590D.3EFB29DC@iprg.nokia.com> Date: Thu, 21 Jun 2001 13:29:01 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D71@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > > > > Rajeev: The benefit is a clear starting point for the CT > > process. (i.e., > > when to initiate CT) > > True enough, but the problem is that it is an event that happens too > late. > Certainly, for some networks, this may be the only handover event that > > is visible at L3. But, for many networks, there are L2 triggers, and > mobility > events that can be forwarded to CT. > > In this sense, the definition you have provided is too limited. > Perhaps > the answer is to define another phase. I have no real ideas on this at > the > moment: how about proactive, reactive and panic ;^} > Rajeev: Given that you agree (at least partially) that in some networks, (or "inter-networks") IP message after the link is established is the only way you could request CT, I would argue that the current definition, which is based on L2 triggers and "mobility events", is too limited. It is ironic that we are debating whether to use IP messaging to request CT once the link is established.. > > > Rajeev: The offered definition does not say anything about how long > > context transfer takes place. The _start_ of CT request is > > the issue. A > > packet arrives at the new AR (e.g., a MN request for CT), there is > no > > context there, then you fetch it. > > Ok. How CT starts is important. But as important is when it finishes. > Indeed, it is more important to me, as I see too little value in ct > that > finishes after 3 or 4 packets have been forwarded. I want ct to make > real-time > handovers opaque to the end-user. > > Rajeev: While I don't necessarily agree with the example, we all want CT to finish before the packets start arriving. That's why we have predictive handovers. When you can't do such a thing, e.g., consider that link-layer triggers don't work because the two technologies are different, you have the initiation of reactive CT after the MN establishes a new link. > > > If the context is not in place for the first packet forwarding, > then > > > the transfer is reactive; meaning that at this point, the goal is > to > > > complete the transfer as fast as possible to minimize the delay in > > > > forwarding that first packet. > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > But this is in the current requirements. It just doesn't say that > reactive > starts with the first packet forwarding, accounting for the fact that > in some > networks, reactive mode can occur before that event. > Rajeev: Is it possible to re-word it such that it takes care of the issue we have raised ? Can we say that reactive CT takes place as a consequence of MN establishing a new link ? This would be sufficient. > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, > or > > > I fail to meet the goal of being proactive. > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > It seems to me that the only part that we disagree on is what > indicates that "reactive mode" is occurring. > Rajeev: Yes, and some text along the above lines would do it. Regards, -Rajeev > > > > > Regards, > > Onwards and upwards, > Gary > > > > > -Rajeev > > > > > > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are > missing. > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > Comment type: 'T'echnical > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > Section: 4.5 > > > > > > > > Rationale/Explanation of issue: > > > > > > > > The section provides the description of proactive and reactive > > > > CT without properly defining what they are. We need the > > definitions. > > > > > > > > > > > Requested Change: > > > > > > > > Reactive CT: The context transfer process which takes place > > > subsequent > > > > to arrival of a MN's packet at the target AR > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > context transfer > > > > process in which the required contexts are in place at > > the target AR > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 16:42: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 QAA17285 for ; Thu, 21 Jun 2001 16:42:18 -0400 (EDT) Received: (qmail 12880 invoked by alias); 21 Jun 2001 20:29:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12874 invoked by uid 200); 21 Jun 2001 20:29:07 -0000 Received: (qmail 12869 invoked from network); 21 Jun 2001 20:29:05 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 20:29:05 -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 NAA07233; Thu, 21 Jun 2001 13:39:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LKda327068; Thu, 21 Jun 2001 13:39:36 -0700 X-mProtect: Thu, 21 Jun 2001 13:39:36 -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 smtpdRQK32w; Thu, 21 Jun 2001 13:39:34 PDT Message-ID: <3B325B86.50F24EC9@iprg.nokia.com> Date: Thu, 21 Jun 2001 13:39:34 -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: seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DE0@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 Madjid, I hope you don't mind if I edge a word in between. > I think, I know what the problem is: > The draft bases the definition of Proactive and reactive on > when the handover (packet arrival) COMPLETE S. But the problem could be that the term "handover" is not sufficiently crisp to carry out the discussion. The concept of link establishment, however, is crisp enough. I would like to suggest using the latter term. I would define it as follows: - A link establishment has occurred when a mobile node becomes able to send a packet to the access router This does NOT say that the mobile node is REQUIRED to send a layer-3 packet before the link is established -- only that it _could_ send a layer-3 packet. Then, my definitions about reactive vs. predictive/proactive context transfer initiation are equally precise. > I think the drafts approach is better FOR NOW since, we have not completed > the frame work discussion yet (we did have a discussion about Mobility > framework, and I did ask the question of whether the scope is Mobile IP > or not, of the very same reason). Basing the definitions on link establishment avoids completely any questions about Mobile IP. > When you don't know what your underlying layer 2 technology or your > Layer 3 mobility baseline is, then you have to speak in common, general > terms, such as packet arrival. Even packet arrival is quite susceptible to ambiguity: - Is it that a packet arrived, or that it MIGHT have arrived? - What packet is it that arrived? - Did it arrive at the mobile node, the previous access router, or the new access router? > Start of CT can be based on all kinds of things: > Example From Mobile IP fast handover perspective: > 1-Solicitation for proxy router > 2-Binding update > 3-Neighbor advertisement from Mobile The Mobile IP fast handover allows layer-2 triggers also. > Example From a link layer perspective > 1-Pilot beacon/ signal strenght measurement > 2-RLC/P/ RNC scheduler directive > 3-Mobility management unit > ...... > >From a CNP network that is doing more advance next router discovery > there could be other types of signals, especially for proactive, > you are understimating the beyond 3G scenarios. > > So which CT trigger do you want to pick? > > Earlier trigger + less amount context + higher AR-AR bandwith > leads to a faster CT (more chance for proactive). > A slow handover solution (base Mobile IP) waits for L2 HO completion and > then starts L3 signaling, a faster handover solution starts earlier. Of course everyone wants to have reliable predictive handovers. But for systems that cannot fit within that design parameter it would still be nice to have fast reactive handovers. It is not a fair criticism of reactive handover to insist that proactive is better. And similarly for reactive context transfer. > So we are talking about a race condition between CT and HO if > we don't know the details of the system, so we base > the definition on CT completion and that is why we > simply say, if the CT is done prior to packet arrival, then > it is proactive, if not it is reactive. I still think this is questionable, given my objections above to the notion of "packet arrival". > two months ago, I was screaming for an event sequence out of > the handoveer procedure for timing requirement, > I suggested to define CT triggers and CT deadline based on the > event sequence First, the deadline for various kinds of context transfer will be different. Secong, the context transfer protocol might be definable without regard to the specific kind of trigger. For layer-2 triggers, this seems pretty clear! > ****Unless you offer a clear event sequence and show different Handover > stages and the need of packet delivery for various feature context, > I don't think we can change our definition and base it on an start > event.***** I'm not sure if my example would be welcome, but here goes anyway: 1) Mobile node shows up at new access router (802.11, say) 2) Mobile node asks new access router to collect context from previous router. Mobile includes authentication data that can be checked by previous access router. 3) New access router sends request for context transfer to previous router. 4) Previous access router checks the authentication data, and upon approval delivers the requested context features 5) New access router installs the delivered context features, and (optionally) notifies the mobile node about the status. This is reactive, and it could be very valuable for certain kinds of context. > As I said in my other email: > It seems you are questioning the usefulness of CT and its role > on the timing of the events, if you think the packets can be > delivered and then you establish HC context and re-negotiate authentication > and other things, then why is CT timing so critical, you are contradicting > yourself. I'm really puzzled by this question. There is a certain time budget (say, as defined by the VoIP parameters). It would be nice to have the fastest possible context transfer in order to remain within that time budget. It's easier to do so with proactive context transfer. It's still possible to do so with reactive context transfer. Not all systems will support proactive context transfer. Am I missing the point of your question?? Regards, Charlie P. From owner-seamoby@diameter.org Thu Jun 21 17:04: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 RAA17792 for ; Thu, 21 Jun 2001 17:04:27 -0400 (EDT) Received: (qmail 13356 invoked by alias); 21 Jun 2001 20:47:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13350 invoked by uid 200); 21 Jun 2001 20:47:46 -0000 Received: (qmail 13345 invoked from network); 21 Jun 2001 20:47:44 -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; 21 Jun 2001 20:47:44 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5LKvv024953 for ; Thu, 21 Jun 2001 16:57:57 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 21 Jun 2001 16:58:03 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 16:58:05 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 16:58:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA94.DC4950B0" 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_01C0FA94.DC4950B0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: I'll try to think of some new wording. I'd appreciate it if anyone else had a suggestion. Just to be clear, I am not sure exactly how Pat wants us to resolve the issues posted, but I will not be make changes to the requirements until their is a clear consensus capture on the www page (I think that's how its supposed to happen). This includes issues I might have with the current wg doc ;^} . Cheers, Gary Some questions/comments below: > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Thursday, June 21, 2001 4:29 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > Gary Kenward wrote: > > > > > > > > > > > Rajeev: The benefit is a clear starting point for the CT > > > process. (i.e., > > > when to initiate CT) > > > > True enough, but the problem is that it is an event that happens too > > late. > > Certainly, for some networks, this may be the only handover > event that > > > > is visible at L3. But, for many networks, there are L2 triggers, and > > mobility > > events that can be forwarded to CT. > > > > In this sense, the definition you have provided is too limited. > > Perhaps > > the answer is to define another phase. I have no real ideas > on this at > > the > > moment: how about proactive, reactive and panic ;^} > > > > Rajeev: Given that you agree (at least partially) that in > some networks, > (or "inter-networks") IP message after the link is established is the > only way you could request CT, I would argue that the current > definition, which is based on L2 triggers and "mobility > events", is too > limited. It is ironic that we are debating whether to use IP messaging > to request CT once the link is established.. I agree that there is one requirement that implies that all triggers are originated at L2. This needs to be fixed. It was never intended that way. (It's the requirement to "hide" the specifics of an L2 trigger). I think I'll post a rewording for that requirement to make it more neutral, ok? > > > > > > Rajeev: The offered definition does not say anything > about how long > > > context transfer takes place. The _start_ of CT request is > > > the issue. A > > > packet arrives at the new AR (e.g., a MN request for CT), there is > > no > > > context there, then you fetch it. > > > > Ok. How CT starts is important. But as important is when it > finishes. > > Indeed, it is more important to me, as I see too little value in ct > > that > > finishes after 3 or 4 packets have been forwarded. I want ct to make > > real-time > > handovers opaque to the end-user. > > > > > > Rajeev: While I don't necessarily agree with the example, we all want > CT to finish before the packets start arriving. That's why we have > predictive handovers. When you can't do such a thing, e.g., consider > that link-layer triggers don't work because the two technologies are > different, you have the initiation of reactive CT after the MN > establishes a new link. I definitely believe this can happen. I am aiming for the requirements to be inclusive. I also don't see how the above has much to do with the first packet arrival at the new AR. It seems to have more to do with an MN initiated L3 trigger, correct? > > > > > > If the context is not in place for the first packet forwarding, > > then > > > > the transfer is reactive; meaning that at this point, > the goal is > > to > > > > complete the transfer as fast as possible to minimize > the delay in > > > > > > forwarding that first packet. > > > > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > > > But this is in the current requirements. It just doesn't say that > > reactive > > starts with the first packet forwarding, accounting for the > fact that > > in some > > networks, reactive mode can occur before that event. > > > > Rajeev: Is it possible to re-word it such that it takes care of the > issue we have raised ? Can we say that reactive CT takes place as a > consequence of MN establishing a new link ? > This would be sufficient. Well, we could, but I'm unclear as to why you don't see that with the current requirements (at least once the problem with the L2 requirement is fixed). Everyone appears to agree that the origin of the triggers is not important, as long as the trigger manifests itself at L3 (probable as a control message) and has certain, as yet unspecified characteristics). The scenario you describe above could be resolved with either an L2 initiated trigger or an MN initiated trigger, could it not? If you were thinking of the trigger being the first IP data packet from the MN to hit the new AR, then that's fine (it may be a little late) - the new AR would simply have to filter incoming packets. There's big questions about what would happen next, but that's solution space. > > > > > > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, > > or > > > > I fail to meet the goal of being proactive. > > > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > > > It seems to me that the only part that we disagree on is what > > indicates that "reactive mode" is occurring. > > > > Rajeev: Yes, and some text along the above lines would do it. > > Regards, > > -Rajeev > > > > > > > > > > Regards, > > > > Onwards and upwards, > > Gary > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > > To: seamoby@cdma-2000.org > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are > > missing. > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > Section: 4.5 > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > The section provides the description of proactive and reactive > > > > > CT without properly defining what they are. We need the > > > definitions. > > > > > > > > > > > > > > Requested Change: > > > > > > > > > > Reactive CT: The context transfer process which takes place > > > > subsequent > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > context transfer > > > > > process in which the required contexts are in place at > > > the target AR > > > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0FA94.DC4950B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] proactive and reactive CT definitions

Rajeev:

I'll try to think of some new wording. I'd appreciate = it if
anyone else had a suggestion.

Just to be clear, I am not sure exactly how Pat wants = us to
resolve the issues posted, but I will not be make = changes to
the requirements until their is a clear consensus = capture on
the www page (I think that's how its supposed to = happen). This
includes issues I might have with the current wg doc = ;^} .

Cheers,
Gary

Some questions/comments below:

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]<= /FONT>
> Sent: Thursday, June 21, 2001 4:29 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] proactive and reactive = CT definitions
>
>
> Gary Kenward wrote:
>
> >
> >
> > >
> > > Rajeev: The benefit is a clear = starting point for the CT
> > > process. (i.e.,
> > > when to initiate CT)
> >
> > True enough, but the problem is that it is = an event that happens too
> > late.
> > Certainly, for some networks, this may be = the only handover
> event that
> >
> > is visible at L3. But, for many networks, = there are L2 triggers, and
> > mobility
> > events that can be forwarded to CT.
> >
> > In this sense, the definition you have = provided is too limited.
> > Perhaps
> > the answer is to define another phase. I = have no real ideas
> on this at
> > the
> > moment: how about proactive, reactive and = panic ;^}
> >
>
> Rajeev: Given that you agree (at least = partially) that in
> some networks,
> (or "inter-networks") IP message = after the link is established is the
> only way you could request CT, I would argue = that the current
> definition, which is based on L2 triggers and = "mobility
> events", is too
> limited. It is ironic that we are debating = whether to use IP messaging
> to request CT once the link is = established..

I agree that there is one requirement that implies = that all triggers are originated at L2. This needs to be fixed. It was = never intended that way.

(It's the requirement to "hide" the = specifics of an L2 trigger).

I think I'll post a rewording for that requirement to = make it more neutral,
ok?

>
> >
> > > Rajeev: The offered definition does = not say anything
> about how long
> > > context transfer takes place. The = _start_ of CT request is
> > > the issue. A
> > > packet arrives at the new AR (e.g., a = MN request for CT), there is
> > no
> > > context there, then you fetch = it.
> >
> > Ok. How CT starts is important. But as = important is when it
> finishes.
> > Indeed, it is more important to me, as I = see too little value in ct
> > that
> > finishes after 3 or 4 packets have been = forwarded. I want ct to make
> > real-time
> > handovers opaque to the end-user.
> >
> >
>
> Rajeev: While I don't necessarily agree with = the example, we all want
> CT to finish before the packets start arriving. = That's why we have
> predictive handovers. When you can't do such a = thing, e.g., consider
> that link-layer triggers don't work because the = two technologies are
> different, you have the initiation of reactive = CT after the MN
> establishes a new link.

I definitely believe this can happen. I am aiming for = the requirements to be inclusive. I also don't see how the above has = much to do with the first packet

arrival at the new AR. It seems to have more to do = with an MN initiated L3 trigger, correct?

>
>
> > > > If the context is not in place = for the first packet forwarding,
> > then
> > > > the transfer is reactive; = meaning that at this point,
> the goal is
> > to
> > > > complete the transfer as fast as = possible to minimize
> the delay in
> >
> > > > forwarding that first = packet.
> > > >
> > >
> > > Rajeev: Exactly. This is what I am = proposing to be added.
> >
> > But this is in the current requirements. = It just doesn't say that
> > reactive
> > starts with the first packet forwarding, = accounting for the
> fact that
> > in some
> > networks, reactive mode can occur before = that event.
> >
>
> Rajeev: Is it possible to re-word it such that = it takes care of the
> issue we have raised ? Can we say that reactive = CT takes place as a
> consequence of MN establishing a new link = ?
> This would be sufficient.

Well, we could, but I'm unclear as to why you don't = see that with the current requirements (at least once the problem with = the L2 requirement is fixed). Everyone appears to agree that the origin = of the triggers is not important, as long as the trigger manifests = itself at L3 (probable as a control message) and has certain, as yet = unspecified characteristics).

The scenario you describe above could be resolved = with either an L2 initiated trigger or an MN initiated trigger, could = it not?

If you were thinking of the trigger being the first = IP data packet from the MN to hit the new AR, then that's fine (it may = be a little late) - the new AR would simply have to filter incoming = packets. There's big questions about what would happen next, but that's = solution space.

>
> >
> > >
> > > >
> > > > Reactive CT is when I either = choose not to perform proactive CT,
> > or
> > > > I fail to meet the goal of being = proactive.
> > >
> > > Rajeev: Agreed.  Can we add the = text then ? What do others think ?
> >
> > It seems to me that the only part that we = disagree on is what
> > indicates that "reactive mode" = is occurring.
> >
>
> Rajeev: Yes, and some text along the above = lines would do it.
>
> Regards,
>
> -Rajeev
>
>
> >
> > >
> > > Regards,
> >
> > Onwards and upwards,
> > Gary
> >
> > >
> > > -Rajeev
> > >
> > >
> > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]<= /FONT>
> > > > > Sent: Wednesday, June 20, = 2001 2:49 PM
> > > > > To: = seamoby@cdma-2000.org
> > > > > Subject: [seamoby] = proactive and reactive CT definitions
> > > > >
> > > > >
> > > > >
> > > > > Description of issue = :Clear, unambiguous definitions are
> > missing.
> > > > >
> > > > > Submitter name: Rajeev = Koodli
> > > > >
> > > > > Submitter email address: = rajeev@iprg.nokia.com
> > > > >
> > > > > Date first submitted: June = 20, 2001
> > > > >
> > > > > Comment type: = 'T'echnical
> > > > >
> > > > > Priority:  ''S'/MUST = fix
> > > > >
> > > > > Section:  4.5
> > > > >
> > > > > Rationale/Explanation of = issue:
> > > > >
> > > > > The section provides the = description of proactive and reactive
> > > > > CT without properly = defining what they are. We need the
> > > definitions.
> > > >
> > > > >
> > > > > Requested Change:
> > > > >
> > > > > Reactive CT: The context = transfer process which takes place
> > > > subsequent
> > > > > to arrival of a MN's packet = at the target AR
> > > > >
> > > > > Proactive (I prfer = Charlie's Predictive better) CT: The
> > > > > context transfer
> > > > > process in which the = required contexts are in place at
> > > the target AR
> > > >
> > > > > prior to the arrival of = MN's packet at target AR.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C0FA94.DC4950B0-- From owner-seamoby@diameter.org Thu Jun 21 17:19:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18097 for ; Thu, 21 Jun 2001 17:19:44 -0400 (EDT) Received: (qmail 13874 invoked by alias); 21 Jun 2001 21:07:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13868 invoked by uid 200); 21 Jun 2001 21:07:06 -0000 Received: (qmail 13863 invoked from network); 21 Jun 2001 21:07:04 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 21:07:04 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA26032 for ; Thu, 21 Jun 2001 14:18:04 -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 OAA27021 for ; Thu, 21 Jun 2001 14:18:04 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 16:18:04 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , Gary Kenward Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Thu, 21 Jun 2001 16:17: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 Rajeev: While I don't necessarily agree with the example, we all want CT to finish before the packets start arriving. That's why we have predictive handovers. When you can't do such a thing, e.g., consider that link-layer triggers don't work because the two technologies are different, you have the initiation of reactive CT after the MN establishes a new link. Ajoy: I thought some more about inter-technolgy CT. It seems the inter-technolgy CT may be difficult to realize. For example, one access network might use PPP while others might not. In this case, will it make sense to transfer the PPP context from one access router to other? Additionally, I think most of us agree that make before break handover is possible in inter-technolgy case, when some overlap is available between coverage area of different technolgies. So Can't MN re-negotiate CT with new AR before breaking connection with oldAR ? regards, ajoy -----Original Message----- From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] Sent: Thursday, June 21, 2001 3:29 PM To: Gary Kenward Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Gary Kenward wrote: > > > > > > Rajeev: The benefit is a clear starting point for the CT > > process. (i.e., > > when to initiate CT) > > True enough, but the problem is that it is an event that happens too > late. > Certainly, for some networks, this may be the only handover event that > > is visible at L3. But, for many networks, there are L2 triggers, and > mobility > events that can be forwarded to CT. > > In this sense, the definition you have provided is too limited. > Perhaps > the answer is to define another phase. I have no real ideas on this at > the > moment: how about proactive, reactive and panic ;^} > Rajeev: Given that you agree (at least partially) that in some networks, (or "inter-networks") IP message after the link is established is the only way you could request CT, I would argue that the current definition, which is based on L2 triggers and "mobility events", is too limited. It is ironic that we are debating whether to use IP messaging to request CT once the link is established.. > > > Rajeev: The offered definition does not say anything about how long > > context transfer takes place. The _start_ of CT request is > > the issue. A > > packet arrives at the new AR (e.g., a MN request for CT), there is > no > > context there, then you fetch it. > > Ok. How CT starts is important. But as important is when it finishes. > Indeed, it is more important to me, as I see too little value in ct > that > finishes after 3 or 4 packets have been forwarded. I want ct to make > real-time > handovers opaque to the end-user. > > Rajeev: While I don't necessarily agree with the example, we all want CT to finish before the packets start arriving. That's why we have predictive handovers. When you can't do such a thing, e.g., consider that link-layer triggers don't work because the two technologies are different, you have the initiation of reactive CT after the MN establishes a new link. > > > If the context is not in place for the first packet forwarding, > then > > > the transfer is reactive; meaning that at this point, the goal is > to > > > complete the transfer as fast as possible to minimize the delay in > > > > forwarding that first packet. > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > But this is in the current requirements. It just doesn't say that > reactive > starts with the first packet forwarding, accounting for the fact that > in some > networks, reactive mode can occur before that event. > Rajeev: Is it possible to re-word it such that it takes care of the issue we have raised ? Can we say that reactive CT takes place as a consequence of MN establishing a new link ? This would be sufficient. > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, > or > > > I fail to meet the goal of being proactive. > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > It seems to me that the only part that we disagree on is what > indicates that "reactive mode" is occurring. > Rajeev: Yes, and some text along the above lines would do it. Regards, -Rajeev > > > > > Regards, > > Onwards and upwards, > Gary > > > > > -Rajeev > > > > > > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are > missing. > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > Comment type: 'T'echnical > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > Section: 4.5 > > > > > > > > Rationale/Explanation of issue: > > > > > > > > The section provides the description of proactive and reactive > > > > CT without properly defining what they are. We need the > > definitions. > > > > > > > > > > > Requested Change: > > > > > > > > Reactive CT: The context transfer process which takes place > > > subsequent > > > > to arrival of a MN's packet at the target AR > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > context transfer > > > > process in which the required contexts are in place at > > the target AR > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 17:29: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 RAA18268 for ; Thu, 21 Jun 2001 17:29:01 -0400 (EDT) Received: (qmail 14353 invoked by alias); 21 Jun 2001 21:14:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14347 invoked by uid 200); 21 Jun 2001 21:14:37 -0000 Received: (qmail 14342 invoked from network); 21 Jun 2001 21:14:35 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 21:14:35 -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 OAA10722; Thu, 21 Jun 2001 14:25:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LLP5C22829; Thu, 21 Jun 2001 14:25:05 -0700 X-mProtect: Thu, 21 Jun 2001 14:25:05 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9sWvEm; Thu, 21 Jun 2001 14:22:22 PDT Message-ID: <3B326566.414D08D2@iprg.nokia.com> Date: Thu, 21 Jun 2001 14:21:42 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@cdma-2000.org Subject: [seamoby] Re: CT trigger or CT completion? was: proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DE0@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 Madjid, I have some comments below. I hope it is sufficient to reply to this e-mail alone (since you pointed to this one in the other e-mail). Regards, -Rajeev Nakhjiri Madjid-MNAKHJI1 wrote: > Rajeev, > > I think, I know what the problem is: > The draft bases the definition of Proactive and reactive on > when the handover (packet arrival) COMPLETE S. > You, on the other hand, are basing you definition on the START > of CT, i.e. CT trigger. > I think the drafts approach is better FOR NOW since, we have not completed > the frame work discussion yet (we did have a discussion about Mobility > framework, and I did ask the question of whether the scope is Mobile IP > or not, of the very same reason). > When you don't know what your underlying layer 2 technology or your > Layer 3 mobility baseline is, then you have to speak in common, general > terms, such as packet arrival. > Rajeev: Do we _need_ to know what the underlying L2 technology is for our purpose here ? I would hope not. CT must work across all L2 technologies. In some networks, you could make use of L2 triggers; that does not mean that we need to know them and base our definitions (only) on them. Regarding L3 mobility baseline: it would help to know it. However, I would argue that it is not needed for the reactive CT definition. What if we use Charlie's suggestion that reactive CT happens once the MN establishes a new link ? This does not depend on any L3 mobility baseline. > Start of CT can be based on all kinds of things: > Example From Mobile IP fast handover perspective: > 1-Solicitation for proxy router > 2-Binding update > 3-Neighbor advertisement from Mobile > Example From a link layer perspective > 1-Pilot beacon/ signal strenght measurement > 2-RLC/P/ RNC scheduler directive > 3-Mobility management unit > Rajeev: As I said in the last sentence above, we could simply say that reactive CT takes place after the MN establishes a new link. No L2 idiosyncracies, no dependence on L3 mobility mechanism. > ...... > >From a CNP network that is doing more advance next router discovery > there could be other types of signals, especially for proactive, > you are understimating the beyond 3G scenarios. > > So which CT trigger do you want to pick? > Earlier trigger + less amount context + higher AR-AR bandwith > leads to a faster CT (more chance for proactive). > A slow handover solution (base Mobile IP) waits for L2 HO completion and > then starts L3 signaling, a faster handover solution starts earlier. > > So we are talking about a race condition between CT and HO if > we don't know the details of the system, so we base > the definition on CT completion and that is why we > simply say, if the CT is done prior to packet arrival, then > it is proactive, if not it is reactive. > Rajeev: I can see the race conditions if you don't specify the start epoch clearly. If you agree that doing CT _after_ packet arrival is reactive, we are in agreement! > > two months ago, I was screaming for an event sequence out of > the handoveer procedure for timing requierement, > I suggested to define CT triggers and CT deadline based on the > event sequence > I asked YOU for a HC based CT deadline event, I don't remember you offering > any? Rajeev: Oops, you can take it that it was unintentional. With so much e-mail load, I hope you would symphathize! Anyway, do you think that this is still important ? I think that base definitions would suffice for the moment. > > I also suggested that we would prioritize features and > then set a halfway CT deadline for reactive, so that by that deadline > only the time critical feature contexts are through and again used HC > as example. > > So why are we in a different situation now? > > ****Unless you offer a clear event sequence and show different Handover > stages and the need of packet delivery for various feature context, > I don't think we can change our definition and base it on an start > event.***** > Rajeev: Well, it appears that this is an important issue to you as well. My suggestion is that we provide basic defintions in the requirements draft. And, we could state the defintions based on whether CT is initiated while the MN still has the link with the old AR or it is initiated after the MN establishes a new link with new AR. That should suffice. If you insist that we need to provide the event sequence, I would be happy to provide them from CT framework draft we submitted for SD IETF. > > ****Furthermore, I think Kulwinder issue #2 covers this aspect. > Unless you want to > > As I said in my other email: > It seems you are questioning the usefulness of CT and its role > on the timing of the events, if you think the packets can be > delivered and then you establish HC context and re-negotiate authentication > and other things, then why is CT timing so critical, you are contradicting > yourself. > Rajeev: I am not questioning the usefulness of CT. I am trying to provide better definitions that would make it feasible to implement it on any L2 network. I hope it is ok to claim that it is a useful purpose. We clearly agree that predictive CT would try to place contexts before the packet arrival at new AR. When this is not possible to achieve, you have to fallback on obtaining the contexts once the MN attaches to the new AR. In any _generic_ network topology, you cannot assume that L2 handover events/triggers would help us accomplish CT. And, we are chartered to develop CT without assuming specific L2 support (NOTE: this does not mean that you don't make use of L2 assistance). So, when predictive is not possible, doing reactive CT could mean a performance hit. That does not mean contradiction; it is stating the fact! As I have said in few e-mails now, when there are no contexts at new AR, what do you ? 1. fetch contexts. The signaling could already have started. Until the contexts arrive, what do you do with the packets? 2. re-establish contexts. Until the contexts are re-established, what do you do with the packets ? In both 1 and 2, you could drop them or forward them without treating them with the feature contexts. The choice is up to you. We know that there is value in forwarding the packet or buffering it. In any case, I don't see any contradiction! > > Regards, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, June 20, 2001 5:11 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > I still don't know whether I should respond to these issues or not, > > but it seems that is the going trend. > > > > Rajeev: It's a good going trend to straighten things out. > > > > > For Proactive, your definition works, and actually it is the same > > as in the draft. > > > > I think this definition of reactive is going backward a bit. > > We did discuss this issue at length and I think you were in agreement that > > reactive CT, does not always mean that CT cannot start until after the > MN's > > packets have arrived. > > > > Rajeev: Reactive CT means that there is no context at the new AR when MN's > packets arrive. If we want to do CT, I would think that that's a good time > to > start. > Going by your argument, when do you start a reactive CT ? If we both agree > that > there is no context in place when the MN's packets arrive, what do you do ? > If > you had started CT before, that's proactive, but not working very well. > Claiming that reactive CT is the "proactive CT gone bad" is extremely poor > definition. I don't believe that I agreed at all to such a definition. > Please > enlighten me! > > > > > For reactive, CT can happens simultaneous as Handover signaling > > but it might not finish when handover signaling is complete. > > Rajeev: Where is this definition ? This can take another avatar of its own > :-) > > > > > > > What you are suggesting, means that you don't need CT to deliver > > packets the mobile and are totally moving CT out of the critical > > path for timing. I guess say for header compression > > it means that the newAR does not have HC states for a while, > > assuming it can receive uncompressed packets, > > But would this work for security and authentication, I don't think so. > > > > Rajeev: If the context is not present when the MN's packet arrive, you try > to > get it. Right ? Why is that not reactive CT ? If CT is not there, and while > I try to fetch it, why can't I forward the packets if it is possible ? If > I *don't* forward packets, what do I do ? Drop them ? How's that good for > TCP/RTP's performance ? Consider the ability to send and receive normal IP > packets as a service (aka connectivity) upon which the rest of the CT > features > are based. > > For HC, you could forward on downlink. For security, you could forward the > packets in both the directions until you receive the appropriate contexts. > You > may not have a packet *treated* with require feature, but you can still > forward > packets. If CT fails all together, what do you do ? You could require the MN > to > re-authenticate itself. How do you do that ? You need connectivity to send > and > receive IP packets. > In a nut shell, if there are no contexts, you can always go fetch them *or* > require the MN to re-establish them. > > > > > I like the current definition for reactive: > > "doing CT when handover is imminent" and that means that oldAR or > > newAR are already engaged in handover signaling, now this could be > > a L2 trigger that newAR has received or a HI or something else, but > > it does not mean completion of handover signaling and packet routing > > change. > > > > Rajeev: When would you start CT in this case ? When does new AR receive L2 > trigger ? Is it trying to do CT when it receives a HI ? > > I understand that when a packet arrives at new AR, the CT may be already "in > progress", as indicated by the signaling that has taken place. The new AR > may > *still* initiate CT signaling and the old AR must be able to handle requests > that come in sequence. It is called "idempotent" operation. > > Regards, > > -Rajeev > > > > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 20, 2001 1:49 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] proactive and reactive CT definitions > > > > Description of issue :Clear, unambiguous definitions are missing. > > > > Submitter name: Rajeev Koodli > > > > Submitter email address: rajeev@iprg.nokia.com > > > > Date first submitted: June 20, 2001 > > > > Comment type: 'T'echnical > > > > Priority: ''S'/MUST fix > > > > Section: 4.5 > > > > Rationale/Explanation of issue: > > > > The section provides the description of proactive and reactive > > CT without properly defining what they are. We need the definitions. > > > > Requested Change: > > > > Reactive CT: The context transfer process which takes place subsequent > > to arrival of a MN's packet at the target AR > > > > Proactive (I prfer Charlie's Predictive better) CT: The context transfer > > process in which the required contexts are in place at the target AR > > prior to the arrival of MN's packet at target AR. From owner-seamoby@diameter.org Thu Jun 21 17:40: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 RAA18509 for ; Thu, 21 Jun 2001 17:40:12 -0400 (EDT) Received: (qmail 14847 invoked by alias); 21 Jun 2001 21:27:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14841 invoked by uid 200); 21 Jun 2001 21:27:50 -0000 Received: (qmail 14834 invoked from network); 21 Jun 2001 21:27:48 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 21:27:48 -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 OAA11632; Thu, 21 Jun 2001 14:38:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LLcIZ11428; Thu, 21 Jun 2001 14:38:18 -0700 X-mProtect: Thu, 21 Jun 2001 14:38:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdnawD2P; Thu, 21 Jun 2001 14:38:16 PDT Message-ID: <3B326949.3D41327A@iprg.nokia.com> Date: Thu, 21 Jun 2001 14:38:17 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: Gary Kenward , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > Rajeev: While I don't necessarily agree with the example, we all want > CT to finish before the packets start arriving. That's why we have > predictive handovers. When you can't do such a thing, e.g., consider > that link-layer triggers don't work because the two technologies are > different, you have the initiation of reactive CT after the MN > establishes a new link. > > Ajoy: I thought some more about inter-technolgy CT. It seems > the inter-technolgy CT may be difficult to realize. For > example, one access network might use PPP while others > might not. In this case, will it make > sense to transfer the PPP context from one access router to > other? Rajeev: probably not. But what's your point beyond that ? > Additionally, I think most of us agree that make before > break handover is possible in inter-technolgy case, when > some overlap is available between coverage area of > different technolgies. Rajeev: May be. May be not. I guess the point is can we depend on such things for all the networks for which we want an IP-based mechanism to work. The basic design principle should be to get the protocol to work on all the link layers while allowing for link-specific optimizations, and not the other way around (i.e., to design the protocol based on what is available in some links that we are familiar with). > So Can't > MN re-negotiate CT with new AR before breaking > connection with oldAR ? > Rajeev: If the MN has link connectivity with the new AR and can send a message, yes. Alternatively, it could use its existing link with the old AR (proactive/predictive CT). Regards, -Rajeev > > regards, > ajoy > From owner-seamoby@diameter.org Thu Jun 21 18:04: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 SAA18940 for ; Thu, 21 Jun 2001 18:04:54 -0400 (EDT) Received: (qmail 15387 invoked by alias); 21 Jun 2001 21:52:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15381 invoked by uid 200); 21 Jun 2001 21:51:59 -0000 Received: (qmail 15376 invoked from network); 21 Jun 2001 21:51:58 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 21:51:58 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 18:02:23 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8057@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Thu, 21 Jun 2001 18:02:23 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 21, 2001 12:38 PM > To: 'Mark Smith'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > Mark, > > Well, it seems like we are going with ARs (which I like). > > I don't know much about MRs and Manet, however I think AR has a more > precise scope than FN. Does AR imply that the router cannot be mobile? > i.e. MR cannot be a subset of AR? > > I don't care too much about the physical or software > definition of a node > as Kulwinder described (although, from the implementation point, it is > important :) > I care about the functionality. > For the neutralness in this discussion I use my own favorite > term CT peer > instead of FN or AR. > > Now, But To answer your question:: > of course if the node offering CT is mobile, it makes > a lot of difference, > 1-how would you handle the security associations for > pre-authentication between CT peers, if the CT peer is mobile? How is this issue different than the MN being mobile? If the CT is aggreated by a device that appears to the network as an large MN how does the network know that the IP stream is for one physical device, or multiple physical devices? Why should it care as long as the 'root MN' has a valid security association that establishes a _Chain_Of_Trust_ to the terminal MN? If we can do partial Context transfer, how will the network actually know that there are two physical devices instead of one as far as CT is concerned? If it does know do you not think this knowledge would best be modularized and handled by a Mobile Router Protocol/AR Discovery Protocol? > 2-How would you handle the associations in case you are using > a transport protocol like SCTP? This is a Mobile Router Protocol issue. This begs the need for a Mobile Router Protocol that does route aggregation using IPv6 subnet prefixes. > 3- The context also needs to be available at the CT peer prior > to the CT, so whatever network element that wants to make sure > CT peer has enough supply for the next CT, needs to track the > CT peer to feed it. Enough supply of what? Bandwidth? This is an AR Discovery issue. If the AR Discovery Protocol is based on triggers I don't see where the problem is. -Kulwinder. > > These are problems that do need a WHOLE lot of consideration when the > CT peer is mobile. > > Madjid > > -----Original Message----- > From: Mark Smith [mailto:mark.smith@comdev.cc] > Sent: Wednesday, June 20, 2001 3:57 PM > To: seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > Thank you, yes, that summarizes quite nicely what I was trying to say. > > I'm not trying to say that this isn't a problem, I'm asking if anyone > can see why it would be. I can't, but I don't claim to be > all knowing. :) > > -Mark > > Kulwinder Atwal wrote: > > > To expand on Mark's comment: > > > > If we think of an AR or MN as a software > thread/task/process with its own > AR > > context/MN context, instead of physical devices, then we > should be able to > > keep the terms AR and MN seperate. > > > > 1. A physical device may have just the AR task running, in > which case it > is > > only an AR. > > > > 2. A physical device may have just the MN task running, in > which case it > is > > only an MN. > > > > 3. A physical device may have a MN task and an AR task > running in which > case > > it is both, but the functionality is modularized. > > > > With the AR discovery protocol is possible to learn in a mobile > environment > > which mobile device nearby has an AR task running before > attempting CT. > > > > - Kulwinder. > > > > > >>-----Original Message----- > >>From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > >>Sent: Wednesday, June 20, 2001 3:06 PM > >>To: Mark Smith > >>Cc: seamoby@cdma-2000.org > >>Subject: Re: [seamoby] Issue 1: Change access network terminology > >> > >> > >> > >>Perhaps I am missing something.. Aren't we concerned about > >>the "entity" which offers > >>different features (QoS, HC,..) ? I guess we went with AR > >>because that's the entity > >>that typically offers the features. > >> > >>Regards, > >> > >>-Rajeev > >> > >> > >>Mark Smith wrote: > >> > >> > >>>I guess my question is, does it matter if a Forwarding Node > >>> > >>(as Gary has > >> > >>>defined them) is also a Mobile Node? What effect does it > >>> > >>have on our > >> > >>>design/requirement/problem statement? > >>> > >>>I think the idea is that, for the sake of a particular CTP > >>> > >>session, a > >> > >>>node is either an MN or an FN. If it's an FN for this CTP > >>> > >>session, it > >> > >>>may be an MN for another session, but those two sessions > >>> > >>are independant > >> > >>>of each other and should be viewed as such. > >>> > >>>-Mark > >>> > >>>Pat Calhoun wrote: > >>> > >>> > >>>>On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > >>>> > >>>> > >>>>>If we do this (which would be find for me, regardless of > >>>>> > >>what my last > >> > >>>>>post said :), make sure we define it to address Phil's > >>>>> > >>requests. I > >> > >>>>>think if we were to specify that an AR, in our case, is > >>>>> > >>not neccessarily > >> > >>>>>a fixed, wired device, that it can, infact, be an MN > >>>>> > >>itself, that should > >> > >>>>>do the trick. > >>>>> > >>>>>Whatever we call it, it should be defined. > >>>>> > >>>>> > >>>>yes, you posts crossed each other :) > >>>> > >>>>Well, if a CT peer can be an MN, then the use of AR is > >>>> > >>clearly innapropriate. > >> > >>>>AR is an access router, and this is typically where I see > >>>> > >>CT being used, but > >> > >>>>I understand that there are others, such as Phil, that > >>>> > >>see CT as having many > >> > >>>>other uses. > >>>> > >>>>Perhaps we should first have someone open an issue on > >>>> > >>whether an MN can in fact > >> > >>>>be a CT peer, and the result of that issue would dictate > >>>> > >>the future of this one. > >> > >>>>PatC > >>>> > >>>> > From owner-seamoby@diameter.org Thu Jun 21 18:15: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 SAA19053 for ; Thu, 21 Jun 2001 18:14:57 -0400 (EDT) Received: (qmail 15868 invoked by alias); 21 Jun 2001 22:02:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15862 invoked by uid 200); 21 Jun 2001 22:02:35 -0000 Received: (qmail 15857 invoked from network); 21 Jun 2001 22:02:33 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 22:02:33 -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 PAA14511; Thu, 21 Jun 2001 15:13:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LMD3X04816; Thu, 21 Jun 2001 15:13:03 -0700 X-mProtect: Thu, 21 Jun 2001 15:13:03 -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 smtpdpWV3u2; Thu, 21 Jun 2001 15:13:02 PDT Message-ID: <3B32716F.323E7BB7@iprg.nokia.com> Date: Thu, 21 Jun 2001 15:13:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Singh Ajoy-ASINGH1 CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Singh Ajoy-ASINGH1 wrote: > Rajeev: While I don't necessarily agree with the example, we all want > CT to finish before the packets start arriving. That's why we have > predictive handovers. When you can't do such a thing, e.g., consider > that link-layer triggers don't work because the two technologies are > different, you have the initiation of reactive CT after the MN > establishes a new link. It is possible or even likely that some packets could be delivered to the mobile node before the context is transferred, especially in the reactive case but not necessarily only there. For example, given proactive, what if the mobile node starts doing DAD at the new access router before the context transfer completes? This would be quite possible, and I would hate to see the context transfer protocol place any restrictions otherwise. Obviously, if DAD is needed, it would be silly to delay its initiation, even for proactive. If, instead, you want to make the definition that this isn't "pro-active enough", then I would claim that the need for redefinition exhibits the problem with even the general thrust of the existing definitions. > Ajoy: I thought some more about inter-technolgy CT. It seems > the inter-technolgy CT may be difficult to realize. For > example, one access network might use PPP while others > might not. In this case, will it make > sense to transfer the PPP context from one access router to > other? Additionally, I think most of us agree that make before > break handover is possible in inter-technolgy case, when > some overlap is available between coverage area of > different technolgies. So Can't > MN re-negotiate CT with new AR before breaking > connection with oldAR ? Sure this can happen, but if inter-technology context transfer is is available and it saves time, then we should allow it. The benefit will be better customer experience in more cases. Furthermore, I can't see any downside on the protocol design. It doesn't seem to make the problem harder or easier. And I would hate to see PPP context become the defining example for context transfer. Regards, Charlie P. From owner-seamoby@diameter.org Thu Jun 21 18:35: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 SAA19361 for ; Thu, 21 Jun 2001 18:35:55 -0400 (EDT) Received: (qmail 16374 invoked by alias); 21 Jun 2001 22:22:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16368 invoked by uid 200); 21 Jun 2001 22:22:49 -0000 Received: (qmail 16361 invoked by uid 500); 21 Jun 2001 22:22:47 -0000 Date: Thu, 21 Jun 2001 15:22:47 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Message-ID: <20010621152247.B14828@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Rajeev Koodli' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D7B@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: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, Jun 21, 2001 at 04:58:02PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 21, 2001 at 04:58:02PM -0400, Gary Kenward wrote: > Rajeev: > > I'll try to think of some new wording. I'd appreciate it if > anyone else had a suggestion. > > Just to be clear, I am not sure exactly how Pat wants us to > resolve the issues posted, but I will not be make changes to > the requirements until their is a clear consensus capture on > the www page (I think that's how its supposed to happen). This > includes issues I might have with the current wg doc ;^} . well, I am rather confused in this whole thread, but I am trying to catch up. So, do folks generally feel that a change is required? If so, could we get some proposed text that we could sink our teeth into? If there are additional changes that are being proposed, unless they are purely editorial in nature, and MAY cause some commotion, then I think an issue should be opened. Once we agree on the wording (read: proposed text), then we can accept the text and close the issue. So far, I just see some people agreeing to nothing particularly concrete :( PatC > > Cheers, > Gary > > Some questions/comments below: > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Thursday, June 21, 2001 4:29 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > Rajeev: The benefit is a clear starting point for the CT > > > > process. (i.e., > > > > when to initiate CT) > > > > > > True enough, but the problem is that it is an event that happens too > > > late. > > > Certainly, for some networks, this may be the only handover > > event that > > > > > > is visible at L3. But, for many networks, there are L2 triggers, and > > > mobility > > > events that can be forwarded to CT. > > > > > > In this sense, the definition you have provided is too limited. > > > Perhaps > > > the answer is to define another phase. I have no real ideas > > on this at > > > the > > > moment: how about proactive, reactive and panic ;^} > > > > > > > Rajeev: Given that you agree (at least partially) that in > > some networks, > > (or "inter-networks") IP message after the link is established is the > > only way you could request CT, I would argue that the current > > definition, which is based on L2 triggers and "mobility > > events", is too > > limited. It is ironic that we are debating whether to use IP messaging > > to request CT once the link is established.. > > I agree that there is one requirement that implies that all triggers are > originated at L2. This needs to be fixed. It was never intended that way. > (It's the requirement to "hide" the specifics of an L2 trigger). > > I think I'll post a rewording for that requirement to make it more neutral, > ok? > > > > > > > > > > Rajeev: The offered definition does not say anything > > about how long > > > > context transfer takes place. The _start_ of CT request is > > > > the issue. A > > > > packet arrives at the new AR (e.g., a MN request for CT), there is > > > no > > > > context there, then you fetch it. > > > > > > Ok. How CT starts is important. But as important is when it > > finishes. > > > Indeed, it is more important to me, as I see too little value in ct > > > that > > > finishes after 3 or 4 packets have been forwarded. I want ct to make > > > real-time > > > handovers opaque to the end-user. > > > > > > > > > > Rajeev: While I don't necessarily agree with the example, we all want > > CT to finish before the packets start arriving. That's why we have > > predictive handovers. When you can't do such a thing, e.g., consider > > that link-layer triggers don't work because the two technologies are > > different, you have the initiation of reactive CT after the MN > > establishes a new link. > > I definitely believe this can happen. I am aiming for the requirements to be > inclusive. I also don't see how the above has much to do with the first > packet > arrival at the new AR. It seems to have more to do with an MN initiated L3 > trigger, correct? > > > > > > > > > > If the context is not in place for the first packet forwarding, > > > then > > > > > the transfer is reactive; meaning that at this point, > > the goal is > > > to > > > > > complete the transfer as fast as possible to minimize > > the delay in > > > > > > > > forwarding that first packet. > > > > > > > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > > > > > But this is in the current requirements. It just doesn't say that > > > reactive > > > starts with the first packet forwarding, accounting for the > > fact that > > > in some > > > networks, reactive mode can occur before that event. > > > > > > > Rajeev: Is it possible to re-word it such that it takes care of the > > issue we have raised ? Can we say that reactive CT takes place as a > > consequence of MN establishing a new link ? > > This would be sufficient. > > Well, we could, but I'm unclear as to why you don't see that with the > current requirements (at least once the problem with the L2 requirement is > fixed). Everyone appears to agree that the origin of the triggers is not > important, as long as the trigger manifests itself at L3 (probable as a > control message) and has certain, as yet unspecified characteristics). > > The scenario you describe above could be resolved with either an L2 > initiated trigger or an MN initiated trigger, could it not? > > If you were thinking of the trigger being the first IP data packet from the > MN to hit the new AR, then that's fine (it may be a little late) - the new > AR would simply have to filter incoming packets. There's big questions about > what would happen next, but that's solution space. > > > > > > > > > > > > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, > > > or > > > > > I fail to meet the goal of being proactive. > > > > > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > > > > > It seems to me that the only part that we disagree on is what > > > indicates that "reactive mode" is occurring. > > > > > > > Rajeev: Yes, and some text along the above lines would do it. > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > > > Regards, > > > > > > Onwards and upwards, > > > Gary > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > > > To: seamoby@cdma-2000.org > > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are > > > missing. > > > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > > > Section: 4.5 > > > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > The section provides the description of proactive and reactive > > > > > > CT without properly defining what they are. We need the > > > > definitions. > > > > > > > > > > > > > > > > > Requested Change: > > > > > > > > > > > > Reactive CT: The context transfer process which takes place > > > > > subsequent > > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > > context transfer > > > > > > process in which the required contexts are in place at > > > > the target AR > > > > > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 18: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 SAA19427 for ; Thu, 21 Jun 2001 18:40:24 -0400 (EDT) Received: (qmail 16600 invoked by alias); 21 Jun 2001 22:25:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16593 invoked by uid 200); 21 Jun 2001 22:25:14 -0000 Received: (qmail 16582 invoked by uid 500); 21 Jun 2001 22:25:11 -0000 Date: Thu, 21 Jun 2001 15:25:11 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Text to accompany requirement 4.7 Message-ID: <20010621152511.C14828@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D61@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: <9FBD322B7824D511B36900508BF93C9C9F5D61@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jun 20, 2001 at 10:14:41AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk Does anyone object to the editor adding the text below in the requirements spec? Thanks, PatC On Wed, Jun 20, 2001 at 10:14:41AM -0400, Gary Kenward wrote: > Looks good to me. > > Gary > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, June 19, 2001 8:18 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] [Issue] Text to accompany requirement 4.7 > > > > > > > > > > Text to accompany requirement 4.7 > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@eng.sun.com > > Date first submitted: June 19,2001 > > Reference: > > Comment type: E > > Priority: 1 > > Section: 4.7 > > Rationale/Explanation of issue: > > Section 4.7 really needs some justification. > > > > Requested change: > > Add the following text to section 4.7: > > > > " It is believed that if a formal authentication exchange > > (e.g. exchanging > > credentials) were done during the context transfer, the > > computation overhead > > for both the sender and the receiver would cause > > additional and unnecessary > > latency to the handoff process. Therefore, the CT peers > > MUST exchange > > credentials prior to any context transfer." > > > > Proposal: > > Adopt the text above in the -01 version of the requirements spec. > > From owner-seamoby@diameter.org Thu Jun 21 18:48: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 SAA19500 for ; Thu, 21 Jun 2001 18:48:49 -0400 (EDT) Received: (qmail 17344 invoked by alias); 21 Jun 2001 22:37:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17337 invoked by uid 200); 21 Jun 2001 22:37:00 -0000 Received: (qmail 17332 invoked by uid 500); 21 Jun 2001 22:36:58 -0000 Date: Thu, 21 Jun 2001 15:36:58 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] [Issue] Support for Multi-Phase CT Message-ID: <20010621153658.D14828@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 Issue 5: Support for multi-phase CT Submitter name: Pat Calhoun Submitter email address: pcalhoun@eng.sun.com Date first submitted: June 21,2001 Reference: Comment type: T Priority: 1 Section: 4.9 Rationale/Explanation of issue: The current requirement in section 4.9 states that a CT can only occur once all of the state has been gathered. The CT protocol must allow for state to be transferred in phases, where the high priority state (e.g. Header Compression, session keys) is sent first, and low priority items are sent at a later time (e.g. accounting information). This would reduce the size of the high priority CT packets, lower the computational cost of processing the packet, and decrease the handoff latency. Requested change: Change 4.9 to state something like: "4.9 Context information MAY be transferred in phases, allowing for higher priority state to be sent first, and lower priority state to be sent at a later time. The total cost of processing a smaller packet with high priority state is smaller, and would decrease any latency introduced by CT. Each CT profile would need to specify whether it is to be considered as a high or low priority state." Proposal: Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Thu Jun 21 18:51:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19562 for ; Thu, 21 Jun 2001 18:51:26 -0400 (EDT) Received: (qmail 17823 invoked by alias); 21 Jun 2001 22:40:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17817 invoked by uid 200); 21 Jun 2001 22:40:01 -0000 Received: (qmail 17810 invoked by uid 500); 21 Jun 2001 22:40:00 -0000 Date: Thu, 21 Jun 2001 15:40:00 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Issue 1:Change access network terminology Message-ID: <20010621154000.F14828@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, Based on the comments on this particular issue, I don't see consensus on changing the terminology from AR to something else, such as FN. If you have any objections, please state them now. PatC From owner-seamoby@diameter.org Thu Jun 21 18:56: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 SAA19649 for ; Thu, 21 Jun 2001 18:56:27 -0400 (EDT) Received: (qmail 18299 invoked by alias); 21 Jun 2001 22:45:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18293 invoked by uid 200); 21 Jun 2001 22:45:03 -0000 Received: (qmail 18288 invoked by uid 500); 21 Jun 2001 22:45:02 -0000 Date: Thu, 21 Jun 2001 15:45:02 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010621154502.G14828@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 If I understand this particular issue properly, it is a request for a layer 3 message be created to initiate CT. However, I believe that the mobility management used already has messages that initiate L3 handoffs, and these could be used to initiate CT. So, we have two options: 1. Create a message, which will introduce additional over the air latency in getting the CT initiated. 2. Retrofit in an existing MM solution, and perhaps create CT documents that describe the CT profile for MM. Example, a document that states how the MIPv6 binding update can be used as a substitute for L2 signalling. I, personally, much prefer option 2, but it does restrict CT to work only when an MM is present, which I believe would always be the case anyways. PatC From owner-seamoby@diameter.org Thu Jun 21 19:18:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20057 for ; Thu, 21 Jun 2001 19:18:04 -0400 (EDT) Received: (qmail 18868 invoked by alias); 21 Jun 2001 23:04:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18861 invoked by uid 200); 21 Jun 2001 23:04:51 -0000 Received: (qmail 18856 invoked from network); 21 Jun 2001 23:04:49 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 23:04:49 -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 QAA20527; Thu, 21 Jun 2001 16:15:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LNFJN28248; Thu, 21 Jun 2001 16:15:19 -0700 X-mProtect: Thu, 21 Jun 2001 16:15:19 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdfvKNHT; Thu, 21 Jun 2001 16:15:18 PDT Message-ID: <3B328006.27360218@iprg.nokia.com> Date: Thu, 21 Jun 2001 16:15:18 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Gary Kenward , seamoby@cdma-2000.org, charliep@IPRG.nokia.com Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com> <20010621152247.B14828@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I did open an issue, and I proposed the text. See at the bottom of this e-mail. We need to revise it a little bit now. So, here is the proposal for revised definitions: Reactive CT: The context transfer process which takes place subsequent to the MN establishing a new link with the new AR. Proactive CT: The context transfer process in which the contexts are present at the new AR prior to the arrival of MN's packets at the new AR. Charlie: would you consider revising it further ? Regards, -Rajeev Pat Calhoun wrote: > On Thu, Jun 21, 2001 at 04:58:02PM -0400, Gary Kenward wrote: > > Rajeev: > > > > I'll try to think of some new wording. I'd appreciate it if > > anyone else had a suggestion. > > > > Just to be clear, I am not sure exactly how Pat wants us to > > resolve the issues posted, but I will not be make changes to > > the requirements until their is a clear consensus capture on > > the www page (I think that's how its supposed to happen). This > > includes issues I might have with the current wg doc ;^} . > > well, I am rather confused in this whole thread, but I am trying > to catch up. So, do folks generally feel that a change is required? > If so, could we get some proposed text that we could sink our > teeth into? > > If there are additional changes that are being proposed, unless they > are purely editorial in nature, and MAY cause some commotion, then > I think an issue should be opened. Once we agree on the wording (read: > proposed text), then we can accept the text and close the issue. > > So far, I just see some people agreeing to nothing particularly > concrete :( > > PatC > > > > > Cheers, > > Gary > > > > Some questions/comments below: > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Thursday, June 21, 2001 4:29 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: seamoby@cdma-2000.org > > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > Rajeev: The benefit is a clear starting point for the CT > > > > > process. (i.e., > > > > > when to initiate CT) > > > > > > > > True enough, but the problem is that it is an event that happens too > > > > late. > > > > Certainly, for some networks, this may be the only handover > > > event that > > > > > > > > is visible at L3. But, for many networks, there are L2 triggers, and > > > > mobility > > > > events that can be forwarded to CT. > > > > > > > > In this sense, the definition you have provided is too limited. > > > > Perhaps > > > > the answer is to define another phase. I have no real ideas > > > on this at > > > > the > > > > moment: how about proactive, reactive and panic ;^} > > > > > > > > > > Rajeev: Given that you agree (at least partially) that in > > > some networks, > > > (or "inter-networks") IP message after the link is established is the > > > only way you could request CT, I would argue that the current > > > definition, which is based on L2 triggers and "mobility > > > events", is too > > > limited. It is ironic that we are debating whether to use IP messaging > > > to request CT once the link is established.. > > > > I agree that there is one requirement that implies that all triggers are > > originated at L2. This needs to be fixed. It was never intended that way. > > (It's the requirement to "hide" the specifics of an L2 trigger). > > > > I think I'll post a rewording for that requirement to make it more neutral, > > ok? > > > > > > > > > > > > > > Rajeev: The offered definition does not say anything > > > about how long > > > > > context transfer takes place. The _start_ of CT request is > > > > > the issue. A > > > > > packet arrives at the new AR (e.g., a MN request for CT), there is > > > > no > > > > > context there, then you fetch it. > > > > > > > > Ok. How CT starts is important. But as important is when it > > > finishes. > > > > Indeed, it is more important to me, as I see too little value in ct > > > > that > > > > finishes after 3 or 4 packets have been forwarded. I want ct to make > > > > real-time > > > > handovers opaque to the end-user. > > > > > > > > > > > > > > Rajeev: While I don't necessarily agree with the example, we all want > > > CT to finish before the packets start arriving. That's why we have > > > predictive handovers. When you can't do such a thing, e.g., consider > > > that link-layer triggers don't work because the two technologies are > > > different, you have the initiation of reactive CT after the MN > > > establishes a new link. > > > > I definitely believe this can happen. I am aiming for the requirements to be > > inclusive. I also don't see how the above has much to do with the first > > packet > > arrival at the new AR. It seems to have more to do with an MN initiated L3 > > trigger, correct? > > > > > > > > > > > > > > If the context is not in place for the first packet forwarding, > > > > then > > > > > > the transfer is reactive; meaning that at this point, > > > the goal is > > > > to > > > > > > complete the transfer as fast as possible to minimize > > > the delay in > > > > > > > > > > forwarding that first packet. > > > > > > > > > > > > > > > > Rajeev: Exactly. This is what I am proposing to be added. > > > > > > > > But this is in the current requirements. It just doesn't say that > > > > reactive > > > > starts with the first packet forwarding, accounting for the > > > fact that > > > > in some > > > > networks, reactive mode can occur before that event. > > > > > > > > > > Rajeev: Is it possible to re-word it such that it takes care of the > > > issue we have raised ? Can we say that reactive CT takes place as a > > > consequence of MN establishing a new link ? > > > This would be sufficient. > > > > Well, we could, but I'm unclear as to why you don't see that with the > > current requirements (at least once the problem with the L2 requirement is > > fixed). Everyone appears to agree that the origin of the triggers is not > > important, as long as the trigger manifests itself at L3 (probable as a > > control message) and has certain, as yet unspecified characteristics). > > > > The scenario you describe above could be resolved with either an L2 > > initiated trigger or an MN initiated trigger, could it not? > > > > If you were thinking of the trigger being the first IP data packet from the > > MN to hit the new AR, then that's fine (it may be a little late) - the new > > AR would simply have to filter incoming packets. There's big questions about > > what would happen next, but that's solution space. > > > > > > > > > > > > > > > > > > > > > > > > > > Reactive CT is when I either choose not to perform proactive CT, > > > > or > > > > > > I fail to meet the goal of being proactive. > > > > > > > > > > Rajeev: Agreed. Can we add the text then ? What do others think ? > > > > > > > > It seems to me that the only part that we disagree on is what > > > > indicates that "reactive mode" is occurring. > > > > > > > > > > Rajeev: Yes, and some text along the above lines would do it. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Onwards and upwards, > > > > Gary > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > > > Sent: Wednesday, June 20, 2001 2:49 PM > > > > > > > To: seamoby@cdma-2000.org > > > > > > > Subject: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > > > > > > > > > > > > > > > > > Description of issue :Clear, unambiguous definitions are > > > > missing. > > > > > > > > > > > > > > Submitter name: Rajeev Koodli > > > > > > > > > > > > > > Submitter email address: rajeev@iprg.nokia.com > > > > > > > > > > > > > > Date first submitted: June 20, 2001 > > > > > > > > > > > > > > Comment type: 'T'echnical > > > > > > > > > > > > > > Priority: ''S'/MUST fix > > > > > > > > > > > > > > Section: 4.5 > > > > > > > > > > > > > > Rationale/Explanation of issue: > > > > > > > > > > > > > > The section provides the description of proactive and reactive > > > > > > > CT without properly defining what they are. We need the > > > > > definitions. > > > > > > > > > > > > > > > > > > > > Requested Change: > > > > > > > > > > > > > > Reactive CT: The context transfer process which takes place > > > > > > subsequent > > > > > > > to arrival of a MN's packet at the target AR > > > > > > > > > > > > > > Proactive (I prfer Charlie's Predictive better) CT: The > > > > > > > context transfer > > > > > > > process in which the required contexts are in place at > > > > > the target AR > > > > > > > > > > > > > prior to the arrival of MN's packet at target AR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 21 19:22: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 TAA20135 for ; Thu, 21 Jun 2001 19:22:00 -0400 (EDT) Received: (qmail 19102 invoked by alias); 21 Jun 2001 23:07:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19096 invoked by uid 200); 21 Jun 2001 23:07:19 -0000 Received: (qmail 19084 invoked by uid 500); 21 Jun 2001 23:07:16 -0000 Date: Thu, 21 Jun 2001 16:07:16 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Pat Calhoun , Gary Kenward , seamoby@cdma-2000.org, charliep@IPRG.nokia.com Subject: Re: [seamoby] proactive and reactive CT definitions Message-ID: <20010621160715.K14828@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Pat Calhoun , Gary Kenward , seamoby@cdma-2000.org, charliep@iprg.nokia.com References: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com> <20010621152247.B14828@charizard.diameter.org> <3B328006.27360218@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B328006.27360218@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Thu, Jun 21, 2001 at 04:15:18PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > I did open an issue, and I proposed the text. See at the bottom of this e-mail. > We need to revise it a little bit now. right. > > So, here is the proposal for revised definitions: > > Reactive CT: The context transfer process which takes place subsequent to the MN > establishing a new link with the new AR. > > Proactive CT: The context transfer process in which the contexts are present at > the new AR prior to the arrival of MN's packets at the new AR. > > Charlie: would you consider revising it further ? and other folks, too, of course :) Do folks generally favor such a change? PatC From owner-seamoby@diameter.org Thu Jun 21 19:33: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 TAA20352 for ; Thu, 21 Jun 2001 19:33:36 -0400 (EDT) Received: (qmail 19851 invoked by alias); 21 Jun 2001 23:22:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19845 invoked by uid 200); 21 Jun 2001 23:22:11 -0000 Received: (qmail 19840 invoked from network); 21 Jun 2001 23:22:10 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jun 2001 23:22:10 -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 QAA21864; Thu, 21 Jun 2001 16:32:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5LNWeO21176; Thu, 21 Jun 2001 16:32:40 -0700 X-mProtect: Thu, 21 Jun 2001 16:32:40 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdvxSWqC; Thu, 21 Jun 2001 16:32:39 PDT Message-ID: <3B328417.DE7B88E0@iprg.nokia.com> Date: Thu, 21 Jun 2001 16:32:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Rajeev Koodli , Gary Kenward , seamoby@cdma-2000.org, charliep@IPRG.nokia.com Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com> <20010621152247.B14828@charizard.diameter.org> <3B328006.27360218@iprg.nokia.com> <20010621160715.K14828@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > > I did open an issue, and I proposed the text. See at the bottom of this e-mail. > > We need to revise it a little bit now. > > right. > > > > > So, here is the proposal for revised definitions: > > > > Reactive CT: The context transfer process which takes place subsequent to the MN > > establishing a new link with the new AR. > > > > Proactive CT: The context transfer process in which the contexts are present at > > the new AR prior to the arrival of MN's packets at the new AR. > > > > Charlie: would you consider revising it further ? > > and other folks, too, of course :) > > Do folks generally favor such a change? I prefer this change. its much more clear and concrete and would stop further debate on what proactive and reactive CT mean. Vijay > > PatC From owner-seamoby@diameter.org Fri Jun 22 00:40:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28069 for ; Fri, 22 Jun 2001 00:40:52 -0400 (EDT) Received: (qmail 21002 invoked by alias); 22 Jun 2001 04:29:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20996 invoked by uid 200); 22 Jun 2001 04:29:21 -0000 Received: (qmail 20990 invoked from network); 22 Jun 2001 04:29:19 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 04:29:19 -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 VAA06739; Thu, 21 Jun 2001 21:39:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5M4dpk04138; Thu, 21 Jun 2001 21:39:51 -0700 X-mProtect: Thu, 21 Jun 2001 21:39:51 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdpI0BaT; Thu, 21 Jun 2001 21:39:49 PDT Message-ID: <3B32CBBE.74EAE09E@iprg.nokia.com> Date: Thu, 21 Jun 2001 21:38:22 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D7B@zcard031.ca.nortel.com> <20010621152247.B14828@charizard.diameter.org> <3B328006.27360218@iprg.nokia.com> <20010621160715.K14828@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pat, > > So, here is the proposal for revised definitions: > > > > Reactive CT: The context transfer process which takes place subsequent to the MN > > establishing a new link with the new AR. > > > > Proactive CT: The context transfer process in which the contexts are present at > > the new AR prior to the arrival of MN's packets at the new AR. I would suggest that for Proactive context transfer, we should allow for the possibility that some of the context may still be in transit when packets begin to arrive for the mobile node at the new access router. One other characteristic is that reactive is a "context pull" operation, and proactive is a "context push" operation. They could still both use the same protocol message to deliver the context, though. In other words, as I understand "proactive", the previous access router predictively sends the context to a new access router (selected by some unspecified means, presumably initiated by some radio network controller). Reactive transfer, on the other hand, would typically be initiated by the new access router sending a request for context transfer to the previous access router. In many systems that reactive request might actually be triggered by a message from the mobile node, but the actual context transfer request would more likely seem to have emanated from the new access router. Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 22 02:40: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 CAA11939 for ; Fri, 22 Jun 2001 02:40:39 -0400 (EDT) Received: (qmail 21629 invoked by alias); 22 Jun 2001 06:29:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21624 invoked by uid 200); 22 Jun 2001 06:29:05 -0000 Received: (qmail 21615 invoked from network); 22 Jun 2001 06:29:03 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 06:29:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 02:39:35 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8059@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Fri, 22 Jun 2001 02:39:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 6:45 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] Issue 2: Make IP messages uniform > > > If I understand this particular issue properly, it is a > request for a layer 3 > message be created to initiate CT. However, I believe that > the mobility management > used already has messages that initiate L3 handoffs, and > these could be used > to initiate CT. > > So, we have two options: > 1. Create a message, which will introduce additional over the > air latency in > getting the CT initiated. The newAR will need to request CT from a peer AR. Are you suggesting that MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA? Or, is it quite possible that the CoA and the oldAR may not be co-located? Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some technology do we really care about over the air latency for a few bytes? Of course some lower bandwidth technologies will use an L2 Trigger at the newAR, but the choice is really technology specific. Further, I would hope that if the CoA were not co-located with the oldAR that some time could be saved by sending a change in route to the parent AR on the newAR-to-ParentAR link, while at the _same_ time sending a message to the oldAR on the oldAR-to-newAR link to transfer Context. Since time is very critical in Reactive Context Transfer it would seem like a very useful method to reduce latency. Additionally, a MN message on a high bandwidth link could be forwarded by the currentAR to the oldAR to request CT, and at the _same_ time a MN message could be forwarded by the currentAR to the ParentAR to affect a route change. The route change message may travel to a different entity along a different link, than the Context Transfer request message. Having them happen in parrallel could significantly reduce Reactive Context Transfer. - Kulwinder. > 2. Retrofit in an existing MM solution, and perhaps create CT > documents that > describe the CT profile for MM. Example, a document that > states how the > MIPv6 binding update can be used as a substitute for L2 signalling. > > I, personally, much prefer option 2, but it does restrict CT > to work only > when an MM is present, which I believe would always be the > case anyways. > > PatC > From owner-seamoby@diameter.org Fri Jun 22 14:49: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 OAA04483 for ; Fri, 22 Jun 2001 14:49:50 -0400 (EDT) Received: (qmail 23455 invoked by alias); 22 Jun 2001 18:37:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23448 invoked by uid 200); 22 Jun 2001 18:37:48 -0000 Received: (qmail 23443 invoked from network); 22 Jun 2001 18:37:46 -0000 Received: from boreas.isi.edu (128.9.160.161) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 18:37:46 -0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f5MImjG20654; Fri, 22 Jun 2001 11:48:45 -0700 (PDT) Message-Id: <200106221848.f5MImjG20654@boreas.isi.edu> To: IETF-Announce: ; Subject: [seamoby] RFC 3132 on Dormant Mode Host Alerting Problem Statement Cc: rfc-ed@ISI.EDU, seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 22 Jun 2001 11:48:45 -0700 From: RFC Editor Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3132 Title: Dormant Mode Host Alerting ("IP Paging") Problem Statement Author(s): J. Kempf Status: Informational Date: June 2001 Mailbox: james.kempf@sun.com Pages: 14 Characters: 34985 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-seamoby-paging-problem-statement-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3132.txt This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. The results are specifically directed toward the task undertaken by the design team, and are not meant to be the definitive word on paging for all time, nor to be binding on Seamoby or other working groups, should the situation with regard to IP mobility protocols or radio link support undergo a major change. This document is a product of the Context and Micro-mobility Routing Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010622114648.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3132 --OtherAccess Content-Type: Message/External-body; name="rfc3132.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010622114648.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Fri Jun 22 15:34: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 PAA06559 for ; Fri, 22 Jun 2001 15:34:03 -0400 (EDT) Received: (qmail 24470 invoked by alias); 22 Jun 2001 19:21:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24464 invoked by uid 200); 22 Jun 2001 19:21:20 -0000 Received: (qmail 24458 invoked from network); 22 Jun 2001 19:21:18 -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; 22 Jun 2001 19:21:18 -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 f5MJVd005608 for ; Fri, 22 Jun 2001 15:31:39 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 22 Jun 2001 15:31:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 15:31:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D7E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , Rajeev Koodli Cc: seamoby@cdma-2000.org, charliep@IPRG.nokia.com Subject: RE: [seamoby] proactive and reactive CT definitions Date: Fri, 22 Jun 2001 15:31:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB51.F8A68800" 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_01C0FB51.F8A68800 Content-Type: text/plain; charset="iso-8859-1" Pat: I do not. While I understand the general argument, and I actually agree with it, I see tying reactive CT to the events mentioned as being too restrictive. To echo Charlie's own arguments: "establishing a link" is a process, not an event, and the definition proposed below links reactive CT to then end of that process. What if someone wants to use the start of the process as the event? What is someone wants to use an L2 event to initiate a reactive CT that is coupled but asynchronous to the "link establishment"? The bottom line is that tying the requirement to a specific event prevents others from taking a different approach, and ct was supposed to be applicable to any wireless or wireline network. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 7:07 PM > To: Rajeev Koodli > Cc: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH]; > seamoby@cdma-2000.org; > charliep@IPRG.nokia.com > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > I did open an issue, and I proposed the text. See at the > bottom of this e-mail. > > We need to revise it a little bit now. > > right. > > > > > So, here is the proposal for revised definitions: > > > > Reactive CT: The context transfer process which takes place > subsequent to the MN > > establishing a new link with the new AR. > > > > Proactive CT: The context transfer process in which the > contexts are present at > > the new AR prior to the arrival of MN's packets at the new AR. > > > > Charlie: would you consider revising it further ? > > and other folks, too, of course :) > > Do folks generally favor such a change? > > PatC > > -------------------------------------------------------------- > ----------- > This email server is running an evaluation copy of the > MailShield anti- > spam software. Please contact your email administrator if you have any > questions about this message. MailShield product info: www.mailshield.com ------_=_NextPart_001_01C0FB51.F8A68800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] proactive and reactive CT definitions

Pat:

 I do not. While I understand the general = argument, and I actually agree
with it, I see tying reactive CT to the events = mentioned as being too restrictive.

 To echo Charlie's own arguments: = "establishing a link" is a process, not an
event, and the definition proposed below links = reactive CT to then end of that
process. What if someone wants to use the start of = the process as the event?
What is someone wants to use an L2 event to initiate = a reactive CT that is coupled but asynchronous to the "link = establishment"?

The bottom line is that tying the requirement to a = specific event prevents others from taking a different approach, and ct = was supposed to be applicable to any wireless or wireline = network.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Thursday, June 21, 2001 7:07 PM
> To: Rajeev Koodli
> Cc: Pat Calhoun; Kenward, Gary = [WDLN2:AN10:EXCH];
> seamoby@cdma-2000.org;
> charliep@IPRG.nokia.com
> Subject: Re: [seamoby] proactive and reactive = CT definitions
>
>
> > I did open an issue, and I proposed the = text. See at the
> bottom of this e-mail.
> > We need to revise it a little bit = now.
>
> right.
>
> >
> > So, here is the proposal for revised = definitions:
> >
> > Reactive CT: The context transfer process = which takes place
> subsequent to the MN
> > establishing a new link with the new = AR.
> >
> > Proactive CT: The context transfer process = in which the
> contexts are present at
> > the new AR prior to the arrival of MN's = packets at the new AR.
> >
> > Charlie: would you consider revising it = further ?
>
> and other folks, too, of course :)
>
> Do folks generally favor such a change?
>
> PatC
>
> = --------------------------------------------------------------
> -----------
> This email server is running an evaluation copy = of the
> MailShield anti-
> spam software. Please contact your email = administrator if you have any
> questions about this message. MailShield = product info:
www.mailshield.com

------_=_NextPart_001_01C0FB51.F8A68800-- From owner-seamoby@diameter.org Fri Jun 22 15:41:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06883 for ; Fri, 22 Jun 2001 15:41:44 -0400 (EDT) Received: (qmail 24946 invoked by alias); 22 Jun 2001 19:28:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24940 invoked by uid 200); 22 Jun 2001 19:28:56 -0000 Received: (qmail 24932 invoked from network); 22 Jun 2001 19:28:54 -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; 22 Jun 2001 19:28:54 -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 f5MJdF006449 for ; Fri, 22 Jun 2001 15:39:15 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 22 Jun 2001 15:38:52 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 15:38:55 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D7F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" , Pat Calhoun Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Fri, 22 Jun 2001 15:38:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB52.F6554F90" 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_01C0FB52.F6554F90 Content-Type: text/plain; charset="iso-8859-1" Pat: The debate has been centered so much around the definition of reactive, I missed the change in proactive. I agree with Charlie, in no way should proactive ct be required to end at some particular event. We have a requirement that ct should not delay handover. It is unrealistic to believe that ct will *never* delay handover and attempting too set a termination limit is just as unrealistic. Gary > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 22, 2001 12:38 AM > To: Pat Calhoun > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > Hello Pat, > > > > So, here is the proposal for revised definitions: > > > > > > Reactive CT: The context transfer process which takes > place subsequent to the MN > > > establishing a new link with the new AR. > > > > > > Proactive CT: The context transfer process in which the > contexts are present at > > > the new AR prior to the arrival of MN's packets at the new AR. > > I would suggest that for Proactive context transfer, we > should allow for the > possibility that some of the context may still be in transit > when packets begin > to arrive for the mobile node at the new access router. > > One other characteristic is that reactive is a "context pull" > operation, > and proactive is a "context push" operation. They could still both > use the same protocol message to deliver the context, though. > In other words, as I understand "proactive", the previous access > router predictively sends the context to a new access router > (selected by some unspecified means, presumably initiated by > some radio network controller). Reactive transfer, on the other > hand, would typically be initiated by the new access router > sending a request for context transfer to the previous access > router. In many systems that reactive request might actually > be triggered by a message from the mobile node, but the > actual context transfer request would more likely seem to have > emanated from the new access router. > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C0FB52.F6554F90 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] proactive and reactive CT definitions

Pat:
 
  The debate has been centered so much around the definition of reactive,
I missed the change in proactive. I agree with Charlie, in no way should
proactive ct be required to end at some particular event. We have a requirement
that ct should not delay handover. It is unrealistic to believe that ct will
*never* delay handover and attempting too set a termination limit is just as unrealistic.

Gary

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Friday, June 22, 2001 12:38 AM
> To: Pat Calhoun
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] proactive and reactive CT definitions
>
>
>
> Hello Pat,
>
> > > So, here is the proposal for revised definitions:
> > >
> > > Reactive CT: The context transfer process which takes
> place subsequent to the MN
> > > establishing a new link with the new AR.
> > >
> > > Proactive CT: The context transfer process in which the
> contexts are present at
> > > the new AR prior to the arrival of MN's packets at the new AR.
>
> I would suggest that for Proactive context transfer, we
> should allow for the
> possibility that some of the context may still be in transit
> when packets begin
> to arrive for the mobile node at the new access router.
>
> One other characteristic is that reactive is a "context pull"
> operation,
> and proactive is a "context push" operation.  They could still both
> use the same protocol message to deliver the context, though.
> In other words, as I understand "proactive", the previous access
> router predictively sends the context to a new access router
> (selected by some unspecified means, presumably initiated by
> some radio network controller).  Reactive transfer, on the other
> hand, would typically be initiated by the new access router
> sending a request for context transfer to the previous access
> router.  In many systems that reactive request might actually
> be triggered by a message from the mobile node, but the
> actual context transfer request would more likely seem to have
> emanated from the new access router.
>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C0FB52.F6554F90-- From owner-seamoby@diameter.org Fri Jun 22 15:46:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07147 for ; Fri, 22 Jun 2001 15:46:53 -0400 (EDT) Received: (qmail 23999 invoked by alias); 22 Jun 2001 19:13:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23993 invoked by uid 200); 22 Jun 2001 19:13:26 -0000 Received: (qmail 23988 invoked from network); 22 Jun 2001 19:13:24 -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; 22 Jun 2001 19:13:24 -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 f5MJNe004356 for ; Fri, 22 Jun 2001 15:23:41 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 22 Jun 2001 15:23:45 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 15:23:48 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D7D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT Date: Fri, 22 Jun 2001 15:23:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB50.D9F15080" 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_01C0FB50.D9F15080 Content-Type: text/plain; charset="iso-8859-1" Pat: I with you up until that last two paragraphs of the proposed new texts. The second to last paragraph is editorial, and presumes much about the context, the ctp design and the implementation. As for the last paragraph, I do not see the need to add priority to CTP. It is already required that the receiving AR process the context in the order received, and this yields the same result (priority can always be translated to a measurable performance criteria, such as "processed sooner" or "given more resources"). I do not see the utility of a "priority" bit. Perhaps you could elaborate? Otherwise I have no problem with the additional requirement (although I wonder what an operator would say about "accounting" being "low priority" ;^}). Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 6:37 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > Issue 5: Support for multi-phase CT > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@eng.sun.com > Date first submitted: June 21,2001 > Reference: > Comment type: T > Priority: 1 > Section: 4.9 > > Rationale/Explanation of issue: > The current requirement in section 4.9 states that a CT can only > occur once all of the state has been gathered. The CT protocol > must allow for state to be transferred in phases, where the high > priority state (e.g. Header Compression, session keys) is sent > first, and low priority items are sent at a later time (e.g. > accounting information). > > This would reduce the size of the high priority CT packets, > lower the computational cost of processing the packet, > and decrease > the handoff latency. > > Requested change: > Change 4.9 to state something like: > > "4.9 Context information MAY be transferred in phases, > allowing for > higher priority state to be sent first, and lower priority > state to be sent at a later time. > > The total cost of processing a smaller packet with high priority > state is smaller, and would decrease any latency > introduced by CT. Each > CT profile would need to specify whether it is to be considered > as a high or low priority state." > > Proposal: > Adopt the text above in the -01 version of the > requirements spec. > ------_=_NextPart_001_01C0FB50.D9F15080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] [Issue] Support for Multi-Phase CT

Pat:

  I with you up until that last two paragraphs = of the proposed new texts.
The second to last paragraph is editorial, and = presumes much about the context,
the ctp design and the implementation.

  As for the last paragraph, I do not see the = need to add priority to CTP. It is already required that the receiving = AR process the context in the order received, and this yields the same = result (priority can always be translated to a measurable performance = criteria, such as "processed sooner" or "given more = resources"). I do not see the utility of a "priority" = bit. Perhaps you could

elaborate?

  Otherwise I have no problem with the = additional requirement (although I wonder what an operator would say = about "accounting" being "low priority" = ;^}).

Gary


> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Thursday, June 21, 2001 6:37 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] [Issue] Support for = Multi-Phase CT
>
>
> Issue 5: Support for multi-phase CT
>
>      Submitter name: = Pat Calhoun
>      Submitter email = address: pcalhoun@eng.sun.com
>      Date first = submitted: June 21,2001
>      Reference: =
>      Comment type: T =
>      Priority: 1 =
>      Section: 4.9 =
>
>      = Rationale/Explanation of issue:
>      The current = requirement in section 4.9 states that a CT can only
>      occur once all of = the state has been gathered. The CT protocol
>      must allow for = state to be transferred in phases, where the high
>      priority state = (e.g. Header Compression, session keys) is sent
>      first, and low = priority items are sent at a later time (e.g.
>      accounting = information).
>
>      This would reduce = the size of the high priority CT packets,
>      lower the = computational cost of processing the packet,
> and decrease
>      the handoff = latency.
>
>      Requested change: =
>      Change 4.9 to = state something like:
>
>      "4.9 Context = information MAY be transferred in phases,
> allowing for
>      higher priority = state to be sent first, and lower priority
>      state to be sent = at a later time.
>
>      The total cost of = processing a smaller packet with high priority
>      state is smaller, = and would decrease any latency
> introduced by CT. Each
>      CT profile would = need to specify whether it is to be considered
>      as a high or low = priority state."
>
>      Proposal:
>      Adopt the text = above in the -01 version of the
> requirements spec.
>

------_=_NextPart_001_01C0FB50.D9F15080-- From owner-seamoby@diameter.org Fri Jun 22 17:03:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10117 for ; Fri, 22 Jun 2001 17:03:07 -0400 (EDT) Received: (qmail 25586 invoked by alias); 22 Jun 2001 20:50:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25580 invoked by uid 200); 22 Jun 2001 20:50:52 -0000 Received: (qmail 25575 invoked from network); 22 Jun 2001 20:50:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 20:50:50 -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 OAA23829; Fri, 22 Jun 2001 14:01:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5ML1No22312; Fri, 22 Jun 2001 14:01:23 -0700 X-mProtect: Fri, 22 Jun 2001 14:01:23 -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 smtpdX5yLoe; Fri, 22 Jun 2001 14:01:22 PDT Message-ID: <3B33B222.5D714E64@iprg.nokia.com> Date: Fri, 22 Jun 2001 14:01:22 -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: Gary Kenward CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D7E@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, > To echo Charlie's own arguments: "establishing a link" is a process, not an > event, and the definition proposed below links reactive CT to then end of that > process. What if someone wants to use the start of the process as the event? > What is someone wants to use an L2 event to initiate a reactive CT that is > coupled but asynchronous to the "link establishment"? It's still coupled to an event associated with link establishment. Maybe the words need refinement, but the idea might be clear enough. > The bottom line is that tying the requirement to a specific event prevents > others from taking a different approach, and ct was supposed to be applicable > to any wireless or wireline network. I'm generally in agreement with your sentiment here, but I sort-of thought that some bits had to be able to traverse the medium before a reactive context transfer could start. Your point about possibly asynchronous operation, or parallel operation of context transfer and link establishment, is valid I reckon. And yet the reactive process doesn't just start up out of the blue. Thus, we ought to be able to figure out some words to characterize the kind of event that initiates a reactive context transfer. Is it possible to use the "push/pull" distinction instead of making the definition in terms of a protocol event? I haven't fully thought this through, so I'm not sure... Regards, Charlie P. > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 21, 2001 7:07 PM > > To: Rajeev Koodli > > Cc: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH]; > > seamoby@cdma-2000.org; > > charliep@IPRG.nokia.com > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > I did open an issue, and I proposed the text. See at the > > bottom of this e-mail. > > > We need to revise it a little bit now. > > > > right. > > > > > > > > So, here is the proposal for revised definitions: > > > > > > Reactive CT: The context transfer process which takes place > > subsequent to the MN > > > establishing a new link with the new AR. > > > > > > Proactive CT: The context transfer process in which the > > contexts are present at > > > the new AR prior to the arrival of MN's packets at the new AR. > > > > > > Charlie: would you consider revising it further ? > > > > and other folks, too, of course :) > > > > Do folks generally favor such a change? > > > > PatC > > > > -------------------------------------------------------------- > > ----------- > > This email server is running an evaluation copy of the > > MailShield anti- > > spam software. Please contact your email administrator if you have any > > questions about this message. MailShield product info: > www.mailshield.com From owner-seamoby@diameter.org Fri Jun 22 17:05: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 RAA10206 for ; Fri, 22 Jun 2001 17:05:21 -0400 (EDT) Received: (qmail 25663 invoked by alias); 22 Jun 2001 20:51:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25656 invoked by uid 200); 22 Jun 2001 20:51:06 -0000 Received: (qmail 25637 invoked by uid 500); 22 Jun 2001 20:51:03 -0000 Date: Fri, 22 Jun 2001 13:51:03 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Charlie Perkins'" , Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Message-ID: <20010622135103.B14828@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Charlie Perkins' , Pat Calhoun , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D7F@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: <9FBD322B7824D511B36900508BF93C9C9F5D7F@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Fri, Jun 22, 2001 at 03:38:50PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 22, 2001 at 03:38:50PM -0400, Gary Kenward wrote: > Pat: > > The debate has been centered so much around the definition of reactive, > I missed the change in proactive. I agree with Charlie, in no way should > proactive ct be required to end at some particular event. We have a > requirement > that ct should not delay handover. It is unrealistic to believe that ct will > > *never* delay handover and attempting too set a termination limit is just as > unrealistic. so you are in agreement with the whole change, or just portions of? PatC > > Gary > > > -----Original Message----- > > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > > Sent: Friday, June 22, 2001 12:38 AM > > To: Pat Calhoun > > Cc: seamoby@cdma-2000.org > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > Hello Pat, > > > > > > So, here is the proposal for revised definitions: > > > > > > > > Reactive CT: The context transfer process which takes > > place subsequent to the MN > > > > establishing a new link with the new AR. > > > > > > > > Proactive CT: The context transfer process in which the > > contexts are present at > > > > the new AR prior to the arrival of MN's packets at the new AR. > > > > I would suggest that for Proactive context transfer, we > > should allow for the > > possibility that some of the context may still be in transit > > when packets begin > > to arrive for the mobile node at the new access router. > > > > One other characteristic is that reactive is a "context pull" > > operation, > > and proactive is a "context push" operation. They could still both > > use the same protocol message to deliver the context, though. > > In other words, as I understand "proactive", the previous access > > router predictively sends the context to a new access router > > (selected by some unspecified means, presumably initiated by > > some radio network controller). Reactive transfer, on the other > > hand, would typically be initiated by the new access router > > sending a request for context transfer to the previous access > > router. In many systems that reactive request might actually > > be triggered by a message from the mobile node, but the > > actual context transfer request would more likely seem to have > > emanated from the new access router. > > > > Regards, > > Charlie P. > > > > > > From owner-seamoby@diameter.org Fri Jun 22 17:07: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 RAA10248 for ; Fri, 22 Jun 2001 17:07:34 -0400 (EDT) Received: (qmail 26261 invoked by alias); 22 Jun 2001 20:54:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26253 invoked by uid 200); 22 Jun 2001 20:54:38 -0000 Received: (qmail 26241 invoked by uid 500); 22 Jun 2001 20:54:35 -0000 Date: Fri, 22 Jun 2001 13:54:35 -0700 From: Pat Calhoun To: "Charles E. Perkins" Cc: Gary Kenward , seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Message-ID: <20010622135435.D14828@charizard.diameter.org> Mail-Followup-To: "Charles E. Perkins" , Gary Kenward , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D7E@zcard031.ca.nortel.com> <3B33B222.5D714E64@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B33B222.5D714E64@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 22, 2001 at 02:01:22PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > I'm generally in agreement with your sentiment here, but I sort-of thought > that some bits had to be able to traverse the medium before a reactive > context transfer could start. Your point about possibly asynchronous > operation, or parallel operation of context transfer and link establishment, > is valid I reckon. And yet the reactive process doesn't just start up > out of the blue. Thus, we ought to be able to figure out some words to > characterize the kind of event that initiates a reactive context transfer. > > Is it possible to use the "push/pull" distinction instead of making > the definition in terms of a protocol event? I haven't fully thought > this through, so I'm not sure... I don't think so. A pro-active is not bound to a particular direction. In a target trigger (using the FMIPv4 terminology), it would pull the context, and this could occur before the actual handoff is complete. In a source trigger, the would push the context, and again, it could occur before the handoff is complete. So pull/push wouldn't work. PatC From owner-seamoby@diameter.org Fri Jun 22 17:36:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12215 for ; Fri, 22 Jun 2001 17:36:38 -0400 (EDT) Received: (qmail 27052 invoked by alias); 22 Jun 2001 21:25:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27046 invoked by uid 200); 22 Jun 2001 21:25:08 -0000 Received: (qmail 27040 invoked from network); 22 Jun 2001 21:25:07 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 21:25:07 -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 OAA26529; Fri, 22 Jun 2001 14:35:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5MLZfR04164; Fri, 22 Jun 2001 14:35:41 -0700 X-mProtect: Fri, 22 Jun 2001 14:35:41 -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 smtpd0RPT6S; Fri, 22 Jun 2001 14:35:39 PDT Message-ID: <3B33BA2B.D0C130@iprg.nokia.com> Date: Fri, 22 Jun 2001 14:35:39 -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: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5D7E@zcard031.ca.nortel.com> <3B33B222.5D714E64@iprg.nokia.com> <20010622135435.D14828@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pat, > I don't think so. A pro-active is not bound to a particular direction. In a > target trigger (using the FMIPv4 terminology), it would pull the context, and > this could occur before the actual handoff is complete. Do you mean that the new access router could request context from the old access router before a bit could traverse the air interface? > In a source trigger, > the would push the context, and again, it could occur before the handoff is > complete. This latter case is presumably more common. > So pull/push wouldn't work. Too bad. I agree that if the target trigger context pull is initiated before the mobile node is connected, the push/pull distinction wouldn't work. I'm a little bit surprised that such a case is important, but if it is then so be it. That would put us back to defining reactive and proactive in terms of some recognizable event associated with the mobile node's arrival at the new access network (or, maybe even "at" the new access router). Regards, Charlie P. From owner-seamoby@diameter.org Fri Jun 22 18:12: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 SAA13199 for ; Fri, 22 Jun 2001 18:12:13 -0400 (EDT) Received: (qmail 27633 invoked by alias); 22 Jun 2001 22:00:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27627 invoked by uid 200); 22 Jun 2001 22:00:22 -0000 Received: (qmail 27618 invoked by uid 500); 22 Jun 2001 22:00:20 -0000 Date: Fri, 22 Jun 2001 15:00:20 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT Message-ID: <20010622150020.M14828@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D7D@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: <9FBD322B7824D511B36900508BF93C9C9F5D7D@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Fri, Jun 22, 2001 at 03:23:43PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote: > I with you up until that last two paragraphs of the proposed new texts. > The second to last paragraph is editorial, and presumes much about the > context, > the ctp design and the implementation. ok, I am certainly open to suggestions. > As for the last paragraph, I do not see the need to add priority to CTP. > It is already required that the receiving AR process the context in the > order received, and this yields the same result (priority can always be > translated to a measurable performance criteria, such as "processed sooner" > or "given more resources"). I do not see the utility of a "priority" bit. > Perhaps you could > elaborate? This isn't a question of a bit. It has to do with sending critical CT information that is REQUIRED in order to deliver a single packet to the mobile. This could include HC state, session keys, etc. This state info is sent first when a handoff is occuring. Later (say, 1+ seconds later) additional state is sent. Although this info is important, it may only be necessary when doing things such as generating accounting messages, which are infrequent, and not required during the handoff process. > Otherwise I have no problem with the additional requirement (although I > wonder what an operator would say about "accounting" being "low priority" > ;^}). :) PatC > > Gary > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 21, 2001 6:37 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > > > > Issue 5: Support for multi-phase CT > > > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@eng.sun.com > > Date first submitted: June 21,2001 > > Reference: > > Comment type: T > > Priority: 1 > > Section: 4.9 > > > > Rationale/Explanation of issue: > > The current requirement in section 4.9 states that a CT can only > > occur once all of the state has been gathered. The CT protocol > > must allow for state to be transferred in phases, where the high > > priority state (e.g. Header Compression, session keys) is sent > > first, and low priority items are sent at a later time (e.g. > > accounting information). > > > > This would reduce the size of the high priority CT packets, > > lower the computational cost of processing the packet, > > and decrease > > the handoff latency. > > > > Requested change: > > Change 4.9 to state something like: > > > > "4.9 Context information MAY be transferred in phases, > > allowing for > > higher priority state to be sent first, and lower priority > > state to be sent at a later time. > > > > The total cost of processing a smaller packet with high priority > > state is smaller, and would decrease any latency > > introduced by CT. Each > > CT profile would need to specify whether it is to be considered > > as a high or low priority state." > > > > Proposal: > > Adopt the text above in the -01 version of the > > requirements spec. > > From owner-seamoby@diameter.org Fri Jun 22 18:17: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 SAA13325 for ; Fri, 22 Jun 2001 18:17:00 -0400 (EDT) Received: (qmail 28112 invoked by alias); 22 Jun 2001 22:05:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28106 invoked by uid 200); 22 Jun 2001 22:05:19 -0000 Received: (qmail 28097 invoked by uid 500); 22 Jun 2001 22:05:17 -0000 Date: Fri, 22 Jun 2001 15:05:17 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010622150517.N14828@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Pat Calhoun' , seamoby@cdma-2000.org References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8059@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8059@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Fri, Jun 22, 2001 at 02:39:35AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote: > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 21, 2001 6:45 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] Issue 2: Make IP messages uniform > > > > > > If I understand this particular issue properly, it is a > > request for a layer 3 > > message be created to initiate CT. However, I believe that > > the mobility management > > used already has messages that initiate L3 handoffs, and > > these could be used > > to initiate CT. > > > > So, we have two options: > > 1. Create a message, which will introduce additional over the > > air latency in > > getting the CT initiated. > > The newAR will need to request CT from a peer AR. Are you suggesting that > MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA? > Or, is it quite possible that the CoA and the oldAR may not be co-located? > > Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some > technology do we really care about over the air latency for a few bytes? no, but look at option 2 below. My point is that there is already some signalling, either at L2 (e.g. signal strength), or at L3 (binding update). Why require another message, since we've already agreed to co-locate with other MM protocols. > > Of course some lower bandwidth technologies will use an L2 Trigger at the > newAR, but the choice is really technology specific. right, so we allow for L2 or L3. The question is whether CT needs to define another message, or if an existing one can be used. I much prefer the latter. > > Further, I would hope that if the CoA were not co-located with the oldAR > that some time could be saved by sending a change in route to the parent AR > on the newAR-to-ParentAR link, while at the _same_ time sending a message to > the oldAR on the oldAR-to-newAR link to transfer Context. > > Since time is very critical in Reactive Context Transfer it would seem like > a very useful method to reduce latency. right, but I don't see how a CT L3 message would be faster, and therefore enable reactive CT, than would a binding update. > Additionally, a MN message on a high bandwidth link could be forwarded by > the currentAR to the oldAR to request CT, and at the _same_ time a MN > message could be forwarded by the currentAR to the ParentAR to affect a > route change. > > The route change message may travel to a different entity along a different > link, than the Context Transfer request message. Having them happen in > parrallel could significantly reduce Reactive Context Transfer. ok, this is the one and first argument that I've heard that could convince me to agree to MN-initiated CT. PatC From owner-seamoby@diameter.org Fri Jun 22 18:40:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13891 for ; Fri, 22 Jun 2001 18:40:45 -0400 (EDT) Received: (qmail 28610 invoked by alias); 22 Jun 2001 22:29:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28604 invoked by uid 200); 22 Jun 2001 22:29:03 -0000 Received: (qmail 28599 invoked from network); 22 Jun 2001 22:29:01 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 22:29:01 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA09990 for ; Fri, 22 Jun 2001 15:40:05 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA11744 for ; Fri, 22 Jun 2001 15:33:16 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 17:40:04 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DEF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Fri, 22 Jun 2001 17: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 Hi Charlie, Thanks for the valuable insights. Sorry for the delay. I am responding to your comments in general for now, and hopefully get back to you with more details responses to your statements. Basically, after giving it some more thought, I like your definitions more, IF we cover all the holes as I explain: it seems that you like to see the proactive or reactive-ness of CT based on a starting trigger, rather than when CT completes and you want to base the definition on link establishment rather than handover. I agree that handover can be a bit fuzzy, but I want to assume that by link establishment you are talking about a L3 connection ((or Link layer connectivity) between MN and newAR. If we agree on this, let me go forward. I can see three cases for how CT can happen in regards to link establishment with the newAR. I intentionally don't bring the loss of connectivity with oldAR as a factor here. (I call the event that starts CT as CT trigger, it could be explicit or implicit) 1-CT trigger arrives before Handover trigger (what starts the handover, it could be at oldAR, at newAR or at MN) and naturally before link establishment. 2-CT trigger arrives after handover trigger, but before link layer establishment with newAR. 3-CT trigger arrives after link layer establishment with newAR. The way I see it, if we want to base the definitions of pro and reactive on the starting event: Your Proactive covers 1 and 2. Your reactive covers 3. Do we agree? If yes I am ok with this, the reason is the current draft definition: Proactive covers only 1 and only if CT completes prior to packet arrival and reactive covers both 2 and 3 only if CT completes after packet arrival (it does not cover 2 and 3 if the CT completes before packet arrival). So actually the draft definition is not conclusive of all cases, but your definition does not provide any timing requirement (the reason we defined reactive-ness and proactiveness the way we did). Note however, that I don't agree that proactive or reactive should be defined based on inquiry source as you explained in your other email. I don't think proactive=oldAR sends context, reactive=newAR sends context request (who sends and who requests things is more of a design matter, don't you agree? We had this discussion for a short while and we all decided that who initiates CT should not be the issue. Regards, Madjid From owner-seamoby@diameter.org Fri Jun 22 19:26: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 TAA14917 for ; Fri, 22 Jun 2001 19:26:09 -0400 (EDT) Received: (qmail 29098 invoked by alias); 22 Jun 2001 22:51:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29092 invoked by uid 200); 22 Jun 2001 22:51:15 -0000 Received: (qmail 29087 invoked from network); 22 Jun 2001 22:51:12 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Jun 2001 22:51:12 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA20052 for ; Fri, 22 Jun 2001 16:02:17 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA08371 for ; Fri, 22 Jun 2001 16:02:16 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 18:02:16 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF0@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Fri, 22 Jun 2001 18:02:16 -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 Hi Charlie, Comments below (MN>>) -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Thursday, June 21, 2001 3:40 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions Hello Madjid, I hope you don't mind if I edge a word in between. MN>> I actually appreciate it :) > I think, I know what the problem is: > The draft bases the definition of Proactive and reactive on > when the handover (packet arrival) COMPLETE S. But the problem could be that the term "handover" is not sufficiently crisp to carry out the discussion. The concept of link establishment, however, is crisp enough. I would like to suggest using the latter term. I would define it as follows: - A link establishment has occurred when a mobile node becomes able to send a packet to the access router This does NOT say that the mobile node is REQUIRED to send a layer-3 packet before the link is established -- only that it _could_ send a layer-3 packet. MN>> I am not sure if I understand the sentence above, but I take it as, by link establishment you mean the MN is able to send and receive L3 packets. The reason we picked Handover, was so we knew whether we were introducing latency into handovers or not. Then, my definitions about reactive vs. predictive/proactive context transfer initiation are equally precise. > I think the drafts approach is better FOR NOW since, we have not completed > the frame work discussion yet (we did have a discussion about Mobility > framework, and I did ask the question of whether the scope is Mobile IP > or not, of the very same reason). Basing the definitions on link establishment avoids completely any questions about Mobile IP. MN>> Please see my earlier email on the 3 cases. > When you don't know what your underlying layer 2 technology or your > Layer 3 mobility baseline is, then you have to speak in common, general > terms, such as packet arrival. Even packet arrival is quite susceptible to ambiguity: - Is it that a packet arrived, or that it MIGHT have arrived? - What packet is it that arrived? - Did it arrive at the mobile node, the previous access router, or the new access router? MN>> I agree, however, it is not very hard to change it, to say Packet arrival at newAR (since that is what matters for CT). Not having feature contexts might make the packet arrival defintion fuzzier if you don't know how to interprete packets. However, as I said you can replace packet arrival with an almost equivalent event (say another message that makes packets arrive at newAR). MN>>point was to define a deadline for CT to be complete, and basing everything on the starting event, does not provide any timing requirements for CT, unless you want to leave it open for now. > Start of CT can be based on all kinds of things: > Example From Mobile IP fast handover perspective: > 1-Solicitation for proxy router > 2-Binding update > 3-Neighbor advertisement from Mobile The Mobile IP fast handover allows layer-2 triggers also. > Example From a link layer perspective > 1-Pilot beacon/ signal strenght measurement > 2-RLC/P/ RNC scheduler directive > 3-Mobility management unit > ...... > >From a CNP network that is doing more advance next router discovery > there could be other types of signals, especially for proactive, > you are understimating the beyond 3G scenarios. > > So which CT trigger do you want to pick? > > Earlier trigger + less amount context + higher AR-AR bandwith > leads to a faster CT (more chance for proactive). > A slow handover solution (base Mobile IP) waits for L2 HO completion and > then starts L3 signaling, a faster handover solution starts earlier. Of course everyone wants to have reliable predictive handovers. But for systems that cannot fit within that design parameter it would still be nice to have fast reactive handovers. It is not a fair criticism of reactive handover to insist that proactive is better. And similarly for reactive context transfer. MN>> Sure, my point was that both starting point and finishing point for CT are important, so CT does not introduce delays. > So we are talking about a race condition between CT and HO if > we don't know the details of the system, so we base > the definition on CT completion and that is why we > simply say, if the CT is done prior to packet arrival, then > it is proactive, if not it is reactive. I still think this is questionable, given my objections above to the notion of "packet arrival". > two months ago, I was screaming for an event sequence out of > the handoveer procedure for timing requirement, > I suggested to define CT triggers and CT deadline based on the > event sequence First, the deadline for various kinds of context transfer will be different. Secong, the context transfer protocol might be definable without regard to the specific kind of trigger. For layer-2 triggers, this seems pretty clear! MN>> sure, the starts might be different too, we are trying to define abstract events, both trigger and deadline without getting into specific technologies. But we are closely tied to handovers (at least for scope of CT-seamoby) and so it makes sense if our events come from handover events. My question has been whether the group feels we can borrow these events from Mobile IP handovers (at layer 3)? > ****Unless you offer a clear event sequence and show different Handover > stages and the need of packet delivery for various feature context, > I don't think we can change our definition and base it on an start > event.***** I'm not sure if my example would be welcome, but here goes anyway: 1) Mobile node shows up at new access router (802.11, say) 2) Mobile node asks new access router to collect context from previous router. Mobile includes authentication data that can be checked by previous access router. 3) New access router sends request for context transfer to previous router. 4) Previous access router checks the authentication data, and upon approval delivers the requested context features 5) New access router installs the delivered context features, and (optionally) notifies the mobile node about the status. This is reactive, and it could be very valuable for certain kinds of context. MN>> what if the newAR receives notification about an iminent arrival before the MN actually arrives at the newAR. This is common in cellular! Which category does this fall into? Proactive? If your proactive includes this, then we are fine. > As I said in my other email: > It seems you are questioning the usefulness of CT and its role > on the timing of the events, if you think the packets can be > delivered and then you establish HC context and re-negotiate authentication > and other things, then why is CT timing so critical, you are contradicting > yourself. I'm really puzzled by this question. There is a certain time budget (say, as defined by the VoIP parameters). It would be nice to have the fastest possible context transfer in order to remain within that time budget. It's easier to do so with proactive context transfer. It's still possible to do so with reactive context transfer. Not all systems will support proactive context transfer. MN>> Well, I said that since Rajeev was dismissing the possibility of having the context to handle packets in time. I agree not all systems/ scnearios could support proactive, but does that mean we exclude it? Am I missing the point of your question?? MN>> My question was, don't you think CT should have timing requirements, so it introduces zero (proactive) or as little delay as possible. Don't take me wrong, I don't know enough about all the features to believe 100% in zero delay, but it is a scenario, that should be included. Regards, Madjid From owner-seamoby@diameter.org Fri Jun 22 19:43: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 TAA15414 for ; Fri, 22 Jun 2001 19:43:56 -0400 (EDT) Received: (qmail 29659 invoked by alias); 22 Jun 2001 23:32:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29653 invoked by uid 200); 22 Jun 2001 23:32:24 -0000 Received: (qmail 29648 invoked by uid 500); 22 Jun 2001 23:32:22 -0000 Date: Fri, 22 Jun 2001 16:32:22 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] [Issue] Should Nagle be used instead of 5.4.6? Message-ID: <20010622163221.T14828@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 Should Nagle be used instead of 5.4.6? Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: June 22, 2001 Reference: Comment type: T Priority: 2 Section: 5.4.6 Rationale/Explanation of issue: I have a question about the following requirement, which I brought up once, but now my objection is a little clearer, I think. "5.4.6 The context transfer protocol MUST support the aggregation of multiple contexts." The issue that I had previously with this one is that transport protocols such as TCP and STCP commonly combine data sent to a common destination if the data is ready within a very small window. This is known as Nagle Algorithm (see section 2.3 of draft-ietf-aaa-transport-04.txt for more info). My point is that the transport can do this, and I see no reason why CT needs to also handle this case. I have another objection. In most cases, as we agree, latency introduced by CT MUST be minimized. I would claim that most environments could easily handle each CT instance as a separate thread, and work independently. For real-time OSes that do not have such rich features as threaded environments, Nagle still provides batching at the transport layer. Requested change: So, having said that, I believe that we should do one of a few options: 1. leave it as is 2. Remove the requirement 3. Re-word the requirement to state that if the transport selected does not support the Nagle algorithm, than this requirement holds. From owner-seamoby@diameter.org Fri Jun 22 23:18: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 XAA20836 for ; Fri, 22 Jun 2001 23:18:52 -0400 (EDT) Received: (qmail 30263 invoked by alias); 23 Jun 2001 03:05:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30257 invoked by uid 200); 23 Jun 2001 03:05:49 -0000 Received: (qmail 30252 invoked from network); 23 Jun 2001 03:05:47 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jun 2001 03:05:47 -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 UAA14322; Fri, 22 Jun 2001 20:16:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5N3GLB11714; Fri, 22 Jun 2001 20:16:21 -0700 X-mProtect: Fri, 22 Jun 2001 20:16:21 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd06NurO; Fri, 22 Jun 2001 20:16:19 PDT Message-ID: <3B3409C3.6181AB63@iprg.nokia.com> Date: Fri, 22 Jun 2001 20:15:15 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DF0@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 Madjid, > - A link establishment has occurred when a mobile node becomes > able to send a packet to the access router > > This does NOT say that the mobile node is REQUIRED to send > a layer-3 packet before the link is established -- only that > it _could_ send a layer-3 packet. > > MN>> I am not sure if I understand the sentence above, but > I take it as, by link establishment you mean the MN is able > to send and receive L3 packets. If a node can receive a layer-2 packet, then it could conceivably receive a layer-3 packet. And, same for transmission. This is separate from whether it's authorized to use the particular layer-3 address. So, I don't think I see the difference. Can you explain more? > Basing the definitions on link establishment avoids completely any > questions about Mobile IP. > > MN>> Please see my earlier email on the 3 cases. O.K., but can you give me a handle (say, the date)? > MN>> I agree, however, it is not very hard to change it, to say > Packet arrival at newAR (since that is what matters for CT). > Not having feature contexts might make the packet arrival defintion > fuzzier if you don't know how to interprete packets. > However, as I said you can replace packet arrival with an > almost equivalent event (say another message that makes packets arrive > at newAR). Somehow, though, this seems to miss the point. For reactive, the context transfer should be reacting to something -- say, the arrival of a mobile node at the new access network. Whether this arrival is determined by the transmission of a layer-3 packet is important, yet necessarily comes after the arrival. On the other hand, by protocol the only way we can detect the arrival is by some packet being sent somewhere. That's why I tried to make the definition in terms of the _ability_ of the mobile node to send a packet. I'm curious how a message could be delivered to enable packets, when the message itself has to be the content of a packet. This makes me think that we are using different definitions for what a "packet" is supposed to be. For me it's a bag of bits, and can be used at layer 2. > MN>>point was to define a deadline for CT to be complete, and > basing everything on the starting event, does not provide any > timing requirements for CT, unless you want to leave it open > for now. I suggest that the starting event is the right way, and that all of the protocols involved have to be robust enough to work anyway if something takes longer. We should just make it work as fast as we can. > Of course everyone wants to have reliable predictive handovers. > But for systems that cannot fit within that design parameter > it would still be nice to have fast reactive handovers. It is > not a fair criticism of reactive handover to insist that proactive > is better. And similarly for reactive context transfer. > > MN>> Sure, my point was that both starting point and finishing point > for CT are important, so CT does not introduce delays. Yes those are important points in time, but maybe it's enough to define reactive in terms of whether the _start_ of context transfer happens before or after the mobile node arrives at the new access network. > > So we are talking about a race condition between CT and HO if > > we don't know the details of the system, so we base > > the definition on CT completion and that is why we > > simply say, if the CT is done prior to packet arrival, then > > it is proactive, if not it is reactive. If packets arrive for the mobile node before the context is fully transferred, then the penalty should be lost performance, not lost packets. Basing the definitions on "completion" would mean, for instance, that the previous access router couldn't really be sure what kind of context transfer was happening. After all, the previous access router cannot be sure of the order of arrival of handover packets vs. context transfer packets, even if it is sure of the order in which they were transmitted. Plus we have to worry about what happens when CT packets are lost or when handover control packets are lost, if the system design admits this possibility. > First, the deadline for various kinds of context transfer > will be different. Secong, the context transfer protocol > might be definable without regard to the specific kind of > trigger. For layer-2 triggers, this seems pretty clear! > > MN>> sure, the starts might be different too, we are trying > to define abstract events, both trigger and deadline without > getting into specific technologies. But we are closely tied > to handovers (at least for scope of CT-seamoby) and so > it makes sense if our events come from handover events. > My question has been whether the group feels we can borrow > these events from Mobile IP handovers (at layer 3)? In Mobile IP, we defined 4 scenarios. They were very useful: - Mobile initiated after departure - Network initiated after departure - Mobile initiated before departure - Network initiated before departure Context transfer can be sensible in all four of these cases. > > ****Unless you offer a clear event sequence and show different Handover > > stages and the need of packet delivery for various feature context, > > I don't think we can change our definition and base it on an start > > event.***** > > I'm not sure if my example would be welcome, but here goes > anyway: > > 1) Mobile node shows up at new access router (802.11, say) > 2) Mobile node asks new access router to collect context > from previous router. Mobile includes authentication data > that can be checked by previous access router. > 3) New access router sends request for context transfer to > previous router. > 4) Previous access router checks the authentication data, and > upon approval delivers the requested context features > 5) New access router installs the delivered context features, > and (optionally) notifies the mobile node about the status. > > This is reactive, and it could be very valuable for certain > kinds of context. > > MN>> what if the newAR receives notification about an iminent > arrival before the MN actually arrives at the newAR. This is > common in cellular! Which category does this fall into? > Proactive? If your proactive includes this, then we are fine. By my understanding, this would be proactive; I am guessing that the new access router receives context information as well as the basic indication of the arrival of the mobile node. But that amounts to an (important!) optimization. > MN>> Well, I said that since Rajeev was dismissing the > possibility of having the context to handle packets in time. > I agree not all systems/ scnearios could support proactive, but > does that mean we exclude it? I definitely propose that we not exclude reactive context transfer. > MN>> My question was, don't you think CT should have timing > requirements, so it introduces zero (proactive) or as little > delay as possible. Don't take me wrong, I don't know enough > about all the features to believe 100% in zero delay, but it > is a scenario, that should be included. I think that context transfer should be optimized for the best performance in time. I don't see how you can realistically put absolute time bounds on the process, though. What would it be? 30ms? 300ms? Shouldn't the same protocol work for transferring video context as well as audio context (if there needed to be such a thing)? Regards, Charlie P. From owner-seamoby@diameter.org Sat Jun 23 03:37:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08161 for ; Sat, 23 Jun 2001 03:37:21 -0400 (EDT) Received: (qmail 30920 invoked by alias); 23 Jun 2001 07:25:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30914 invoked by uid 200); 23 Jun 2001 07:25:37 -0000 Received: (qmail 30906 invoked from network); 23 Jun 2001 07:25:35 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jun 2001 07:25:35 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 03:36:10 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8075@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Should Nagle be used instead of 5.4.6? Date: Sat, 23 Jun 2001 03:36:09 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, June 22, 2001 7:32 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] [Issue] Should Nagle be used instead of 5.4.6? > > > Should Nagle be used instead of 5.4.6? > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: June 22, 2001 > Reference: > Comment type: T > Priority: 2 > Section: 5.4.6 > Rationale/Explanation of issue: > > I have a question about the following requirement, which I > brought up once, > but now my objection is a little clearer, I think. > > "5.4.6 The context transfer protocol MUST support the aggregation of > multiple contexts." > > The issue that I had previously with this one is that > transport protocols > such as TCP and STCP commonly combine data sent to a common > destination > if the data is ready within a very small window. This is known as > Nagle Algorithm (see section 2.3 of > draft-ietf-aaa-transport-04.txt for > more info). > > My point is that the transport can do this, and I see no reason why CT > needs to also handle this case. > > I have another objection. In most cases, as we agree, latency > introduced by > CT MUST be minimized. I would claim that most environments > could easily > handle each CT instance as a separate thread, and work > independently. For > real-time OSes that do not have such rich features as > threaded environments, > Nagle still provides batching at the transport layer. > > Requested change: > > So, having said that, I believe that we should do one of a > few options: > 1. leave it as is > 2. Remove the requirement > 3. Re-word the requirement to state that if the transport > selected does not > support the Nagle algorithm, than this requirement holds. > I have had the same thoughts, but I wanted to wait for the outcome of the transport selection process. I would aggree with option 3. - Kulwinder. > From owner-seamoby@diameter.org Sat Jun 23 03:43:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08195 for ; Sat, 23 Jun 2001 03:43:08 -0400 (EDT) Received: (qmail 31385 invoked by alias); 23 Jun 2001 07:31:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31379 invoked by uid 200); 23 Jun 2001 07:31:20 -0000 Received: (qmail 31374 invoked from network); 23 Jun 2001 07:31:18 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jun 2001 07:31:18 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 03:41:54 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8076@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: "'seamoby@cdma-2000.org'" Subject: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Sat, 23 Jun 2001 03:41:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk -----Original Message----- From: kalatwal [mailto:katwal@zucotto.com] Sent: Saturday, June 23, 2001 3:10 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: 'seamoby@cdma-2000.org' Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, June 22, 2001 7:02 PM > To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > > > MN>>point was to define a deadline for CT to be complete, and > basing everything on the starting event, does not provide any > timing requirements for CT, unless you want to leave it open > for now. As I have said many, many times on the Design Team list these 'timing requirements' are not necessary, and unworkable in a heterogenous network. I fully agree with everything that Charlie has said in his last email. > > MN>> Sure, my point was that both starting point and finishing point > for CT are important, so CT does not introduce delays. They are only important if you are unwilling to design a state machine for the protocol to accommodate an imperfect world. The packet exchange for context transfer can be the same for proactive and reactive. The only thing that is really different is where the context request comes from. With Multi-Phasic Context Transfer there is really no difference between the Reactive or Proactive packet exchanges other than where the request comes from. I believe we should drop the terms Proactive and Reactive since some people seem to attach them to events in MIP like HandOver. And, then use HandOver to unnecessarily constrain the design of CTP. I would much rather see a protocol that allowed things to happen as fast as hardware will allow rather than wait for some artificial protocol event. The problem with waiting for HO is that it only works well if your network has been tightly engineered from the beginning. This expectation does not hold true for private wireless networks connected to Ethernet LANs where packet collisions could re-arrange the packet order of HO and CT. I would like the terms Proactive and Reactive replaced by packet order neutral terms: Pre-Connection Context Transfer: The Context Transfer is initiated prior to the newAR recieving a packet directly from the MN. Post-Connection Context Transfer: The Context Transfer is initiated after the newAR recieves a packet directly from the MN. But, really why should we care where the request for CT comes from if we are going to process it just the same? The only thing that is important is that the requesting entity recieve a packet indicating the success or failure mode of the CT operation. - Kulwinder. > Regards, > Madjid > From owner-seamoby@diameter.org Sat Jun 23 05:56: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 FAA08865 for ; Sat, 23 Jun 2001 05:56:37 -0400 (EDT) Received: (qmail 31995 invoked by alias); 23 Jun 2001 09:44:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31989 invoked by uid 200); 23 Jun 2001 09:44:50 -0000 Received: (qmail 31984 invoked from network); 23 Jun 2001 09:44:48 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jun 2001 09:44:48 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 05:55:24 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8077@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Sat, 23 Jun 2001 05:55:24 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, June 22, 2001 7:02 PM > To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Hi Charlie, > > Comments below (MN>>) > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 21, 2001 3:40 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and > reactive CT definitions > > > > Hello Madjid, > > > MN>> I am not sure if I understand the sentence above, but > I take it as, by link establishment you mean the MN is able > to send and receive L3 packets. > The reason we picked Handover, was so we knew whether we were > introducing latency into handovers or not. > I don't know who 'we' are, but as a member of the Design Team I certainly do not recall 'picking' Handover to mean that we would sequentially hard code parrallel asynchronous events. I do recall argueing strongly against _any_ ordering of events that are not a direct part of CT and having the text changed to reflect it. But, I suppose that the changes did not go far enough. > MN>> My question was, don't you think CT should have timing > requirements, so it introduces zero (proactive) or as little > delay as possible. This is wishful thinking. It is impossible to guarrantee in a heterogenous network. We cannot guarrantee how long something will take, where our mobile device will be, or the sequence of packet arrival (events). We can hope for the best, but we need to plan for the worst (even with proactive). > Don't take me wrong, I don't know enough > about all the features to believe 100% in zero delay, but it > is a scenario, that should be included. Even if you are late the end-user will never notice, as long as the packet is delivered to the MN within the tolerable interpacket jitter of the Real-Time stream. This is the _REAL_ deadline, and it depends on which Real-Time streams you choose to support. If the parentAR is heavily loaded with other tasks on a private wireless network such that each route change message arrives 1 mSec after the CT on a direct route between newAR and oldAR should proactive CT always fail? Is dealing with this Proactive 'error' condition not more complicated than simply removing this restriction? Will having to deal with this 'error' condition not introduce more delay? This protocol will fail to operate in a private wireless network with requirements 5.4.1 and 5.4.2. There is no way to gaurantee the sequence of packet arrival in every type of wired/wireless network where this protocol may be used. - Kulwinder. > > Regards, > Madjid > From owner-seamoby@diameter.org Sat Jun 23 13:24: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 NAA13682 for ; Sat, 23 Jun 2001 13:24:31 -0400 (EDT) Received: (qmail 556 invoked by alias); 23 Jun 2001 17:12:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 549 invoked by uid 200); 23 Jun 2001 17:12:47 -0000 Received: (qmail 544 invoked from network); 23 Jun 2001 17:12:46 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jun 2001 17:12:46 -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 LAA22283; Sat, 23 Jun 2001 11:23:50 -0600 (MDT) Received: from awe171-106 (awe195-63.AWE.Sun.COM [192.29.195.63]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA26127; Sat, 23 Jun 2001 10:23:50 -0700 (PDT) Message-Id: <200106231723.KAA26127@heliopolis.eng.sun.com> Date: Sat, 23 Jun 2001 09:15:28 -0700 (PDT) From: kempf Reply-To: kempf Subject: Re: [seamoby] Question on 4.2 To: seamoby@cdma-2000.org, pcalhoun@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jwll+QSxfjD0rYyXktDSwg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk Pat, A bunch of us are in discussion about doing a draft on abstract L2 triggers. Currently, there is some unpublished material and the material embedded in the FMIPv4 draft that we would like to pull together. This should allow people to refer to a common source on L2 triggers. We are unclear yet whether this belongs in MIP, Seamoby, or other. It is clearly important for the MIP fast handoff work, and also perhaps Seamoby context transfer. jak >Delivered-To: seamoby-list@charizard.diameter.org >Date: Tue, 19 Jun 2001 16:51:22 -0700 >From: Pat Calhoun >To: seamoby@cdma-2000.org >Subject: [seamoby] Question on 4.2 >Mail-Followup-To: seamoby@cdma-2000.org >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >I do recall a recent discussion on this, so I appologize if this has already >come up. Does the following text, which appears under section 4.2, imply that >seamoby will define the triggers? > >" This implies that there are general > characteristics of an IP level trigger that need to be defined so > that the triggers generated by different layer 2 solutions will have > identical semantics at the IP level." > >PatC From owner-seamoby@diameter.org Sat Jun 23 17:06: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 RAA17445 for ; Sat, 23 Jun 2001 17:06:31 -0400 (EDT) Received: (qmail 1270 invoked by alias); 23 Jun 2001 20:53:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1264 invoked by uid 200); 23 Jun 2001 20:53:06 -0000 Received: (qmail 1259 invoked from network); 23 Jun 2001 20:53:05 -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; 23 Jun 2001 20:53:05 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5NL3S017997 for ; Sat, 23 Jun 2001 17:03:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Sat, 23 Jun 2001 17:03:38 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 17:03:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D83@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Sat, 23 Jun 2001 17:03:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FC27.F9A50700" 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_01C0FC27.F9A50700 Content-Type: text/plain; charset="iso-8859-1" Hmmm. I though I was clear. I only disagree with both halves of the proposal.... Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, June 22, 2001 4:51 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'Charlie Perkins'; Pat Calhoun; seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > > On Fri, Jun 22, 2001 at 03:38:50PM -0400, Gary Kenward wrote: > > Pat: > > > > The debate has been centered so much around the > definition of reactive, > > I missed the change in proactive. I agree with Charlie, in > no way should > > proactive ct be required to end at some particular event. We have a > > requirement > > that ct should not delay handover. It is unrealistic to > believe that ct will > > > > *never* delay handover and attempting too set a termination > limit is just as > > unrealistic. > > so you are in agreement with the whole change, or just portions of? > > PatC > > > > > Gary > > > > > -----Original Message----- > > > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > > > Sent: Friday, June 22, 2001 12:38 AM > > > To: Pat Calhoun > > > Cc: seamoby@cdma-2000.org > > > Subject: Re: [seamoby] proactive and reactive CT definitions > > > > > > > > > > > > Hello Pat, > > > > > > > > So, here is the proposal for revised definitions: > > > > > > > > > > Reactive CT: The context transfer process which takes > > > place subsequent to the MN > > > > > establishing a new link with the new AR. > > > > > > > > > > Proactive CT: The context transfer process in which the > > > contexts are present at > > > > > the new AR prior to the arrival of MN's packets at the new AR. > > > > > > I would suggest that for Proactive context transfer, we > > > should allow for the > > > possibility that some of the context may still be in transit > > > when packets begin > > > to arrive for the mobile node at the new access router. > > > > > > One other characteristic is that reactive is a "context pull" > > > operation, > > > and proactive is a "context push" operation. They could > still both > > > use the same protocol message to deliver the context, though. > > > In other words, as I understand "proactive", the previous access > > > router predictively sends the context to a new access router > > > (selected by some unspecified means, presumably initiated by > > > some radio network controller). Reactive transfer, on the other > > > hand, would typically be initiated by the new access router > > > sending a request for context transfer to the previous access > > > router. In many systems that reactive request might actually > > > be triggered by a message from the mobile node, but the > > > actual context transfer request would more likely seem to have > > > emanated from the new access router. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > ------_=_NextPart_001_01C0FC27.F9A50700 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] proactive and reactive CT definitions

Hmmm. I though I was clear. I only disagree with both halves of the proposal....
Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Friday, June 22, 2001 4:51 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Charlie Perkins'; Pat Calhoun; seamoby@cdma-2000.org
> Subject: Re: [seamoby] proactive and reactive CT definitions
>
>
> On Fri, Jun 22, 2001 at 03:38:50PM -0400, Gary Kenward wrote:
> > Pat:
> > 
> >   The debate has been centered so much around the
> definition of reactive,
> > I missed the change in proactive. I agree with Charlie, in
> no way should
> > proactive ct be required to end at some particular event. We have a
> > requirement
> > that ct should not delay handover. It is unrealistic to
> believe that ct will
> >
> > *never* delay handover and attempting too set a termination
> limit is just as
> > unrealistic.
>
> so you are in agreement with the whole change, or just portions of?
>
> PatC
>
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> > > Sent: Friday, June 22, 2001 12:38 AM
> > > To: Pat Calhoun
> > > Cc: seamoby@cdma-2000.org
> > > Subject: Re: [seamoby] proactive and reactive CT definitions
> > >
> > >
> > >
> > > Hello Pat,
> > >
> > > > > So, here is the proposal for revised definitions:
> > > > >
> > > > > Reactive CT: The context transfer process which takes
> > > place subsequent to the MN
> > > > > establishing a new link with the new AR.
> > > > >
> > > > > Proactive CT: The context transfer process in which the
> > > contexts are present at
> > > > > the new AR prior to the arrival of MN's packets at the new AR.
> > >
> > > I would suggest that for Proactive context transfer, we
> > > should allow for the
> > > possibility that some of the context may still be in transit
> > > when packets begin
> > > to arrive for the mobile node at the new access router.
> > >
> > > One other characteristic is that reactive is a "context pull"
> > > operation,
> > > and proactive is a "context push" operation.  They could
> still both
> > > use the same protocol message to deliver the context, though.
> > > In other words, as I understand "proactive", the previous access
> > > router predictively sends the context to a new access router
> > > (selected by some unspecified means, presumably initiated by
> > > some radio network controller).  Reactive transfer, on the other
> > > hand, would typically be initiated by the new access router
> > > sending a request for context transfer to the previous access
> > > router.  In many systems that reactive request might actually
> > > be triggered by a message from the mobile node, but the
> > > actual context transfer request would more likely seem to have
> > > emanated from the new access router.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > >
> > >
>

------_=_NextPart_001_01C0FC27.F9A50700-- From owner-seamoby@diameter.org Mon Jun 25 00:02: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 AAA21216 for ; Mon, 25 Jun 2001 00:02:13 -0400 (EDT) Received: (qmail 8569 invoked by alias); 25 Jun 2001 03:50:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8563 invoked by uid 200); 25 Jun 2001 03:50:12 -0000 Received: (qmail 8555 invoked by uid 500); 25 Jun 2001 03:50:11 -0000 Date: Sun, 24 Jun 2001 20:50:11 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010624205011.B14828@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8076@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8076@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Sat, Jun 23, 2001 at 03:41:53AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk > > > > MN>> Sure, my point was that both starting point and finishing point > > for CT are important, so CT does not introduce delays. > > They are only important if you are unwilling to design a state machine for > the protocol to accommodate an imperfect world. > > The packet exchange for context transfer can be the same for proactive and > reactive. > The only thing that is really different is where the context request comes > from. > > With Multi-Phasic Context Transfer there is really no difference between the > Reactive or Proactive packet exchanges other than where the request comes > from. > > I believe we should drop the terms Proactive and Reactive since some people > seem to attach them to events in MIP like HandOver. And, then use HandOver > to unnecessarily constrain the design of CTP. > > I would much rather see a protocol that allowed things to happen as fast as > hardware will allow rather than wait for some artificial protocol event. > The problem with waiting for HO is that it only works well if your network > has been tightly engineered from the beginning. > > This expectation does not hold true for private wireless networks connected > to Ethernet LANs where packet collisions could re-arrange the packet order > of HO and CT. > > I would like the terms Proactive and Reactive replaced by packet order > neutral terms: > > Pre-Connection Context Transfer: The Context Transfer is initiated prior to > the newAR recieving a packet directly from the MN. > > Post-Connection Context Transfer: The Context Transfer is initiated after > the newAR recieves a packet directly from the MN. *this* I like! However, I disagree with your view on handoffs. I would like the pre-handoff and post-handoff context transfer. Pre or post first packet doesn't make any sense *at all* to me. How can you guarantee, or know, when the first packet will be received?!? In all cases that I know of, some signalling, either at L2 or L3, is used to register the mobile locally (or some signal strength measurements), but there is always an indication of handoff. > But, really why should we care where the request for CT comes from if we are > going to process it just the same? > > The only thing that is important is that the requesting entity recieve a > packet indicating the success or failure mode of the CT operation. ditto. PatC From owner-seamoby@diameter.org Mon Jun 25 01:19: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 BAA22639 for ; Mon, 25 Jun 2001 01:19:37 -0400 (EDT) Received: (qmail 9083 invoked by alias); 25 Jun 2001 05:07:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9077 invoked by uid 200); 25 Jun 2001 05:07:39 -0000 Received: (qmail 9072 invoked from network); 25 Jun 2001 05:07:37 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 05:07:37 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 01:18:17 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F807B@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Kulwinder Atwal Cc: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Mon, 25 Jun 2001 01:18:00 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Sunday, June 24, 2001 11:50 PM > To: Kulwinder Atwal > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > > > > > MN>> Sure, my point was that both starting point and > finishing point > > > for CT are important, so CT does not introduce delays. > > > > They are only important if you are unwilling to design a > state machine for > > the protocol to accommodate an imperfect world. > > > > The packet exchange for context transfer can be the same > for proactive and > > reactive. > > The only thing that is really different is where the > context request comes > > from. > > > > With Multi-Phasic Context Transfer there is really no > difference between the > > Reactive or Proactive packet exchanges other than where the > request comes > > from. > > > > I believe we should drop the terms Proactive and Reactive > since some people > > seem to attach them to events in MIP like HandOver. And, > then use HandOver > > to unnecessarily constrain the design of CTP. > > > > I would much rather see a protocol that allowed things to > happen as fast as > > hardware will allow rather than wait for some artificial > protocol event. > > The problem with waiting for HO is that it only works well > if your network > > has been tightly engineered from the beginning. > > > > This expectation does not hold true for private wireless > networks connected > > to Ethernet LANs where packet collisions could re-arrange > the packet order > > of HO and CT. > > > > I would like the terms Proactive and Reactive replaced by > packet order > > neutral terms: > > > > Pre-Connection Context Transfer: The Context Transfer is > initiated prior to > > the newAR recieving a packet directly from the MN. > > > > Post-Connection Context Transfer: The Context Transfer is > initiated after > > the newAR recieves a packet directly from the MN. > > *this* I like! However, I disagree with your view on handoffs. I would > like the pre-handoff and post-handoff context transfer. Pre > or post first > packet doesn't make any sense *at all* to me. How can you > guarantee, or know, > when the first packet will be received?!? I can't. How early to do Pre-Connection Context Transfer to get seamless transfer is implementation specific. The viewpoint is the newAR. Either the newAR is notified for a need to CT from oldAR, or MN. The difference is on what interface the newAR is notified. It is up to the implementor to take into account particular network and inter-network characteristics and real-time flow requirements to determine how early Pre-Connection Context Transfer needs to be done to guarrantee seamless. - Kulwinder. > In all cases that I > know of, some > signalling, either at L2 or L3, is used to register the > mobile locally (or > some signal strength measurements), but there is always an > indication of handoff. > > > > But, really why should we care where the request for CT > comes from if we are > > going to process it just the same? > > > > The only thing that is important is that the requesting > entity recieve a > > packet indicating the success or failure mode of the CT operation. > > ditto. > > PatC > From owner-seamoby@diameter.org Mon Jun 25 08:48: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 IAA13666 for ; Mon, 25 Jun 2001 08:48:09 -0400 (EDT) Received: (qmail 11201 invoked by alias); 25 Jun 2001 12:36:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11194 invoked by uid 200); 25 Jun 2001 12:36:40 -0000 Received: (qmail 11189 invoked from network); 25 Jun 2001 12:36:38 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 12:36:38 -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 f5PCkr923578 for ; Mon, 25 Jun 2001 15:46:53 +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, 25 Jun 2001 15:47:46 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 25 Jun 2001 15:47:48 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1081077AB@eseis04nok> From: john.loughney@nokia.com To: Madjid.Nakhjiri@motorola.com Cc: seamoby@diameter.org Subject: RE: [seamoby] Reactive context transfer Date: Mon, 25 Jun 2001 15:47:41 +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, > Why is explicit messaging so important, it might even > add more delay. I think we should go after the event that > triggers this signaling (implicit or explicit is less important > IMHO). I was just seperating the concepts out. I don't like explicit signaling either. John From owner-seamoby@diameter.org Mon Jun 25 10:13: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 KAA16183 for ; Mon, 25 Jun 2001 10:13:22 -0400 (EDT) Received: (qmail 11937 invoked by alias); 25 Jun 2001 14:01:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11931 invoked by uid 200); 25 Jun 2001 14:01:19 -0000 Received: (qmail 11924 invoked by uid 500); 25 Jun 2001 14:01:17 -0000 Date: Mon, 25 Jun 2001 07:01:17 -0700 From: Pat Calhoun To: Charlie Perkins Cc: Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions Message-ID: <20010625070117.J14828@charizard.diameter.org> Mail-Followup-To: Charlie Perkins , Nakhjiri Madjid-MNAKHJI1 , seamoby@cdma-2000.org References: <35DBB8B7AC89D4118E98009027B1009B017A9DF0@IL27EXM10.cig.mot.com> <3B3409C3.6181AB63@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3409C3.6181AB63@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Jun 22, 2001 at 08:15:15PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > I think that context transfer should be optimized for the best > performance in time. I don't see how you can realistically put > absolute time bounds on the process, though. What would it > be? 30ms? 300ms? Shouldn't the same protocol work for > transferring video context as well as audio context (if there needed > to be such a thing)? I've been in agreement with this since day one. PatC From owner-seamoby@diameter.org Mon Jun 25 11:10:37 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17616 for ; Mon, 25 Jun 2001 11:10:36 -0400 (EDT) Received: (qmail 12562 invoked by alias); 25 Jun 2001 14:47:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12556 invoked by uid 200); 25 Jun 2001 14:47:13 -0000 Received: (qmail 12551 invoked from network); 25 Jun 2001 14:47:11 -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; 25 Jun 2001 14:47:11 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5PEvW007098 for ; Mon, 25 Jun 2001 10:57:35 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 25 Jun 2001 10:57:15 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 10:57:18 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D86@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@cdma-2000.org'" Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Mon, 25 Jun 2001 10:56:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FD87.107306C0" 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_01C0FD87.107306C0 Content-Type: text/plain; charset="iso-8859-1" The purpose of ct is to enhance handover. If there are no timing constraints, then it's not worth doing. I think, Kulwinder, that you are arguing a matter of degree, and I agree with your concerns. But, homogenous, or heterogeneous, it would seem logical to say that ct should happen as fast as possible, and that, if it is to actually help handover (the "s" word comes to mind here), then it handover should not take longer with ct then without. Yeah, I know, "what's a handover" and "when does it end", etc., etc. We seem to be masters of circular dialectic. It seem to me that when we began all of this, we shared a common interest in solving the problem. Now we all seem preoccupied with semantics. May I suggest that if the ambiguity of "handover" is the issue, then let's attempt to define it, for I am positive that ct without handover is like bungee jumping without gravity - you can do it, but what's the point? Just trying to move forward, Gary > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Saturday, June 23, 2001 5:55 AM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Friday, June 22, 2001 7:02 PM > > To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1 > > Cc: seamoby@cdma-2000.org > > Subject: RE: [seamoby] CT trigger or CT completion? was: > proactive and > > re active CT definitions > > > > > > Hi Charlie, > > > > Comments below (MN>>) > > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Thursday, June 21, 2001 3:40 PM > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: seamoby@cdma-2000.org > > Subject: Re: [seamoby] CT trigger or CT completion? was: > proactive and > > reactive CT definitions > > > > > > > > Hello Madjid, > > > > > > MN>> I am not sure if I understand the sentence above, but > > I take it as, by link establishment you mean the MN is able > > to send and receive L3 packets. > > The reason we picked Handover, was so we knew whether we were > > introducing latency into handovers or not. > > > > I don't know who 'we' are, but as a member of the Design Team > I certainly do > not recall 'picking' Handover to mean that we would > sequentially hard code > parrallel asynchronous events. > > I do recall argueing strongly against _any_ ordering of > events that are not > a direct part of CT and having the text changed to reflect it. But, I > suppose that the changes did not go far enough. > > > MN>> My question was, don't you think CT should have timing > > requirements, so it introduces zero (proactive) or as little > > delay as possible. > > This is wishful thinking. It is impossible to guarrantee in > a heterogenous > network. > > We cannot guarrantee how long something will take, where our > mobile device > will be, or the sequence of packet arrival (events). We can > hope for the > best, but we need to plan for the worst (even with proactive). > > > Don't take me wrong, I don't know enough > > about all the features to believe 100% in zero delay, but it > > is a scenario, that should be included. > > Even if you are late the end-user will never notice, as long > as the packet > is delivered to the MN within the tolerable interpacket jitter of the > Real-Time stream. > > This is the _REAL_ deadline, and it depends on which > Real-Time streams you > choose to support. > > If the parentAR is heavily loaded with other tasks on a > private wireless > network such that each route change message arrives 1 mSec > after the CT on a > direct route between newAR and oldAR should proactive CT always fail? > > Is dealing with this Proactive 'error' condition not more > complicated than > simply removing this restriction? Will having to deal with > this 'error' > condition not introduce more delay? > > This protocol will fail to operate in a private wireless network with > requirements 5.4.1 and 5.4.2. > > There is no way to gaurantee the sequence of packet arrival > in every type of > wired/wireless network where this protocol may be used. > > > - Kulwinder. > > > > > Regards, > > Madjid > > > ------_=_NextPart_001_01C0FD87.107306C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] CT trigger or CT completion? was: proactive and re = active CT definitions

The purpose of ct is to enhance handover. If there = are no timing
constraints, then it's not worth doing.

I think, Kulwinder, that you are arguing a matter of = degree, and I
agree with your concerns. But, homogenous, or = heterogeneous, it would
seem logical to say that ct should happen as fast as = possible, and
that, if it is to actually help handover (the = "s" word comes to mind
here), then it handover should not take longer with = ct then without.

Yeah, I know, "what's a handover" and = "when does it end", etc., etc.
We seem to be masters of circular dialectic. It seem = to me that when
we began all of this, we shared a common interest in = solving the problem.
Now we all seem preoccupied with semantics.

May I suggest that if the ambiguity of = "handover" is the issue, then
let's attempt to define it, for I am positive that = ct without handover
is like bungee jumping without gravity - you can do = it, but what's the
point?

Just trying to move forward,
Gary

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucot= to.com]
> Sent: Saturday, June 23, 2001 5:55 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. = Perkins'
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] CT trigger or CT = completion? was: proactive and
> re active CT definitions
>
>
>
>
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> > Sent: Friday, June 22, 2001 7:02 PM
> > To: 'Charles E. Perkins'; Nakhjiri = Madjid-MNAKHJI1
> > Cc: seamoby@cdma-2000.org
> > Subject: RE: [seamoby] CT trigger or CT = completion? was:
> proactive and
> > re active CT definitions
> >
> >
> > Hi Charlie,
> >
> > Comments below (MN>>)
> >
> > -----Original Message-----
> > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> > Sent: Thursday, June 21, 2001 3:40 = PM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: seamoby@cdma-2000.org
> > Subject: Re: [seamoby] CT trigger or CT = completion? was:
> proactive and
> > reactive CT definitions
> >
> >
> >
> > Hello Madjid,
> >
> >
> > MN>> I am not sure if I understand = the sentence above, but
> > I take it as, by link establishment you = mean the MN is able
> > to send and receive L3 packets.
> > The reason we picked Handover, was so we = knew whether we were
> > introducing latency into handovers or = not.
> >
>
> I don't know who 'we' are, but as a member of = the Design Team
> I certainly do
> not recall 'picking' Handover to mean that we = would
> sequentially hard code
> parrallel asynchronous events.
>
> I do recall argueing strongly against _any_ = ordering of
> events that are not
> a direct part of CT and having the text changed = to reflect it.  But, I
> suppose that the changes did not go far = enough.
>
> > MN>> My question was, don't you = think CT should have timing
> > requirements, so  it introduces zero = (proactive) or as little
> > delay as possible.
>
> This is wishful thinking.  It is = impossible to guarrantee in
> a heterogenous
> network.
>
> We cannot guarrantee how long something will = take, where our
> mobile device
> will be, or the sequence of packet arrival = (events).  We can
> hope for the
> best, but we need to plan for the worst (even = with proactive).
>
> > Don't take me wrong, I don't know enough =
> > about all the features to believe 100% in = zero delay, but it
> > is a scenario, that should be = included.
>
> Even if you are late the end-user will never = notice, as long
> as the packet
> is delivered to the MN within the tolerable = interpacket jitter of the
> Real-Time stream. 
>
> This is the _REAL_ deadline, and it depends on = which
> Real-Time streams you
> choose to support.
>
> If the parentAR is heavily loaded with other = tasks on a
> private wireless
> network such that each route change message = arrives 1 mSec
> after the CT on a
> direct route between newAR and oldAR should = proactive CT always fail?
>
> Is dealing with this Proactive 'error' = condition not more
> complicated than
> simply removing this restriction?  Will = having to deal with
> this 'error'
> condition not introduce more delay?
>
> This protocol will fail to operate in a private = wireless network with
> requirements 5.4.1 and 5.4.2. 
>
> There is no way to gaurantee the sequence of = packet arrival
> in every type of
> wired/wireless network where this protocol may = be used.
>
>
> - Kulwinder.
>
> >
> > Regards,
> > Madjid
> >
>

------_=_NextPart_001_01C0FD87.107306C0-- From owner-seamoby@diameter.org Mon Jun 25 11:39:43 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18570 for ; Mon, 25 Jun 2001 11:39:34 -0400 (EDT) Received: (qmail 13117 invoked by alias); 25 Jun 2001 15:25:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13111 invoked by uid 200); 25 Jun 2001 15:25:22 -0000 Received: (qmail 13106 invoked from network); 25 Jun 2001 15:25:20 -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; 25 Jun 2001 15:25:20 -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 f5PFZo013868 for ; Mon, 25 Jun 2001 11:35:50 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 25 Jun 2001 11:35:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 11:35:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D87@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Mon, 25 Jun 2001 11:35:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FD8C.7C426A30" 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_01C0FD8C.7C426A30 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Sunday, June 24, 2001 11:50 PM > To: Kulwinder Atwal > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > *snip* > > Pre-Connection Context Transfer: The Context Transfer is > initiated prior to > > the newAR recieving a packet directly from the MN. > > > > Post-Connection Context Transfer: The Context Transfer is > initiated after > > the newAR recieves a packet directly from the MN. Ok, so what happened to the packets going in the other direction? > > *this* I like! However, I disagree with your view on handoffs. I would > like the pre-handoff and post-handoff context transfer. Pre > or post first > packet doesn't make any sense *at all* to me. How can you > guarantee, or know, > when the first packet will be received?!? In all cases that I > know of, some > signalling, either at L2 or L3, is used to register the > mobile locally (or > some signal strength measurements), but there is always an > indication of handoff. The whole fallacy with the idea of identifying a "concrete" event to base the *definition* of ct on is that there is no event that can be "guaranteed" to work in all possible scenarios. For one, we do not know all possible scenarios. The idea behind "proactive" and "reactive" was not to define two different solutions, but to identify two modes of operation. And, in this, primarily to ensure that some attention was given to prophylactic measures. As the various requirements resolve, it looks to me that ct still needs two modes of operation, call them "A" and "B". In "A", the network uses whatever information is available to determine where traffic handovers might take place, and installs context into those ARs which may be required to handle the traffic. Mode "A" includes an intrinsic presumption of having time available, so the first transfer is probably "static" (or "quasi-static") context - e.g. context that does not change over time, or context that changes slowly or with low probability. For context that changes quickly, or with high probability, high impact (e.g. most likely context that changes between packet arrivals), then there will be a deadline driven transfer of this context. This may or may not be a wise transfer to attempt, but ctp should provide for it, if at all possible. Mode "B" is driven by the assumption that there is little or no time available before the context is needed at the forwarding AR. Whatever scenario one identifies to define the epoch for mode "B", there are always cases where handover events occur with no warning - e.g. the network detects the MN in a completely new coverage are, or the target AR finds "packets in its queue" that must be forwarded. In mode "B", the network must do whatever it can to get the context from old AR to the target AR, as quickly as possible. If it takes seconds to complete the ct, then clearly the handover will not be "seamless" (i.e. no degradation of service). For some services, if it takes 100 ms to re-establish certain feature contexts then the user will be notice the handover. There is a proposal for mode "B" to be multiphasic. This is a good idea, and in fact, the phases appear to be the reverse of the mode "A" phases. The biggest problem with this proposal is that it's premature: it presumes certain timing problems with acquiring the context at the oldAR, and delays in transfer. If all the context can be captured quickly (i.e. in usecs) at the oldAR, and transfer in one "blob", then a multiphasic solution will slow down ct unnecessarily. At this point, the real change in the draft should be to reflect the requirement that ctp should allow for feature contexts to be transferred when it is ready (a configurable option for the system engineer) It matters not what names are given to these modes, what matters is what changes in the requirements on ctp. As for triggers/events: no one trigger/event will ever satisfy everyone, as every wireless network has different capabilities (and it appears, this situation will continue). Just some further sporadic thoughts. Gary > > > > But, really why should we care where the request for CT > comes from if we are > > going to process it just the same? > > > > The only thing that is important is that the requesting > entity recieve a > > packet indicating the success or failure mode of the CT operation. > > ditto. > > PatC > ------_=_NextPart_001_01C0FD8C.7C426A30 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Sunday, June 24, 2001 11:50 PM
> To: Kulwinder Atwal
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
*snip*

> > Pre-Connection Context Transfer: The Context Transfer is
> initiated prior to
> > the newAR recieving a packet directly from the MN.
> >
> > Post-Connection Context Transfer:  The Context Transfer is
> initiated after
> > the newAR recieves a packet directly from the MN.

Ok, so what happened to the packets going in the other direction?

>
> *this* I like! However, I disagree with your view on handoffs. I would
> like the pre-handoff and post-handoff context transfer. Pre
> or post first
> packet doesn't make any sense *at all* to me. How can you
> guarantee, or know,
> when the first packet will be received?!? In all cases that I
> know of, some
> signalling, either at L2 or L3, is used to register the
> mobile locally (or
> some signal strength measurements), but there is always an
> indication of handoff.

The whole fallacy with the idea of identifying a "concrete" event
to base the *definition* of ct on is that there is no event that can
be "guaranteed" to work in all possible scenarios. For one, we do not
know all possible scenarios.

The idea behind "proactive" and "reactive" was not to define two
different solutions, but to identify two modes of operation. And,
in this, primarily to ensure that some attention was given to
prophylactic measures.

As the various requirements resolve, it looks to me that ct still
needs two modes of operation, call them "A" and "B". In "A",
the network uses whatever information is available to determine
where traffic handovers might take place, and installs context
into those ARs which may be required to handle the traffic.

Mode "A" includes an intrinsic presumption of having time available,
so the first transfer is probably "static" (or "quasi-static") context -
e.g. context that does not change over time, or context that changes
slowly or with low probability.

For context that changes quickly, or with high probability, high impact
(e.g. most likely context that changes between packet arrivals), then
there will be a deadline driven transfer of this context. This may or
may not be a wise transfer to attempt, but ctp should provide for it,
if at all possible.

Mode "B" is driven by the assumption that there is little or no time
available before the context is needed at the forwarding AR. Whatever
scenario one identifies to define the epoch for mode "B", there are
always cases where handover events occur with no warning - e.g. the
network detects the MN in a completely new coverage are, or
the target AR finds "packets in its queue" that must be forwarded.
In mode "B", the network must do whatever it can to get the context
from old AR to the target AR, as quickly as possible. If it takes
seconds to complete the ct, then clearly the handover will not be
"seamless" (i.e. no degradation of service). For some services, if
it takes 100 ms to re-establish certain feature contexts then the
user will be notice the handover.

There is a proposal for mode "B" to be multiphasic. This is a good
idea, and in fact, the phases appear to be the reverse of the mode
"A" phases. The biggest problem with this proposal is that it's
premature: it presumes certain timing problems with acquiring the
context at the oldAR, and delays in transfer. If all the context
can be captured quickly (i.e. in usecs) at the oldAR, and transfer
in one "blob", then a multiphasic solution will slow down ct
unnecessarily. At this point, the real change in the draft
should be to reflect the requirement that ctp should allow for
feature contexts to be transferred when it is ready (a configurable
option for the system engineer)

It matters not what names are given to these modes, what matters
is what changes in the requirements on ctp.

As for triggers/events: no one trigger/event will ever satisfy everyone,
as every wireless network has different capabilities (and it appears,
this situation will continue).

Just some further sporadic thoughts.

Gary


>
>
> > But, really why should we care where the request for CT
> comes from if we are
> > going to process it just the same?
> >
> > The only thing that is important is that the requesting
> entity recieve a
> > packet indicating the success or failure mode of the CT operation.
>
> ditto.
>
> PatC
>

------_=_NextPart_001_01C0FD8C.7C426A30-- From owner-seamoby@diameter.org Mon Jun 25 12:28: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 MAA20176 for ; Mon, 25 Jun 2001 12:28:34 -0400 (EDT) Received: (qmail 13714 invoked by alias); 25 Jun 2001 16:16:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13707 invoked by uid 200); 25 Jun 2001 16:16:25 -0000 Received: (qmail 13702 invoked from network); 25 Jun 2001 16:16:23 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 16:16:23 -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 JAA29623; Mon, 25 Jun 2001 09:27:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PGR3x16720; Mon, 25 Jun 2001 09:27:03 -0700 X-mProtect: Mon, 25 Jun 2001 09:27:03 -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 smtpdQnIsCu; Mon, 25 Jun 2001 09:27:01 PDT Message-ID: <3B376655.117117B3@iprg.nokia.com> Date: Mon, 25 Jun 2001 09:27:01 -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: Kulwinder Atwal CC: "'seamoby@cdma-2000.org'" , Pat Calhoun Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F807B@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 Hello Kulwinder, It seems to me that we are getting closer to some definitions that can work. Kulwinder Atwal wrote: > The viewpoint is the newAR. Either the newAR is notified for a need > to CT from oldAR, or MN. > The difference is on what interface the newAR is notified. I agree with this, basically. Please let me know how you think it applies in the following scenario: - Previous access router and new access router agree that the mobile node should move to the new access router. - Mobile node is told to move (after this, connectivity between mobile node and previous access router may fail) - Access network controller tells new access router to allocate spectrum for mobile node - New access router asks previous access router for context - At the same time, mobile node detects beacon from new access router and carries out operations for link establishment - Before finalizing the process of link establishment and the installation of the transferred context features, the new access router verifies the credentials of the mobile node. How do you think this scenario applies to your classification? My answer, is that this is reactive. The new access router is reacting to the information that the mobile node has arrived. I hope we can make definitions to enable the protocol solution I have outlined, since it my favorite scenario and I believe it is compatible with 3G designs. > It is up to the implementor to take into account particular network and > inter-network characteristics and real-time flow requirements to determine > how early Pre-Connection Context Transfer needs to be done to guarrantee > seamless. By previous discussion, we are unlikely to be able to make any such guarantees. We can, however, make a darned good stab at it. Regards, Charlie P. From owner-seamoby@diameter.org Mon Jun 25 13:54:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22566 for ; Mon, 25 Jun 2001 13:54:51 -0400 (EDT) Received: (qmail 14423 invoked by alias); 25 Jun 2001 17:42:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14417 invoked by uid 200); 25 Jun 2001 17:42:58 -0000 Received: (qmail 14412 invoked from network); 25 Jun 2001 17:42:56 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 17:42:56 -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 KAA08364; Mon, 25 Jun 2001 10:53:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PHreJ26008; Mon, 25 Jun 2001 10:53:40 -0700 X-mProtect: Mon, 25 Jun 2001 10:53:40 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdAIKc5c; Mon, 25 Jun 2001 10:53:38 PDT Message-ID: <3B377AA1.A908CEF8@iprg.nokia.com> Date: Mon, 25 Jun 2001 10:53:37 -0700 From: Rajeev Koodli 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: "'Charles E. Perkins'" , seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DF0@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 Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > Even packet arrival is quite susceptible to ambiguity: > > - Is it that a packet arrived, or that it MIGHT have arrived? > - What packet is it that arrived? > - Did it arrive at the mobile node, the previous access router, or > the new access router? > > MN>> I agree, however, it is not very hard to change it, to say > Packet arrival at newAR (since that is what matters for CT). > Not having feature contexts might make the packet arrival defintion > fuzzier if you don't know how to interprete packets. > However, as I said you can replace packet arrival with an > almost equivalent event (say another message that makes packets arrive > at newAR). > Rajeev: We ought to be able to handle IP packets such as an IP packet from the MN to trigger CT. You don't need any context; only routing needs to work correctly. > [snip] > > I'm really puzzled by this question. There is a certain time > budget (say, as defined by the VoIP parameters). It would be nice > to have the fastest possible context transfer in order to remain > within that time budget. It's easier to do so with proactive > context transfer. It's still possible to do so with reactive > context transfer. Not all systems will support proactive context > transfer. > > MN>> Well, I said that since Rajeev was dismissing the > possibility of having the context to handle packets in time. > I agree not all systems/ scnearios could support proactive, but > does that mean we exclude it? > > Am I missing the point of your question?? Rajeev: Perhaps you misunderstood.. If in reactive mode, CT works by fetching contexts after the MN has arrived at the new AR (and even perhaps after a packet arrives at the new AR), it does not mean that contexts cannot be there "in time". Obviously there is predictive CT, and depending on the nature of the application, even reactive CT could meet the performance requirements. So, I never dismissed the possibility of CT being undistputably useful :-) That is, contexts are there "in time". [note: this does not mean predictive CT will always accomplish it] Regards, -Rajeev [snip]. From owner-seamoby@diameter.org Mon Jun 25 14:21: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 OAA23242 for ; Mon, 25 Jun 2001 14:21:34 -0400 (EDT) Received: (qmail 14991 invoked by alias); 25 Jun 2001 18:09:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14985 invoked by uid 200); 25 Jun 2001 18:09:47 -0000 Received: (qmail 14980 invoked from network); 25 Jun 2001 18:09:46 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:09:46 -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 LAA11037; Mon, 25 Jun 2001 11:20:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PIKTi05699; Mon, 25 Jun 2001 11:20:29 -0700 X-mProtect: Mon, 25 Jun 2001 11:20:29 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd8wPZka; Mon, 25 Jun 2001 11:20:28 PDT Message-ID: <3B3780EC.D831B75C@iprg.nokia.com> Date: Mon, 25 Jun 2001 11:20:28 -0700 From: Rajeev Koodli 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: Kulwinder Atwal CC: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F807B@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: > > > > > > Pre-Connection Context Transfer: The Context Transfer is > > initiated prior to > > > the newAR recieving a packet directly from the MN. > > > > > > Post-Connection Context Transfer: The Context Transfer is > > initiated after > > > the newAR recieves a packet directly from the MN. > Rajeev: I like this classification as well. > > > > *this* I like! However, I disagree with your view on handoffs. I would > > like the pre-handoff and post-handoff context transfer. Pre > > or post first > > packet doesn't make any sense *at all* to me. How can you > > guarantee, or know, > > when the first packet will be received?!? > > I can't. How early to do Pre-Connection Context Transfer to get seamless > transfer is implementation specific. > > The viewpoint is the newAR. Either the newAR is notified for a need to CT > from oldAR, or MN. > The difference is on what interface the newAR is notified. > > Rajeev: I guess the point is that you would do CT either 1. before the new AR becomes the MN's default router, or 2. after the new AR becomes the MN's default router Both 1) and 2) are related to handover. Regards, -Rajeev > It is up to the implementor to take into account particular network and > inter-network characteristics and real-time flow requirements to determine > how early Pre-Connection Context Transfer needs to be done to guarrantee > seamless. > > - Kulwinder. > > > In all cases that I > > know of, some > > signalling, either at L2 or L3, is used to register the > > mobile locally (or > > some signal strength measurements), but there is always an > > indication of handoff. > > > > > > > But, really why should we care where the request for CT > > comes from if we are > > > going to process it just the same? > > > > > > The only thing that is important is that the requesting > > entity recieve a > > > packet indicating the success or failure mode of the CT operation. > > > > ditto. > > > > PatC > > From owner-seamoby@diameter.org Mon Jun 25 14:52: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 OAA24002 for ; Mon, 25 Jun 2001 14:52:48 -0400 (EDT) Received: (qmail 15512 invoked by alias); 25 Jun 2001 18:39:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15506 invoked by uid 200); 25 Jun 2001 18:39:29 -0000 Received: (qmail 15501 invoked from network); 25 Jun 2001 18:39:27 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:39:27 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA18045 for ; Mon, 25 Jun 2001 11:50:38 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA10469 for ; Mon, 25 Jun 2001 11:50:37 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 13:50:36 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF3@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Kulwinder Atwal'" , Nakhjiri Madjid-MNAKHJI1 , "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Mon, 25 Jun 2001 13:50:36 -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: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Thursday, June 21, 2001 5:02 PM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Mark Smith'; seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 21, 2001 12:38 PM > To: 'Mark Smith'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > Mark, > > Well, it seems like we are going with ARs (which I like). > > I don't know much about MRs and Manet, however I think AR has a more > precise scope than FN. Does AR imply that the router cannot be mobile? > i.e. MR cannot be a subset of AR? > > I don't care too much about the physical or software > definition of a node > as Kulwinder described (although, from the implementation point, it is > important :) > I care about the functionality. > For the neutralness in this discussion I use my own favorite > term CT peer > instead of FN or AR. > > Now, But To answer your question:: > of course if the node offering CT is mobile, it makes > a lot of difference, > 1-how would you handle the security associations for > pre-authentication between CT peers, if the CT peer is mobile? How is this issue different than the MN being mobile? MN>> I don't even see the relevance. The discussion was about how much of different CT scenario do you have if the AR that is doing CT for an MN is mobile AR or fixed. Not about the MN. If the CT is aggreated by a device that appears to the network as an large MN how does the network know that the IP stream is for one physical device, or multiple physical devices? MN>> we are not only talking about the IP streams, we are talking about the contexts that relate all these mobiles. All of sudden you have an AR that is supposed to do CT for a lot of MNs. How do you feed that AR with the contexts, how do you solve the security, authentication,... issues for all the context, I am sure you admit that things get more completed when the CT peers are mobile themselves (Analogy of IP and Mobile IP should be enough :) Why should it care as long as the 'root MN' has a valid security association that establishes a _Chain_Of_Trust_ to the terminal MN? MN>> You need to explain the difference between root MN and terminal MN for me. If by root MN you mean AR, then establishing trust that goes through a Mobile AR is more difficult. If we can do partial Context transfer, how will the network actually know that there are two physical devices instead of one as far as CT is concerned? If it does know do you not think this knowledge would best be modularized and handled by a Mobile Router Protocol/AR Discovery Protocol? MN>> how does doing partial CT make things easier. Besides nobody has brought up multidevice CT when different context is going to different devices, as far as I remember, so I guess I am missing something. > 2-How would you handle the associations in case you are using > a transport protocol like SCTP? This is a Mobile Router Protocol issue. This begs the need for a Mobile Router Protocol that does route aggregation using IPv6 subnet prefixes. MN>> Finally, You won the million dollar question!!! that is what we have been talking about all along. > 3- The context also needs to be available at the CT peer prior > to the CT, so whatever network element that wants to make sure > CT peer has enough supply for the next CT, needs to track the > CT peer to feed it. Enough supply of what? Bandwidth? This is an AR Discovery issue. If the AR Discovery Protocol is based on triggers I don't see where the problem is. MN>> Supply of context for the CT peer !!! -Kulwinder. > > These are problems that do need a WHOLE lot of consideration when the > CT peer is mobile. > > Madjid > > -----Original Message----- > From: Mark Smith [mailto:mark.smith@comdev.cc] > Sent: Wednesday, June 20, 2001 3:57 PM > To: seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > Thank you, yes, that summarizes quite nicely what I was trying to say. > > I'm not trying to say that this isn't a problem, I'm asking if anyone > can see why it would be. I can't, but I don't claim to be > all knowing. :) > > -Mark > > Kulwinder Atwal wrote: > > > To expand on Mark's comment: > > > > If we think of an AR or MN as a software > thread/task/process with its own > AR > > context/MN context, instead of physical devices, then we > should be able to > > keep the terms AR and MN seperate. > > > > 1. A physical device may have just the AR task running, in > which case it > is > > only an AR. > > > > 2. A physical device may have just the MN task running, in > which case it > is > > only an MN. > > > > 3. A physical device may have a MN task and an AR task > running in which > case > > it is both, but the functionality is modularized. > > > > With the AR discovery protocol is possible to learn in a mobile > environment > > which mobile device nearby has an AR task running before > attempting CT. > > > > - Kulwinder. > > > > > >>-----Original Message----- > >>From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > >>Sent: Wednesday, June 20, 2001 3:06 PM > >>To: Mark Smith > >>Cc: seamoby@cdma-2000.org > >>Subject: Re: [seamoby] Issue 1: Change access network terminology > >> > >> > >> > >>Perhaps I am missing something.. Aren't we concerned about > >>the "entity" which offers > >>different features (QoS, HC,..) ? I guess we went with AR > >>because that's the entity > >>that typically offers the features. > >> > >>Regards, > >> > >>-Rajeev > >> > >> > >>Mark Smith wrote: > >> > >> > >>>I guess my question is, does it matter if a Forwarding Node > >>> > >>(as Gary has > >> > >>>defined them) is also a Mobile Node? What effect does it > >>> > >>have on our > >> > >>>design/requirement/problem statement? > >>> > >>>I think the idea is that, for the sake of a particular CTP > >>> > >>session, a > >> > >>>node is either an MN or an FN. If it's an FN for this CTP > >>> > >>session, it > >> > >>>may be an MN for another session, but those two sessions > >>> > >>are independant > >> > >>>of each other and should be viewed as such. > >>> > >>>-Mark > >>> > >>>Pat Calhoun wrote: > >>> > >>> > >>>>On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > >>>> > >>>> > >>>>>If we do this (which would be find for me, regardless of > >>>>> > >>what my last > >> > >>>>>post said :), make sure we define it to address Phil's > >>>>> > >>requests. I > >> > >>>>>think if we were to specify that an AR, in our case, is > >>>>> > >>not neccessarily > >> > >>>>>a fixed, wired device, that it can, infact, be an MN > >>>>> > >>itself, that should > >> > >>>>>do the trick. > >>>>> > >>>>>Whatever we call it, it should be defined. > >>>>> > >>>>> > >>>>yes, you posts crossed each other :) > >>>> > >>>>Well, if a CT peer can be an MN, then the use of AR is > >>>> > >>clearly innapropriate. > >> > >>>>AR is an access router, and this is typically where I see > >>>> > >>CT being used, but > >> > >>>>I understand that there are others, such as Phil, that > >>>> > >>see CT as having many > >> > >>>>other uses. > >>>> > >>>>Perhaps we should first have someone open an issue on > >>>> > >>whether an MN can in fact > >> > >>>>be a CT peer, and the result of that issue would dictate > >>>> > >>the future of this one. > >> > >>>>PatC > >>>> > >>>> > From owner-seamoby@diameter.org Mon Jun 25 14:57: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 OAA24118 for ; Mon, 25 Jun 2001 14:57:06 -0400 (EDT) Received: (qmail 15998 invoked by alias); 25 Jun 2001 18:45:17 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15992 invoked by uid 200); 25 Jun 2001 18:45:17 -0000 Received: (qmail 15987 invoked from network); 25 Jun 2001 18:45:15 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:45:15 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA16704 for ; Mon, 25 Jun 2001 11:49:39 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA26031 for ; Mon, 25 Jun 2001 11:49:37 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 13:56:29 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Singh Ajoy-ASINGH1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Mon, 25 Jun 2001 13:55:57 -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 Hi Charlie, I guess, I have a question, why would CT have any impact on DAD? I don't recall of any restrictions on CT that would impact DAD. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Thursday, June 21, 2001 5:13 PM To: Singh Ajoy-ASINGH1 Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Singh Ajoy-ASINGH1 wrote: > Rajeev: While I don't necessarily agree with the example, we all want > CT to finish before the packets start arriving. That's why we have > predictive handovers. When you can't do such a thing, e.g., consider > that link-layer triggers don't work because the two technologies are > different, you have the initiation of reactive CT after the MN > establishes a new link. It is possible or even likely that some packets could be delivered to the mobile node before the context is transferred, especially in the reactive case but not necessarily only there. For example, given proactive, what if the mobile node starts doing DAD at the new access router before the context transfer completes? This would be quite possible, and I would hate to see the context transfer protocol place any restrictions otherwise. Obviously, if DAD is needed, it would be silly to delay its initiation, even for proactive. If, instead, you want to make the definition that this isn't "pro-active enough", then I would claim that the need for redefinition exhibits the problem with even the general thrust of the existing definitions. > Ajoy: I thought some more about inter-technolgy CT. It seems > the inter-technolgy CT may be difficult to realize. For > example, one access network might use PPP while others > might not. In this case, will it make > sense to transfer the PPP context from one access router to > other? Additionally, I think most of us agree that make before > break handover is possible in inter-technolgy case, when > some overlap is available between coverage area of > different technolgies. So Can't > MN re-negotiate CT with new AR before breaking > connection with oldAR ? Sure this can happen, but if inter-technology context transfer is is available and it saves time, then we should allow it. The benefit will be better customer experience in more cases. Furthermore, I can't see any downside on the protocol design. It doesn't seem to make the problem harder or easier. And I would hate to see PPP context become the defining example for context transfer. Regards, Charlie P. From owner-seamoby@diameter.org Mon Jun 25 14:59: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 OAA24204 for ; Mon, 25 Jun 2001 14:59:50 -0400 (EDT) Received: (qmail 16475 invoked by alias); 25 Jun 2001 18:48:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16469 invoked by uid 200); 25 Jun 2001 18:48:02 -0000 Received: (qmail 16460 invoked from network); 25 Jun 2001 18:48:01 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:48:01 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA18749 for ; Mon, 25 Jun 2001 11:52:24 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA26722 for ; Mon, 25 Jun 2001 11:59:14 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 13:59:13 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF5@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT Date: Mon, 25 Jun 2001 13:59:11 -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 Pat, I like your idea. I think it should be added. I just have one question and that is on the emphasi -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 21, 2001 5:37 PM To: seamoby@cdma-2000.org Subject: [seamoby] [Issue] Support for Multi-Phase CT Issue 5: Support for multi-phase CT Submitter name: Pat Calhoun Submitter email address: pcalhoun@eng.sun.com Date first submitted: June 21,2001 Reference: Comment type: T Priority: 1 Section: 4.9 Rationale/Explanation of issue: The current requirement in section 4.9 states that a CT can only occur once all of the state has been gathered. The CT protocol must allow for state to be transferred in phases, where the high priority state (e.g. Header Compression, session keys) is sent first, and low priority items are sent at a later time (e.g. accounting information). This would reduce the size of the high priority CT packets, lower the computational cost of processing the packet, and decrease the handoff latency. Requested change: Change 4.9 to state something like: "4.9 Context information MAY be transferred in phases, allowing for higher priority state to be sent first, and lower priority state to be sent at a later time. The total cost of processing a smaller packet with high priority state is smaller, and would decrease any latency introduced by CT. Each CT profile would need to specify whether it is to be considered as a high or low priority state." Proposal: Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Mon Jun 25 15:03:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24278 for ; Mon, 25 Jun 2001 15:03:09 -0400 (EDT) Received: (qmail 16942 invoked by alias); 25 Jun 2001 18:51:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16936 invoked by uid 200); 25 Jun 2001 18:51:28 -0000 Received: (qmail 16931 invoked from network); 25 Jun 2001 18:51:27 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:51:27 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA10751 for ; Mon, 25 Jun 2001 12:02:34 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA29948 for ; Mon, 25 Jun 2001 12:02:33 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 14:02:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT Date: Mon, 25 Jun 2001 14:02:33 -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 Pat, I think this is a good idea. I just have one question, since your text emphasizes on the size of low priority packets. I can see that accounting could include a lot of data, but why the emphasis that every high priority context has small packet size and every low priority context has large packet size? Isn't that a bit of generalization? Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 21, 2001 5:37 PM To: seamoby@cdma-2000.org Subject: [seamoby] [Issue] Support for Multi-Phase CT Issue 5: Support for multi-phase CT Submitter name: Pat Calhoun Submitter email address: pcalhoun@eng.sun.com Date first submitted: June 21,2001 Reference: Comment type: T Priority: 1 Section: 4.9 Rationale/Explanation of issue: The current requirement in section 4.9 states that a CT can only occur once all of the state has been gathered. The CT protocol must allow for state to be transferred in phases, where the high priority state (e.g. Header Compression, session keys) is sent first, and low priority items are sent at a later time (e.g. accounting information). This would reduce the size of the high priority CT packets, lower the computational cost of processing the packet, and decrease the handoff latency. Requested change: Change 4.9 to state something like: "4.9 Context information MAY be transferred in phases, allowing for higher priority state to be sent first, and lower priority state to be sent at a later time. The total cost of processing a smaller packet with high priority state is smaller, and would decrease any latency introduced by CT. Each CT profile would need to specify whether it is to be considered as a high or low priority state." Proposal: Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Mon Jun 25 15:08: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 PAA24413 for ; Mon, 25 Jun 2001 15:08:03 -0400 (EDT) Received: (qmail 17417 invoked by alias); 25 Jun 2001 18:55:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17411 invoked by uid 200); 25 Jun 2001 18:55:45 -0000 Received: (qmail 17406 invoked from network); 25 Jun 2001 18:55:44 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 18:55:44 -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 MAA14222; Mon, 25 Jun 2001 12:06:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PJ6OF07887; Mon, 25 Jun 2001 12:06:24 -0700 X-mProtect: Mon, 25 Jun 2001 12:06:24 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdrOyrwa; Mon, 25 Jun 2001 12:06:23 PDT Message-ID: <3B378BAF.4F3F0216@iprg.nokia.com> Date: Mon, 25 Jun 2001 12:06:23 -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: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9DF4@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 Madjid, > I guess, I have a question, why would CT have any impact on DAD? > I don't recall of any restrictions on CT that would impact DAD. This was exactly my point. I suggested that we should allow for systems in which context transfer can proceed independently from DAD. One can imagine protocol restrictions that would enforce a sequence whereby DAD has to complete before context transfer could be initiated. I would like to make sure that such restrictions do not come into being. Some people may wish to design systems that have the restriction, but the general [seamoby] protocol specification should not mandate any such restriction. Regards, Charlie P. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Thursday, June 21, 2001 5:13 PM > To: Singh Ajoy-ASINGH1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] proactive and reactive CT definitions > > Singh Ajoy-ASINGH1 wrote: > > > Rajeev: While I don't necessarily agree with the example, we all want > > CT to finish before the packets start arriving. That's why we have > > predictive handovers. When you can't do such a thing, e.g., consider > > that link-layer triggers don't work because the two technologies are > > different, you have the initiation of reactive CT after the MN > > establishes a new link. > > It is possible or even likely that some packets could be delivered > to the mobile node before the context is transferred, especially > in the reactive case but not necessarily only there. For example, > given proactive, what if the mobile node starts doing DAD at the > new access router before the context transfer completes? This would > be quite possible, and I would hate to see the context transfer > protocol place any restrictions otherwise. Obviously, if DAD is > needed, it would be silly to delay its initiation, even for > proactive. If, instead, you want to make the definition that > this isn't "pro-active enough", then I would claim that the need > for redefinition exhibits the problem with even the general thrust > of the existing definitions. > > > Ajoy: I thought some more about inter-technolgy CT. It seems > > the inter-technolgy CT may be difficult to realize. For > > example, one access network might use PPP while others > > might not. In this case, will it make > > sense to transfer the PPP context from one access router to > > other? Additionally, I think most of us agree that make before > > break handover is possible in inter-technolgy case, when > > some overlap is available between coverage area of > > different technolgies. So Can't > > MN re-negotiate CT with new AR before breaking > > connection with oldAR ? > > Sure this can happen, but if inter-technology context transfer is > is available and it saves time, then we should allow it. The > benefit will be better customer experience in more cases. Furthermore, > I can't see any downside on the protocol design. It doesn't seem to > make the problem harder or easier. And I would hate to see PPP context > become the defining example for context transfer. > > Regards, > Charlie P. From owner-seamoby@diameter.org Mon Jun 25 15:17: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 PAA24585 for ; Mon, 25 Jun 2001 15:17:42 -0400 (EDT) Received: (qmail 17907 invoked by alias); 25 Jun 2001 19:06:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17901 invoked by uid 200); 25 Jun 2001 19:06:07 -0000 Received: (qmail 17896 invoked from network); 25 Jun 2001 19:06:06 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:06:06 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA19678 for ; Mon, 25 Jun 2001 12:17:19 -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 MAA25210 for ; Mon, 25 Jun 2001 12:17:18 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 14:17:00 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF8@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , "Charles E. Perkins" Cc: Gary Kenward , seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Mon, 25 Jun 2001 14:16:36 -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 I don't like the pull/Push distinction for proactive and reactive either. It is too restrictive. The proactive/ reactive definition were introduced to deal with timing issues not protocol/messaging issues. Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, June 22, 2001 3:55 PM To: Charles E. Perkins Cc: Gary Kenward; seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions > I'm generally in agreement with your sentiment here, but I sort-of thought > that some bits had to be able to traverse the medium before a reactive > context transfer could start. Your point about possibly asynchronous > operation, or parallel operation of context transfer and link establishment, > is valid I reckon. And yet the reactive process doesn't just start up > out of the blue. Thus, we ought to be able to figure out some words to > characterize the kind of event that initiates a reactive context transfer. > > Is it possible to use the "push/pull" distinction instead of making > the definition in terms of a protocol event? I haven't fully thought > this through, so I'm not sure... I don't think so. A pro-active is not bound to a particular direction. In a target trigger (using the FMIPv4 terminology), it would pull the context, and this could occur before the actual handoff is complete. In a source trigger, the would push the context, and again, it could occur before the handoff is complete. So pull/push wouldn't work. PatC From owner-seamoby@diameter.org Mon Jun 25 15:21:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24672 for ; Mon, 25 Jun 2001 15:21:25 -0400 (EDT) Received: (qmail 18389 invoked by alias); 25 Jun 2001 19:09:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18383 invoked by uid 200); 25 Jun 2001 19:09:50 -0000 Received: (qmail 18374 invoked from network); 25 Jun 2001 19:09:48 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:09:48 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA24653 for ; Mon, 25 Jun 2001 12:21:01 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA15988 for ; Mon, 25 Jun 2001 12:14:09 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 14:21:01 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DF9@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Pat Calhoun Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] proactive and reactive CT definitions Date: Mon, 25 Jun 2001 14:20:53 -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, June 22, 2001 4:36 PM To: Pat Calhoun Cc: seamoby@cdma-2000.org Subject: Re: [seamoby] proactive and reactive CT definitions Hello Pat, > I don't think so. A pro-active is not bound to a particular direction. In a > target trigger (using the FMIPv4 terminology), it would pull the context, and > this could occur before the actual handoff is complete. Do you mean that the new access router could request context from the old access router before a bit could traverse the air interface? MN>> That bit doesn't have to be a layer 3 one :) If it is an L2 target trigger, it can start CT. > In a source trigger, > the would push the context, and again, it could occur before the handoff is > complete. This latter case is presumably more common. > So pull/push wouldn't work. Too bad. I agree that if the target trigger context pull is initiated before the mobile node is connected, the push/pull distinction wouldn't work. I'm a little bit surprised that such a case is important, but if it is then so be it. MN>> see my previous comment. That would put us back to defining reactive and proactive in terms of some recognizable event associated with the mobile node's arrival at the new access network (or, maybe even "at" the new access router). MN>>Not necessary, we could make pull/Push subscenarios of reactive and/or proactive. Madjid Regards, Charlie P. From owner-seamoby@diameter.org Mon Jun 25 15:24:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24754 for ; Mon, 25 Jun 2001 15:24:08 -0400 (EDT) Received: (qmail 18675 invoked by alias); 25 Jun 2001 19:11:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18667 invoked by uid 200); 25 Jun 2001 19:11:01 -0000 Received: (qmail 18655 invoked from network); 25 Jun 2001 19:10:59 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:10:59 -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 MAA15787; Mon, 25 Jun 2001 12:21:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PJLfr26199; Mon, 25 Jun 2001 12:21:41 -0700 X-mProtect: Mon, 25 Jun 2001 12:21:41 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdbUIS2h; Mon, 25 Jun 2001 12:21:40 PDT Message-ID: <3B378F44.DE460C44@iprg.nokia.com> Date: Mon, 25 Jun 2001 12:21:40 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: Gary Kenward , "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C9F5D49@zcard031.ca.nortel.com> <20010618135157.Z17928@charizard.diameter.org> <3B3140EC.9EB61F89@iprg.nokia.com> <20010621063217.G1322@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Wed, Jun 20, 2001 at 05:33:48PM -0700, Rajeev Koodli wrote: > > > > Hi Pat, > > > > consider that the MN just shows up at new AR. I mean it looses its current link, > > and gets a new one with new AR. After it establishes the link, the MN sends an > > IP message (just as it would send a Binding Update) to the new AR providing its > > previous IP address and previous AR address. The new AR contacts the old AR to > > fetch contexts. > > > > How's that ? > > then why wouldn't the authenticated binding update simply cause CT to occur? > Rajeev: Sorry for the delayed response to a very good question: This *should* be allowed, and can very well occur. Regards, -Rajeev > > Patc > > > > > From owner-seamoby@diameter.org Mon Jun 25 15:26: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 PAA24845 for ; Mon, 25 Jun 2001 15:26:55 -0400 (EDT) Received: (qmail 19278 invoked by alias); 25 Jun 2001 19:14:30 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19272 invoked by uid 200); 25 Jun 2001 19:14:30 -0000 Received: (qmail 19263 invoked from network); 25 Jun 2001 19:14:28 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:14:28 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA16531 for ; Mon, 25 Jun 2001 12:25:40 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA10793 for ; Mon, 25 Jun 2001 12:25:31 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 14:24:42 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DFA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Kulwinder Atwal Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Mon, 25 Jun 2001 14:24:42 -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 I prefer that we don't introduce explicit messaging, at least for now. Defining a general CT trigger that each technology can map onto should be good enough. I am with option 2. Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, June 22, 2001 5:05 PM To: Kulwinder Atwal Cc: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote: > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 21, 2001 6:45 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] Issue 2: Make IP messages uniform > > > > > > If I understand this particular issue properly, it is a > > request for a layer 3 > > message be created to initiate CT. However, I believe that > > the mobility management > > used already has messages that initiate L3 handoffs, and > > these could be used > > to initiate CT. > > > > So, we have two options: > > 1. Create a message, which will introduce additional over the > > air latency in > > getting the CT initiated. > > The newAR will need to request CT from a peer AR. Are you suggesting that > MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA? > Or, is it quite possible that the CoA and the oldAR may not be co-located? > > Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some > technology do we really care about over the air latency for a few bytes? no, but look at option 2 below. My point is that there is already some signalling, either at L2 (e.g. signal strength), or at L3 (binding update). Why require another message, since we've already agreed to co-locate with other MM protocols. > > Of course some lower bandwidth technologies will use an L2 Trigger at the > newAR, but the choice is really technology specific. right, so we allow for L2 or L3. The question is whether CT needs to define another message, or if an existing one can be used. I much prefer the latter. > > Further, I would hope that if the CoA were not co-located with the oldAR > that some time could be saved by sending a change in route to the parent AR > on the newAR-to-ParentAR link, while at the _same_ time sending a message to > the oldAR on the oldAR-to-newAR link to transfer Context. > > Since time is very critical in Reactive Context Transfer it would seem like > a very useful method to reduce latency. right, but I don't see how a CT L3 message would be faster, and therefore enable reactive CT, than would a binding update. > Additionally, a MN message on a high bandwidth link could be forwarded by > the currentAR to the oldAR to request CT, and at the _same_ time a MN > message could be forwarded by the currentAR to the ParentAR to affect a > route change. > > The route change message may travel to a different entity along a different > link, than the Context Transfer request message. Having them happen in > parrallel could significantly reduce Reactive Context Transfer. ok, this is the one and first argument that I've heard that could convince me to agree to MN-initiated CT. PatC From owner-seamoby@diameter.org Mon Jun 25 15:32:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25001 for ; Mon, 25 Jun 2001 15:32:26 -0400 (EDT) Received: (qmail 19818 invoked by alias); 25 Jun 2001 19:20:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19812 invoked by uid 200); 25 Jun 2001 19:20:51 -0000 Received: (qmail 19807 invoked from network); 25 Jun 2001 19:20:49 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:20:49 -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 MAA16600; Mon, 25 Jun 2001 12:31:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PJVXs08798; Mon, 25 Jun 2001 12:31:33 -0700 X-mProtect: Mon, 25 Jun 2001 12:31:33 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdVxQqGn; Mon, 25 Jun 2001 12:31:32 PDT Message-ID: <3B379194.EC7D92B9@iprg.nokia.com> Date: Mon, 25 Jun 2001 12:31:32 -0700 From: Rajeev Koodli 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: Hamid Syed , seamoby@cdma-2000.org Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <9FBD322B7824D511B36900508BF93C9C1CD101@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hamid, I guess the discussion along this thread has moved over to different thread. In any case, see some comments below. Regards, -Rajeev Hamid Syed wrote: > > > Rajeev, > > By the time the context arrives at the new AR and processed (e.g. for > resource availability against the QoS context0, what is going to > happen to the traffic from the MN to the new AR (as you already said > that the new AR has layer 3 connectivity with MN). Sounds like latency > issue here. The MN sends the IP message to the new AR, the new AR goes > back to the old AR, and finally the context arrives at the new AR, it > gets processed. Now the new Ar is able to determine whether the > support for the MN's microflows is available or not. > Rajeev: The point is that you may not have a choice in some situations. Consider when predictive does not work, the new AR knows of the MN's arrival only after the MN actually attaches to it. Sure there is latency. But, you can still fetch the contexts. The alternative is to re-establish them (over the air interface). And, importantly, you can still build the contexts "soon enough". > > Does it help assuring a "seamlessness" to the MN? > Rajeev: I don't know how to assure something without implementation experience. I do know however that it depends on the nature of the application. Regards, -Rajeev > > -Hamid > > -----Original Message----- > > From owner-seamoby@diameter.org Mon Jun 25 15:37: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 PAA25098 for ; Mon, 25 Jun 2001 15:37:32 -0400 (EDT) Received: (qmail 20302 invoked by alias); 25 Jun 2001 19:26:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20296 invoked by uid 200); 25 Jun 2001 19:26:01 -0000 Received: (qmail 20291 invoked from network); 25 Jun 2001 19:26:00 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 19:26:00 -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 MAA17031; Mon, 25 Jun 2001 12:36:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PJahu16632; Mon, 25 Jun 2001 12:36:43 -0700 X-mProtect: Mon, 25 Jun 2001 12:36:43 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdTZK3Th; Mon, 25 Jun 2001 12:36:42 PDT Message-ID: <3B3792CA.96933D9C@iprg.nokia.com> Date: Mon, 25 Jun 2001 12:36:42 -0700 From: Rajeev Koodli 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: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <35DBB8B7AC89D4118E98009027B1009B017A9DE3@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 Nakhjiri Madjid-MNAKHJI1 wrote: > > > Rajeev: why would we have to add L2 signaling ? An IP message to initiate > CT would be needed for the MN and is perhaps useful for other entities. I > think > it is doable. > > MN>> This IP layer CT is starting to sound like Alchemy :) > Everybody talks about it, nobody is providing it. Say > you are using MIPv6 fast handoff, Which message is it, that > triggers CT? Rajeev: F-BU/F-NA. Regards, -Rajeev > > Madjid From owner-seamoby@diameter.org Mon Jun 25 16: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 QAA26589 for ; Mon, 25 Jun 2001 16:46:39 -0400 (EDT) Received: (qmail 20943 invoked by alias); 25 Jun 2001 20:34:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20937 invoked by uid 200); 25 Jun 2001 20:34:26 -0000 Received: (qmail 20932 invoked from network); 25 Jun 2001 20:34:24 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 20:34:24 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA01346 for ; Mon, 25 Jun 2001 13:38:48 -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 NAA00079 for ; Mon, 25 Jun 2001 13:45:38 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 15:45:38 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DFB@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Kulwinder Atwal'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Mon, 25 Jun 2001 15:45:19 -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 Kulwinder, You seem to be taking too much stuff out of the context! Not good in a context transfer discussion :) it would just add to pollution. Nobody is engaged in wishful thinking, but not everybody's scenario is about inter-finger tip handovers on multi-Mpbs links either. People still are dealing with scenarios where the speed is over 60 Mph and the link is around 10 kpbs with a lot of errors and you loose costumers when you drop calls. So timing is important. If you look at the archive, I have always said we are better off removing timing requirements, if cannot come up with something better than "timely" or "fast" there. I think Charlie has brought up a lot of good points and we are making good progress. If you read my other emails, I said, I don't care what you call reactive or proactive, as long as we cover all the scenarios, I am fine. Madjid -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Saturday, June 23, 2001 4:55 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins' Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, June 22, 2001 7:02 PM > To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Hi Charlie, > > Comments below (MN>>) > > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 21, 2001 3:40 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and > reactive CT definitions > > > > Hello Madjid, > > > MN>> I am not sure if I understand the sentence above, but > I take it as, by link establishment you mean the MN is able > to send and receive L3 packets. > The reason we picked Handover, was so we knew whether we were > introducing latency into handovers or not. > I don't know who 'we' are, but as a member of the Design Team I certainly do not recall 'picking' Handover to mean that we would sequentially hard code parrallel asynchronous events. I do recall argueing strongly against _any_ ordering of events that are not a direct part of CT and having the text changed to reflect it. But, I suppose that the changes did not go far enough. > MN>> My question was, don't you think CT should have timing > requirements, so it introduces zero (proactive) or as little > delay as possible. This is wishful thinking. It is impossible to guarrantee in a heterogenous network. We cannot guarrantee how long something will take, where our mobile device will be, or the sequence of packet arrival (events). We can hope for the best, but we need to plan for the worst (even with proactive). > Don't take me wrong, I don't know enough > about all the features to believe 100% in zero delay, but it > is a scenario, that should be included. Even if you are late the end-user will never notice, as long as the packet is delivered to the MN within the tolerable interpacket jitter of the Real-Time stream. This is the _REAL_ deadline, and it depends on which Real-Time streams you choose to support. If the parentAR is heavily loaded with other tasks on a private wireless network such that each route change message arrives 1 mSec after the CT on a direct route between newAR and oldAR should proactive CT always fail? Is dealing with this Proactive 'error' condition not more complicated than simply removing this restriction? Will having to deal with this 'error' condition not introduce more delay? This protocol will fail to operate in a private wireless network with requirements 5.4.1 and 5.4.2. There is no way to gaurantee the sequence of packet arrival in every type of wired/wireless network where this protocol may be used. - Kulwinder. > > Regards, > Madjid > From owner-seamoby@diameter.org Mon Jun 25 17: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 RAA27300 for ; Mon, 25 Jun 2001 17:14:43 -0400 (EDT) Received: (qmail 21437 invoked by alias); 25 Jun 2001 20:57:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21431 invoked by uid 200); 25 Jun 2001 20:57:27 -0000 Received: (qmail 21426 invoked from network); 25 Jun 2001 20:57:26 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 20:57:26 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA16665 for ; Mon, 25 Jun 2001 14:08:39 -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 OAA05739 for ; Mon, 25 Jun 2001 14:08:39 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 16:08:39 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DFD@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Kulwinder Atwal Cc: "'seamoby@cdma-2000.org'" , Pat Calhoun Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Mon, 25 Jun 2001 16:08:15 -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 Hello Charlie, Sorry, If I am answering to your emails in the wrong order. I was going through the email to not to miss any conclusions. See some comments below. If you don't mind, I added some numbers to your scenario (see your own email at the bottom). your scenario is much closer to reality now. However, there are a couple of things I am fuzzy about. 1-I thought your point in reactive was that the CT is done after link establishment. Now you say you call the scenario reactive because newAR is reacting to MN's move. What if in step 4 oldAR sends a CT start notification (if there was a msg like that) to newAR, saying now I am starting CT? Then newAR does not have to "react" (initiate CT). I still think it is not so important who starts CT messaging. Also your assumption is that newAR is asking for CT and until the reply for this request comes back, MN establishes a link with newAR. If oldAR starts CT, then you might not have that much time for link establishment. 2- What if CT starts before step 5 is completed, then it would not be CT according to your definition. The point I am making is that you should not have to wait for link establishment to complete, if you include that in the definition of proactive, then, that is fine. Bottomline, if you like to redefine the scenarios we should not miss any cases. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] Sent: Monday, June 25, 2001 11:27 AM To: Kulwinder Atwal Cc: 'seamoby@cdma-2000.org'; Pat Calhoun Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions HI agree with this, basically. Please let me know how you think it applies in the following scenario: -1 Previous access router and new access router agree that the mobile node should move to the new access router. -2 Mobile node is told to move (after this, connectivity between mobile node and previous access router may fail) -3 Access network controller tells new access router to allocate spectrum for mobile node -4 New access router asks previous access router for context -5 At the same time, mobile node detects beacon from new access router and carries out operations for link establishment -6 Before finalizing the process of link establishment and the installation of the transferred context features, the new access router verifies the credentials of the mobile node. How do you think this scenario applies to your classification? My answer, is that this is reactive. The new access router is reacting to the information that the mobile node has arrived. From owner-seamoby@diameter.org Mon Jun 25 17:43: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 RAA27876 for ; Mon, 25 Jun 2001 17:43:33 -0400 (EDT) Received: (qmail 21967 invoked by alias); 25 Jun 2001 21:30:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21961 invoked by uid 200); 25 Jun 2001 21:30:00 -0000 Received: (qmail 21956 invoked from network); 25 Jun 2001 21:29:58 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 21:29:58 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA17116 for ; Mon, 25 Jun 2001 14:41:12 -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 OAA24658 for ; Mon, 25 Jun 2001 14:41:12 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 16:41:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DFE@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charlie Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Mon, 25 Jun 2001 16:39:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0FDBF.613AD3C0" 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_01C0FDBF.613AD3C0 Content-Type: text/plain Hello Charlie, Seems like we have reached an agreement based on our common interpretation of proactive case, please see below. I added the 3 cases again, just to make sure. I cut some of less important text. The previous email, that you asked about, is also attached, the cases were , 1-CT trigger arrives before Handover trigger (what starts the handover, it could be at oldAR, at newAR or at MN) and naturally before link establishment. 2-CT trigger arrives after handover trigger, but before link layer establishment with newAR. 3-CT trigger arrives after link layer establishment with newAR. If you agree that 1 and 2 are proactive and 3 is reactive, then we are in agreement and you can change the definition of proactive and reactive based on starting event (link establishment) I just don't want to have to wait for link establishment to start CT. > MN>> I agree, however, it is not very hard to change it, to say > Packet arrival at newAR (since that is what matters for CT). > Not having feature contexts might make the packet arrival defintion > fuzzier if you don't know how to interprete packets. > However, as I said you can replace packet arrival with an > almost equivalent event (say another message that makes packets arrive > at newAR). Somehow, though, this seems to miss the point. For reactive, the context transfer should be reacting to something -- say, the arrival of a mobile node at the new access network. Whether this arrival is determined by the transmission of a layer-3 packet is important, yet necessarily comes after the arrival. On the other hand, by protocol the only way we can detect the arrival is by some packet being sent somewhere. That's why I tried to make the definition in terms of the _ability_ of the mobile node to send a packet. MN>>>> I agree with you. as I said if your proactive covers the case where handover signaling has started but link is not established but you still can start CT without waiting for link establishment, then that is fine. I'm curious how a message could be delivered to enable packets, when the message itself has to be the content of a packet. This makes me think that we are using different definitions for what a "packet" is supposed to be. For me it's a bag of bits, and can be used at layer 2. > MN>>point was to define a deadline for CT to be complete, and > basing everything on the starting event, does not provide any > timing requirements for CT, unless you want to leave it open > for now. I suggest that the starting event is the right way, and that all of the protocols involved have to be robust enough to work anyway if something takes longer. We should just make it work as fast as we can. MN>>>> Again see my comments above, I can see the benefit of using the starting event for the definition over packet arrival (that we had earlier), as long as you expand the proactive case. In Mobile IP, we defined 4 scenarios. They were very useful: - Mobile initiated after departure - Network initiated after departure - Mobile initiated before departure - Network initiated before departure MN>> Departure is a bit fuzzy here, does not tell you what happens to the MN-oldAR or MN-newAR link. Also whether Mobile initiates or network is not very critical for CT. But I see that identifying scenarios are important, and that is why I asked for event sequences and some people took it the wrong way and interpreted that I like to see CT and handover to happen in a sequential manner. Context transfer can be sensible in all four of these cases. > > ****Unless you offer a clear event sequence and show different Handover > > stages and the need of packet delivery for various feature context, > > I don't think we can change our definition and base it on an start > > event.***** > > I'm not sure if my example would be welcome, but here goes > anyway: > > 1) Mobile node shows up at new access router (802.11, say) > 2) Mobile node asks new access router to collect context > from previous router. Mobile includes authentication data > that can be checked by previous access router. > 3) New access router sends request for context transfer to > previous router. > 4) Previous access router checks the authentication data, and > upon approval delivers the requested context features > 5) New access router installs the delivered context features, > and (optionally) notifies the mobile node about the status. > > This is reactive, and it could be very valuable for certain > kinds of context. > > MN>> what if the newAR receives notification about an iminent > arrival before the MN actually arrives at the newAR. This is > common in cellular! Which category does this fall into? > Proactive? If your proactive includes this, then we are fine. By my understanding, this would be proactive; I am guessing that the new access router receives context information as well as the basic indication of the arrival of the mobile node. But that amounts to an (important!) optimization. MN>> Then we are in agreement!!!! > MN>> Well, I said that since Rajeev was dismissing the > possibility of having the context to handle packets in time. > I agree not all systems/ scnearios could support proactive, but > does that mean we exclude it? I definitely propose that we not exclude reactive context transfer. > MN>> My question was, don't you think CT should have timing > requirements, so it introduces zero (proactive) or as little > delay as possible. Don't take me wrong, I don't know enough > about all the features to believe 100% in zero delay, but it > is a scenario, that should be included. I think that context transfer should be optimized for the best performance in time. I don't see how you can realistically put absolute time bounds on the process, though. What would it be? 30ms? 300ms? Shouldn't the same protocol work for transferring video context as well as audio context (if there needed to be such a thing)? MN>> I agree, absolute numbers don't make sense in a general requirement document, I have always said that. Regards, Madjid N. ------_=_NextPart_000_01C0FDBF.613AD3C0 Content-Type: message/rfc822 Content-Description: RE: [seamoby] CT trigger or CT completion? was: proactive and reactive CT definitions Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DEF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby@cdma-2000.org'" Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Fri, 22 Jun 2001 17:40:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Hi Charlie, Thanks for the valuable insights. Sorry for the delay. I am responding to your comments in general for now, and hopefully get back to you with more details responses to your statements. Basically, after giving it some more thought, I like your definitions more, IF we cover all the holes as I explain: it seems that you like to see the proactive or reactive-ness of CT based on a starting trigger, rather than when CT completes and you want to base the definition on link establishment rather than handover. I agree that handover can be a bit fuzzy, but I want to assume that by link establishment you are talking about a L3 connection ((or Link layer connectivity) between MN and newAR. If we agree on this, let me go forward. I can see three cases for how CT can happen in regards to link establishment with the newAR. I intentionally don't bring the loss of connectivity with oldAR as a factor here. (I call the event that starts CT as CT trigger, it could be explicit or implicit) 1-CT trigger arrives before Handover trigger (what starts the handover, it could be at oldAR, at newAR or at MN) and naturally before link establishment. 2-CT trigger arrives after handover trigger, but before link layer establishment with newAR. 3-CT trigger arrives after link layer establishment with newAR. The way I see it, if we want to base the definitions of pro and reactive on the starting event: Your Proactive covers 1 and 2. Your reactive covers 3. Do we agree? If yes I am ok with this, the reason is the current draft definition: Proactive covers only 1 and only if CT completes prior to packet arrival and reactive covers both 2 and 3 only if CT completes after packet arrival (it does not cover 2 and 3 if the CT completes before packet arrival). So actually the draft definition is not conclusive of all cases, but your definition does not provide any timing requirement (the reason we defined reactive-ness and proactiveness the way we did). Note however, that I don't agree that proactive or reactive should be defined based on inquiry source as you explained in your other email. I don't think proactive=oldAR sends context, reactive=newAR sends context request (who sends and who requests things is more of a design matter, don't you agree? We had this discussion for a short while and we all decided that who initiates CT should not be the issue. Regards, Madjid ------_=_NextPart_000_01C0FDBF.613AD3C0-- From owner-seamoby@diameter.org Mon Jun 25 17:47: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 RAA27951 for ; Mon, 25 Jun 2001 17:47:41 -0400 (EDT) Received: (qmail 22294 invoked by alias); 25 Jun 2001 21:34:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22288 invoked by uid 200); 25 Jun 2001 21:34:03 -0000 Received: (qmail 22282 invoked from network); 25 Jun 2001 21:34:00 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 21:34:00 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA11427 for ; Mon, 25 Jun 2001 14:45:11 -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 OAA28484 for ; Mon, 25 Jun 2001 14:45:11 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 16:45:11 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9DFF@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'seamoby'" Subject: RE: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Date: Mon, 25 Jun 2001 16:44:46 -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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Monday, June 25, 2001 2:37 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'seamoby' Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... Nakhjiri Madjid-MNAKHJI1 wrote: > > > Rajeev: why would we have to add L2 signaling ? An IP message to initiate > CT would be needed for the MN and is perhaps useful for other entities. I > think > it is doable. > > MN>> This IP layer CT is starting to sound like Alchemy :) > Everybody talks about it, nobody is providing it. Say > you are using MIPv6 fast handoff, Which message is it, that > triggers CT? Rajeev: F-BU/F-NA. MN>> Yes, I suggested it in another email :) Majid Regards, -Rajeev > > Madjid From owner-seamoby@diameter.org Mon Jun 25 18:16: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 SAA28420 for ; Mon, 25 Jun 2001 18:16:22 -0400 (EDT) Received: (qmail 22974 invoked by alias); 25 Jun 2001 22:04:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22968 invoked by uid 200); 25 Jun 2001 22:04:39 -0000 Received: (qmail 22959 invoked by uid 500); 25 Jun 2001 22:04:37 -0000 Date: Mon, 25 Jun 2001 15:04:37 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT Message-ID: <20010625150437.A22915@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Pat Calhoun' , seamoby@cdma-2000.org References: <35DBB8B7AC89D4118E98009027B1009B017A9DF6@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: <35DBB8B7AC89D4118E98009027B1009B017A9DF6@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jun 25, 2001 at 02:02:33PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 25, 2001 at 02:02:33PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Pat, > > I think this is a good idea. > I just have one question, since your text emphasizes on > the size of low priority packets. I can see that accounting > could include a lot of data, but why the emphasis that every > high priority context has small packet size and every low priority > context has large packet size? Isn't that a bit of generalization? yes it is. Perhaps packet size is the wrong thing to point out here, but my point is that packet construction, transmission, reception and parsing is much faster for small packets than larger packets (well, transmission and reception is in the noise, but you get my drift). So, things like L2 security info needs to be there REAL fast! PatC > > Madjid > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 5:37 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > Issue 5: Support for multi-phase CT > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@eng.sun.com > Date first submitted: June 21,2001 > Reference: > Comment type: T > Priority: 1 > Section: 4.9 > > Rationale/Explanation of issue: > The current requirement in section 4.9 states that a CT can only > occur once all of the state has been gathered. The CT protocol > must allow for state to be transferred in phases, where the high > priority state (e.g. Header Compression, session keys) is sent > first, and low priority items are sent at a later time (e.g. > accounting information). > > This would reduce the size of the high priority CT packets, > lower the computational cost of processing the packet, and decrease > the handoff latency. > > Requested change: > Change 4.9 to state something like: > > "4.9 Context information MAY be transferred in phases, allowing for > higher priority state to be sent first, and lower priority > state to be sent at a later time. > > The total cost of processing a smaller packet with high priority > state is smaller, and would decrease any latency introduced by CT. Each > > CT profile would need to specify whether it is to be considered > as a high or low priority state." > > Proposal: > Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Mon Jun 25 18:19: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 SAA28476 for ; Mon, 25 Jun 2001 18:19:03 -0400 (EDT) Received: (qmail 23245 invoked by alias); 25 Jun 2001 22:05:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23239 invoked by uid 200); 25 Jun 2001 22:05:53 -0000 Received: (qmail 23220 invoked by uid 500); 25 Jun 2001 22:05:50 -0000 Date: Mon, 25 Jun 2001 15:05:50 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , Kulwinder Atwal , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010625150550.B22915@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Pat Calhoun' , Kulwinder Atwal , seamoby@cdma-2000.org References: <35DBB8B7AC89D4118E98009027B1009B017A9DFA@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: <35DBB8B7AC89D4118E98009027B1009B017A9DFA@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jun 25, 2001 at 02:24:42PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Mon, Jun 25, 2001 at 02:24:42PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > I prefer that we don't introduce explicit messaging, at least for now. > Defining a general CT trigger that each technology can map onto should be > good enough. > > I am with option 2. so if I understand correctly, perhaps a wireless technology profile would be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling), cdma2000 profile) PatC > > Madjid > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, June 22, 2001 5:05 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote: > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, June 21, 2001 6:45 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] Issue 2: Make IP messages uniform > > > > > > > > > If I understand this particular issue properly, it is a > > > request for a layer 3 > > > message be created to initiate CT. However, I believe that > > > the mobility management > > > used already has messages that initiate L3 handoffs, and > > > these could be used > > > to initiate CT. > > > > > > So, we have two options: > > > 1. Create a message, which will introduce additional over the > > > air latency in > > > getting the CT initiated. > > > > The newAR will need to request CT from a peer AR. Are you suggesting that > > MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA? > > Or, is it quite possible that the CoA and the oldAR may not be co-located? > > > > Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some > > technology do we really care about over the air latency for a few bytes? > > no, but look at option 2 below. My point is that there is already some > signalling, either at L2 (e.g. signal strength), or at L3 (binding update). > Why require another message, since we've already agreed to co-locate with > other MM protocols. > > > > > Of course some lower bandwidth technologies will use an L2 Trigger at the > > newAR, but the choice is really technology specific. > > right, so we allow for L2 or L3. The question is whether CT needs to define > another message, or if an existing one can be used. > > I much prefer the latter. > > > > > Further, I would hope that if the CoA were not co-located with the oldAR > > that some time could be saved by sending a change in route to the parent AR > > on the newAR-to-ParentAR link, while at the _same_ time sending a message to > > the oldAR on the oldAR-to-newAR link to transfer Context. > > > > Since time is very critical in Reactive Context Transfer it would seem like > > a very useful method to reduce latency. > > right, but I don't see how a CT L3 message would be faster, and therefore enable > reactive CT, than would a binding update. > > > Additionally, a MN message on a high bandwidth link could be forwarded by > > the currentAR to the oldAR to request CT, and at the _same_ time a MN > > message could be forwarded by the currentAR to the ParentAR to affect a > > route change. > > > > The route change message may travel to a different entity along a different > > link, than the Context Transfer request message. Having them happen in > > parrallel could significantly reduce Reactive Context Transfer. > > ok, this is the one and first argument that I've heard that could convince > me to agree to MN-initiated CT. > > PatC From owner-seamoby@diameter.org Mon Jun 25 18:23: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 SAA28518 for ; Mon, 25 Jun 2001 18:23:15 -0400 (EDT) Received: (qmail 23934 invoked by alias); 25 Jun 2001 22:11:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23928 invoked by uid 200); 25 Jun 2001 22:11:58 -0000 Received: (qmail 23920 invoked by uid 500); 25 Jun 2001 22:11:57 -0000 Date: Mon, 25 Jun 2001 15:11:56 -0700 From: Pat Calhoun To: Nakhjiri Madjid-MNAKHJI1 Cc: "'Kulwinder Atwal'" , "'Mark Smith'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 1: Change access network terminology Message-ID: <20010625151156.C22915@charizard.diameter.org> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , 'Kulwinder Atwal' , 'Mark Smith' , seamoby@cdma-2000.org References: <35DBB8B7AC89D4118E98009027B1009B017A9DF3@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: <35DBB8B7AC89D4118E98009027B1009B017A9DF3@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jun 25, 2001 at 01:50:36PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk All, Based on the discussions so far, I believe that consensus shows that we can reject this issue, and leave the term AR in the document. Thanks, PatC From owner-seamoby@diameter.org Mon Jun 25 18:45: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 SAA28861 for ; Mon, 25 Jun 2001 18:45:54 -0400 (EDT) Received: (qmail 24435 invoked by alias); 25 Jun 2001 22:34:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24429 invoked by uid 200); 25 Jun 2001 22:34:26 -0000 Received: (qmail 24424 invoked from network); 25 Jun 2001 22:34:24 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jun 2001 22:34:24 -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 PAA01303; Mon, 25 Jun 2001 15:45:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PMj8B16432; Mon, 25 Jun 2001 15:45:08 -0700 X-mProtect: Mon, 25 Jun 2001 15:45:08 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdDVMTII; Mon, 25 Jun 2001 15:45:06 PDT Message-ID: <3B37BEF2.AA6FD4A0@iprg.nokia.com> Date: Mon, 25 Jun 2001 15:45:06 -0700 From: Rajeev Koodli 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: "'seamoby'" Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: Authentication & Authorization ... References: <35DBB8B7AC89D4118E98009027B1009B017A9DFF@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 Nakhjiri Madjid-MNAKHJI1 wrote: > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, June 25, 2001 2:37 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'seamoby' > Subject: Re: Reactive CT definition: Was Re: [seamoby] RE: > Authentication & Authorization ... > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Rajeev: why would we have to add L2 signaling ? An IP message to initiate > > CT would be needed for the MN and is perhaps useful for other entities. I > > think > > it is doable. > > > > MN>> This IP layer CT is starting to sound like Alchemy :) > > Everybody talks about it, nobody is providing it. Say > > you are using MIPv6 fast handoff, Which message is it, that > > triggers CT? > > Rajeev: F-BU/F-NA. > > MN>> Yes, I suggested it in another email :) So, we agree ! -Rajeev > > > Majid > > Regards, > > -Rajeev > > > > > Madjid From owner-seamoby@diameter.org Mon Jun 25 21:01: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 VAA01198 for ; Mon, 25 Jun 2001 21:01:14 -0400 (EDT) Received: (qmail 25170 invoked by alias); 26 Jun 2001 00:49:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25164 invoked by uid 200); 26 Jun 2001 00:49:38 -0000 Received: (qmail 25158 invoked from network); 26 Jun 2001 00:49:34 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 00:49:34 -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 SAA10348; Mon, 25 Jun 2001 18:00:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5Q10IE21933; Mon, 25 Jun 2001 18:00:18 -0700 X-mProtect: Mon, 25 Jun 2001 18:00:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsOe532; Mon, 25 Jun 2001 18:00:16 PDT Message-ID: <3B37DEA1.B14B8D3C@iprg.nokia.com> Date: Mon, 25 Jun 2001 18:00:17 -0700 From: Rajeev Koodli 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: Kulwinder Atwal CC: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8059@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: > > Additionally, a MN message on a high bandwidth link could be forwarded by > the currentAR to the oldAR to request CT, and at the _same_ time a MN > message could be forwarded by the currentAR to the ParentAR to affect a > route change. > > The route change message may travel to a different entity along a different > link, than the Context Transfer request message. Having them happen in > parrallel could significantly reduce Reactive Context Transfer. > > Exactly. As soon as the MN detects that it has undergone handover, it sends a message which includes BU as an encapsulation. The new AR sends the CT message towards the old AR and the BU towards the mobility agent. We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in Pittsburgh IETF). Regards, -Rajeev From owner-seamoby@diameter.org Mon Jun 25 21:05: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 VAA01268 for ; Mon, 25 Jun 2001 21:05:13 -0400 (EDT) Received: (qmail 25645 invoked by alias); 26 Jun 2001 00:53:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25639 invoked by uid 200); 26 Jun 2001 00:53:26 -0000 Received: (qmail 25634 invoked from network); 26 Jun 2001 00:53:24 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 00:53:24 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 21:04:08 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8080@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Charles E. Perkins'" , Kulwinder Atwal Cc: "'seamoby@cdma-2000.org'" , Pat Calhoun Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Mon, 25 Jun 2001 21:04: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: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Monday, June 25, 2001 12:27 PM > To: Kulwinder Atwal > Cc: 'seamoby@cdma-2000.org'; Pat Calhoun > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > Hello Kulwinder, > > It seems to me that we are getting closer to some definitions > that can work. > > Kulwinder Atwal wrote: > > > The viewpoint is the newAR. Either the newAR is notified for a need > > to CT from oldAR, or MN. > > The difference is on what interface the newAR is notified. > > I agree with this, basically. Please let me know how you think > it applies in the following scenario: > > - Previous access router and new access router agree that the mobile > node should move to the new access router. > - Mobile node is told to move (after this, connectivity between mobile > node and previous access router may fail) > - Access network controller tells new access router to allocate > spectrum for mobile node > - New access router asks previous access router for context For it to work well there needs to be an extra procedure. -The new access router passes to the previous access router the new spectrum allocation info over a wireless control channel. -The prevous access router passes sprectrum allocation info to the MN so that the MN can tune the radio to the correct channel without having to go through a lengthy connection setup phase. > - At the same time, mobile node detects beacon from new access > router and carries out operations for link establishment > - Before finalizing the process of link establishment and the > installation of the transferred context features, the new > access router verifies the credentials of the mobile node. > > How do you think this scenario applies to your classification? To me this is proactive, because the MN does not need to go through a lengthy connection setup phase. > > My answer, is that this is reactive. The new access router is > reacting to the information that the mobile node has arrived. > > I hope we can make definitions to enable the protocol solution > I have outlined, since it my favorite scenario and I believe it > is compatible with 3G designs. > > > It is up to the implementor to take into account particular > network and > > inter-network characteristics and real-time flow > requirements to determine > > how early Pre-Connection Context Transfer needs to be done > to guarrantee > > seamless. > > By previous discussion, we are unlikely to be able to make any > such guarantees. We can, however, make a darned good stab at it. True. - Kulwinder. > > Regards, > Charlie P. > From owner-seamoby@diameter.org Mon Jun 25 21:09: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 VAA01352 for ; Mon, 25 Jun 2001 21:09:50 -0400 (EDT) Received: (qmail 26120 invoked by alias); 26 Jun 2001 00:58:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26114 invoked by uid 200); 26 Jun 2001 00:58:03 -0000 Received: (qmail 26108 invoked from network); 26 Jun 2001 00:58:00 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 00:58:00 -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 SAA10838; Mon, 25 Jun 2001 18:08:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5Q18ic07514; Mon, 25 Jun 2001 18:08:44 -0700 X-mProtect: Mon, 25 Jun 2001 18:08:44 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdzA0lMo; Mon, 25 Jun 2001 18:08:42 PDT Message-ID: <3B37E09B.319B5B1B@iprg.nokia.com> Date: Mon, 25 Jun 2001 18:08:43 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform References: <35DBB8B7AC89D4118E98009027B1009B017A9DFA@IL27EXM10.cig.mot.com> <20010625150550.B22915@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Mon, Jun 25, 2001 at 02:24:42PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > > I prefer that we don't introduce explicit messaging, at least for now. > > Defining a general CT trigger that each technology can map onto should be > > good enough. > > > > I am with option 2. > > so if I understand correctly, perhaps a wireless technology profile would > be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling), cdma2000 profile) > I think we need to define an *option type* that can go with any handover message. To take this one step further, CT itself should focus on defining the feature context defintions that can be carried in different signals. Given that the transport discussion is pending (read: diversity of features requiring different levels of reliability), it is far more productive this way. Regards, -Rajeev > PatC > > > From owner-seamoby@diameter.org Mon Jun 25 22:00: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 WAA03294 for ; Mon, 25 Jun 2001 22:00:40 -0400 (EDT) Received: (qmail 26668 invoked by alias); 26 Jun 2001 01:48:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26661 invoked by uid 200); 26 Jun 2001 01:48:35 -0000 Received: (qmail 26652 invoked from network); 26 Jun 2001 01:48:33 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 01:48:33 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 21:59:17 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8082@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Mon, 25 Jun 2001 21:59:17 -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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, June 25, 2001 2:20 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Kulwinder Atwal wrote: > > > > > > > > > Pre-Connection Context Transfer: The Context Transfer is > > > initiated prior to > > > > the newAR recieving a packet directly from the MN. > > > > > > > > Post-Connection Context Transfer: The Context Transfer is > > > initiated after > > > > the newAR recieves a packet directly from the MN. > > > > Rajeev: I like this classification as well. > > > > > > > *this* I like! However, I disagree with your view on > handoffs. I would > > > like the pre-handoff and post-handoff context transfer. Pre > > > or post first > > > packet doesn't make any sense *at all* to me. How can you > > > guarantee, or know, > > > when the first packet will be received?!? > > > > I can't. How early to do Pre-Connection Context Transfer > to get seamless > > transfer is implementation specific. > > > > The viewpoint is the newAR. Either the newAR is notified > for a need to CT > > from oldAR, or MN. > > The difference is on what interface the newAR is notified. > > > > > > Rajeev: I guess the point is that you would do CT either > > 1. before the new AR becomes the MN's default router, or > 2. after the new AR becomes the MN's default router > > Both 1) and 2) are related to handover. Yes, but handover is pretty vague. Like Gary said, is the start, exact middle, or end of handover, or some special protocol event in the middle. In a collision based wired, or a wireless network we can't be certain which protocol packet will arrive first. Also, we all seem to agree that if pre-connection Context Transfer takes too long due to the uncertain nature of wireless (End-user drives through a tunnel), it is very likely that several post-connection events will pass before the transfer is complete. So, we may start with the best of intentions with the intent of being early enough to not affect the user experience, but events may overtake us such that we find ourselves out of time. So, what do we do at that point in time? A particular technology may find it advantageous to do post-connection, if the data is available, even after the user has experienced a distruption, becuase the connection setup time will be longer than the post-connection Context Transfer time. An other technology may find it advantageous to re-establish new context, because the Context Transfer time (Round-Trip Times) are greater than new connection setup. - Kulwinder. > > Regards, > > -Rajeev > > > > It is up to the implementor to take into account particular > network and > > inter-network characteristics and real-time flow > requirements to determine > > how early Pre-Connection Context Transfer needs to be done > to guarrantee > > seamless. > > > > - Kulwinder. > > > > > In all cases that I > > > know of, some > > > signalling, either at L2 or L3, is used to register the > > > mobile locally (or > > > some signal strength measurements), but there is always an > > > indication of handoff. > > > > > > > > > > But, really why should we care where the request for CT > > > comes from if we are > > > > going to process it just the same? > > > > > > > > The only thing that is important is that the requesting > > > entity recieve a > > > > packet indicating the success or failure mode of the CT > operation. > > > > > > ditto. > > > > > > PatC > > > > From owner-seamoby@diameter.org Mon Jun 25 22:25: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 WAA03615 for ; Mon, 25 Jun 2001 22:25:46 -0400 (EDT) Received: (qmail 27167 invoked by alias); 26 Jun 2001 02:12:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27161 invoked by uid 200); 26 Jun 2001 02:12:32 -0000 Received: (qmail 27156 invoked from network); 26 Jun 2001 02:12:30 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 02:12:30 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 22:23:14 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8083@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , Kulwinder Atwal , "'Mark Smith'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 1: Change access network terminology Date: Mon, 25 Jun 2001 22:23:13 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 25, 2001 2:51 PM > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Mark Smith'; > seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Thursday, June 21, 2001 5:02 PM > To: 'Nakhjiri Madjid-MNAKHJI1'; 'Mark Smith'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Thursday, June 21, 2001 12:38 PM > > To: 'Mark Smith'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] Issue 1: Change access network terminology > > > > > > Mark, > > > > Well, it seems like we are going with ARs (which I like). > > > > I don't know much about MRs and Manet, however I think AR has a more > > precise scope than FN. Does AR imply that the router cannot > be mobile? > > i.e. MR cannot be a subset of AR? > > > > I don't care too much about the physical or software > > definition of a node > > as Kulwinder described (although, from the implementation > point, it is > > important :) > > I care about the functionality. > > For the neutralness in this discussion I use my own favorite > > term CT peer > > instead of FN or AR. > > > > Now, But To answer your question:: > > of course if the node offering CT is mobile, it makes > > a lot of difference, > > 1-how would you handle the security associations for > > pre-authentication between CT peers, if the CT peer is mobile? > > How is this issue different than the MN being mobile? > > MN>> I don't even see the relevance. The discussion was about > how much of different CT scenario do you have if the AR that is > doing CT for an MN is mobile AR or fixed. Not about the MN. > > If the CT is aggreated by a device that appears to the > network as an large > MN how does the network know that the IP stream is for one > physical device, > or multiple physical devices? > > MN>> we are not only talking about the IP streams, we are > talking about the > contexts that relate all these mobiles. All of sudden you > have an AR that is > supposed to do CT for a lot of MNs. How do you feed that AR with the > contexts, What is is this 'feeding' comment about? It is a networking term that I am not familiar with. You send the context from oldAR to newAR. > how do you solve the security, authentication,... issues for all the > context, Is there a specific security issue in this comment? > I am sure you admit that things get more completed when the > CT peers are > mobile themselves (Analogy of IP and Mobile IP should be enough :) I don't believe that you have specific issues here. Broad generalizations do not lead to specific solutions. > > Why should it care as long as the 'root MN' has a valid > security association > that establishes a _Chain_Of_Trust_ to the terminal MN? > > MN>> You need to explain the difference between root MN and > terminal MN > for me. If by root MN you mean AR, then establishing trust > that goes through > a Mobile AR is more difficult. In what way? State specific issues. > > > 3- The context also needs to be available at the CT peer prior > > to the CT, so whatever network element that wants to make sure > > CT peer has enough supply for the next CT, needs to track the > > CT peer to feed it. > > Enough supply of what? Bandwidth? This is an AR Discovery > issue. If the AR > Discovery Protocol is based on triggers I don't see where the > problem is. > > MN>> Supply of context for the CT peer !!! > Specifically, why do you think it will be a problem to supply CT? - Kulwinder. > > -Kulwinder. > > > > > These are problems that do need a WHOLE lot of > consideration when the > > CT peer is mobile. > > > > Madjid > > > > -----Original Message----- > > From: Mark Smith [mailto:mark.smith@comdev.cc] > > Sent: Wednesday, June 20, 2001 3:57 PM > > To: seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 1: Change access network terminology > > > > > > Thank you, yes, that summarizes quite nicely what I was > trying to say. > > > > I'm not trying to say that this isn't a problem, I'm asking > if anyone > > can see why it would be. I can't, but I don't claim to be > > all knowing. :) > > > > -Mark > > > > Kulwinder Atwal wrote: > > > > > To expand on Mark's comment: > > > > > > If we think of an AR or MN as a software > > thread/task/process with its own > > AR > > > context/MN context, instead of physical devices, then we > > should be able to > > > keep the terms AR and MN seperate. > > > > > > 1. A physical device may have just the AR task running, in > > which case it > > is > > > only an AR. > > > > > > 2. A physical device may have just the MN task running, in > > which case it > > is > > > only an MN. > > > > > > 3. A physical device may have a MN task and an AR task > > running in which > > case > > > it is both, but the functionality is modularized. > > > > > > With the AR discovery protocol is possible to learn in a mobile > > environment > > > which mobile device nearby has an AR task running before > > attempting CT. > > > > > > - Kulwinder. > > > > > > > > >>-----Original Message----- > > >>From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > >>Sent: Wednesday, June 20, 2001 3:06 PM > > >>To: Mark Smith > > >>Cc: seamoby@cdma-2000.org > > >>Subject: Re: [seamoby] Issue 1: Change access network terminology > > >> > > >> > > >> > > >>Perhaps I am missing something.. Aren't we concerned about > > >>the "entity" which offers > > >>different features (QoS, HC,..) ? I guess we went with AR > > >>because that's the entity > > >>that typically offers the features. > > >> > > >>Regards, > > >> > > >>-Rajeev > > >> > > >> > > >>Mark Smith wrote: > > >> > > >> > > >>>I guess my question is, does it matter if a Forwarding Node > > >>> > > >>(as Gary has > > >> > > >>>defined them) is also a Mobile Node? What effect does it > > >>> > > >>have on our > > >> > > >>>design/requirement/problem statement? > > >>> > > >>>I think the idea is that, for the sake of a particular CTP > > >>> > > >>session, a > > >> > > >>>node is either an MN or an FN. If it's an FN for this CTP > > >>> > > >>session, it > > >> > > >>>may be an MN for another session, but those two sessions > > >>> > > >>are independant > > >> > > >>>of each other and should be viewed as such. > > >>> > > >>>-Mark > > >>> > > >>>Pat Calhoun wrote: > > >>> > > >>> > > >>>>On Tue, Jun 19, 2001 at 05:13:57PM -0700, Mark Smith wrote: > > >>>> > > >>>> > > >>>>>If we do this (which would be find for me, regardless of > > >>>>> > > >>what my last > > >> > > >>>>>post said :), make sure we define it to address Phil's > > >>>>> > > >>requests. I > > >> > > >>>>>think if we were to specify that an AR, in our case, is > > >>>>> > > >>not neccessarily > > >> > > >>>>>a fixed, wired device, that it can, infact, be an MN > > >>>>> > > >>itself, that should > > >> > > >>>>>do the trick. > > >>>>> > > >>>>>Whatever we call it, it should be defined. > > >>>>> > > >>>>> > > >>>>yes, you posts crossed each other :) > > >>>> > > >>>>Well, if a CT peer can be an MN, then the use of AR is > > >>>> > > >>clearly innapropriate. > > >> > > >>>>AR is an access router, and this is typically where I see > > >>>> > > >>CT being used, but > > >> > > >>>>I understand that there are others, such as Phil, that > > >>>> > > >>see CT as having many > > >> > > >>>>other uses. > > >>>> > > >>>>Perhaps we should first have someone open an issue on > > >>>> > > >>whether an MN can in fact > > >> > > >>>>be a CT peer, and the result of that issue would dictate > > >>>> > > >>the future of this one. > > >> > > >>>>PatC > > >>>> > > >>>> > > > From owner-seamoby@diameter.org Mon Jun 25 23:24:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05630 for ; Mon, 25 Jun 2001 23:24:09 -0400 (EDT) Received: (qmail 27715 invoked by alias); 26 Jun 2001 03:12:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27709 invoked by uid 200); 26 Jun 2001 03:12:25 -0000 Received: (qmail 27700 invoked from network); 26 Jun 2001 03:12:22 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 03:12:22 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 23:23:07 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8084@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Mon, 25 Jun 2001 23:23:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, June 25, 2001 9:00 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > Kulwinder Atwal wrote: > > > > > Additionally, a MN message on a high bandwidth link could > be forwarded by > > the currentAR to the oldAR to request CT, and at the _same_ > time a MN > > message could be forwarded by the currentAR to the ParentAR > to affect a > > route change. > > > > The route change message may travel to a different entity > along a different > > link, than the Context Transfer request message. Having > them happen in > > parrallel could significantly reduce Reactive Context Transfer. > > > > > > Exactly. As soon as the MN detects that it has undergone > handover, it sends a > message which includes BU as an encapsulation. The new AR > sends the CT message > towards the old AR and the BU towards the mobility agent. > We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in > Pittsburgh IETF). Post-Connection Context Transfer: Yes, I think it would take less time for the newAR to process a message from the MN that contained the necessary info. The newAR will need to ask the MN some indentity info anyway like: - Who are you? - Where is your Context located? - Where is your CoA located? Why can't the MN send the info needed to start a route change request and a CT request in the same packet as its identity? The MN is already there at the newAR with all the needed info. With Post-Connection CT the newAR knows nothing about the MN, so it cannot use an L2 Trigger, becuase it does not know who the MN is, where its Context may be, where its CoA maybe. It may turn out that the Context, and CoA are just too far away to attempt a CT (Maybe the MN was moving while experiencing a loss in connectivity). - Kulwinder. > > Regards, > > -Rajeev > > > From owner-seamoby@diameter.org Tue Jun 26 00:03:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06788 for ; Tue, 26 Jun 2001 00:03:53 -0400 (EDT) Received: (qmail 28207 invoked by alias); 26 Jun 2001 03:52:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28201 invoked by uid 200); 26 Jun 2001 03:52:22 -0000 Received: (qmail 28196 invoked from network); 26 Jun 2001 03:52:19 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 03:52:19 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 00:03:04 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8085@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Nakhjiri Madjid-MNAKHJI1'" , Kulwinder Atwal , "'Charles E. Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Tue, 26 Jun 2001 00:03:02 -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: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 25, 2001 4:45 PM > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Kulwinder, > So timing is important. > If you look at the archive, I have always said we are > better off removing timing requirements, if cannot come > up with something better than "timely" or "fast" there. > I think Charlie has brought up a lot of good points and > we are making good progress. Would it be impossible to wait for both Handover Complete and Context Transfer Complete before forwarding packets? It would seem that a good design would need to ensure that both were present before forwarding packets. If it is timing that you are concerned with maybe between 2 to 3 Round-Trip-Times would be a better measure of how soon Context Transfer and Handover need to complete. - Kulwinder. > > If you read my other emails, I said, I don't care what > you call reactive or proactive, as long as we cover > all the scenarios, I am fine. > > Madjid From owner-seamoby@diameter.org Tue Jun 26 10:37:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13543 for ; Tue, 26 Jun 2001 10:37:39 -0400 (EDT) Received: (qmail 32527 invoked by alias); 26 Jun 2001 14:24:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32521 invoked by uid 200); 26 Jun 2001 14:24:56 -0000 Received: (qmail 32516 invoked from network); 26 Jun 2001 14:24:49 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 14:24:49 -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 HAA11814; Tue, 26 Jun 2001 07:35:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5QEZYr24036; Tue, 26 Jun 2001 07:35:34 -0700 X-mProtect: Tue, 26 Jun 2001 07:35:34 -0700 Nokia Silicon Valley Messaging Protection Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdANUq6v; Tue, 26 Jun 2001 07:35:33 PDT Message-ID: <3B389DA4.D534D1F0@iprg.nokia.com> Date: Tue, 26 Jun 2001 07:35:16 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun CC: Gary Kenward , seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT References: <9FBD322B7824D511B36900508BF93C9C9F5D7D@zcard031.ca.nortel.com> <20010622150020.M14828@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with this (the support for multi-phase ct proposal) and would actually go one step further: requirement: a proactive transfer MUST be multiphasic (so that accounting transfer can be transfered after the handoff and config transfer before the handoff) a reactive transfer SHOULD be monophasic. and the distinction between proactive and reactive becomes one of a number of phases. Cedric. Pat Calhoun wrote: > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote: > > I with you up until that last two paragraphs of the proposed new texts. > > The second to last paragraph is editorial, and presumes much about the > > context, > > the ctp design and the implementation. > > ok, I am certainly open to suggestions. > > > As for the last paragraph, I do not see the need to add priority to CTP. > > It is already required that the receiving AR process the context in the > > order received, and this yields the same result (priority can always be > > translated to a measurable performance criteria, such as "processed sooner" > > or "given more resources"). I do not see the utility of a "priority" bit. > > Perhaps you could > > elaborate? > > This isn't a question of a bit. It has to do with sending critical CT > information that is REQUIRED in order to deliver a single packet to the > mobile. This could include HC state, session keys, etc. This state info > is sent first when a handoff is occuring. > > Later (say, 1+ seconds later) additional state is sent. Although this > info is important, it may only be necessary when doing things such as > generating accounting messages, which are infrequent, and not required > during the handoff process. > > > Otherwise I have no problem with the additional requirement (although I > > wonder what an operator would say about "accounting" being "low priority" > > ;^}). > > :) > > PatC > > > > > Gary > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, June 21, 2001 6:37 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > > > > > > > Issue 5: Support for multi-phase CT > > > > > > Submitter name: Pat Calhoun > > > Submitter email address: pcalhoun@eng.sun.com > > > Date first submitted: June 21,2001 > > > Reference: > > > Comment type: T > > > Priority: 1 > > > Section: 4.9 > > > > > > Rationale/Explanation of issue: > > > The current requirement in section 4.9 states that a CT can only > > > occur once all of the state has been gathered. The CT protocol > > > must allow for state to be transferred in phases, where the high > > > priority state (e.g. Header Compression, session keys) is sent > > > first, and low priority items are sent at a later time (e.g. > > > accounting information). > > > > > > This would reduce the size of the high priority CT packets, > > > lower the computational cost of processing the packet, > > > and decrease > > > the handoff latency. > > > > > > Requested change: > > > Change 4.9 to state something like: > > > > > > "4.9 Context information MAY be transferred in phases, > > > allowing for > > > higher priority state to be sent first, and lower priority > > > state to be sent at a later time. > > > > > > The total cost of processing a smaller packet with high priority > > > state is smaller, and would decrease any latency > > > introduced by CT. Each > > > CT profile would need to specify whether it is to be considered > > > as a high or low priority state." > > > > > > Proposal: > > > Adopt the text above in the -01 version of the > > > requirements spec. > > > From owner-seamoby@diameter.org Tue Jun 26 11:33: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 LAA21976 for ; Tue, 26 Jun 2001 11:32:49 -0400 (EDT) Received: (qmail 756 invoked by alias); 26 Jun 2001 15:16:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 750 invoked by uid 200); 26 Jun 2001 15:16:24 -0000 Received: (qmail 745 invoked from network); 26 Jun 2001 15:16:22 -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; 26 Jun 2001 15:16:22 -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 f5QFQh009783 for ; Tue, 26 Jun 2001 11:26:49 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 26 Jun 2001 11:26:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 11:26:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D95@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charlie Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Tue, 26 Jun 2001 11:26:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE54.651E33C0" 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_01C0FE54.651E33C0 Content-Type: text/plain; charset="iso-8859-1" Madjid, Charlie: Case two below that Madjid has outlined would be reactive, IMCO. Borrowing Madjid's numbers for a previous email, with an MN moving at 60 kph, being served by a 10Mpbs stream does not allow any time to be "proactive" between a possible event indicating the start of handover (there are many examples) and "link establishment) - the network must "react" quickly to transfer the context. This whole discussion seems to be focussed on pinning down reactive ct as a process triggered by a specific event. To me, the concepts border, if not lie directly in solution space. Certainly, I find the definition far too restrictive at this stage. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 25, 2001 5:40 PM > To: 'Charlie Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Hello Charlie, > > > Seems like we have reached an agreement based on our common > interpretation of proactive case, please see below. I added > the 3 cases > again, just to make sure. I cut some of less important text. > > The previous email, that you asked about, is also attached, > the cases were > > , 1-CT trigger arrives before Handover trigger (what starts the > handover, it could be at oldAR, at newAR or at MN) and naturally > before link establishment. > > 2-CT trigger arrives after handover trigger, but before link layer > establishment with newAR. > > 3-CT trigger arrives after link layer establishment with newAR. > > If you agree that 1 and 2 are proactive and 3 is reactive, > then we are in agreement and you can change the definition > of proactive and reactive based on starting event (link establishment) > > I just don't want to have to wait for link establishment to > start CT. > > > > MN>> I agree, however, it is not very hard to change it, to say > > Packet arrival at newAR (since that is what matters for CT). > > Not having feature contexts might make the packet arrival defintion > > fuzzier if you don't know how to interprete packets. > > However, as I said you can replace packet arrival with an > > almost equivalent event (say another message that makes > packets arrive > > at newAR). > > Somehow, though, this seems to miss the point. For reactive, > the context transfer should be reacting to something -- say, the > arrival of a mobile node at the new access network. Whether > this arrival is determined by the transmission of a layer-3 > packet is important, yet necessarily comes after the arrival. > On the other hand, by protocol the only way we can detect > the arrival is by some packet being sent somewhere. > That's why I tried to make the definition in terms of the > _ability_ of the mobile node to send a packet. > > MN>>>> I agree with you. as I said if your proactive covers > the case where handover signaling has started but link is not > established but you still can start CT without waiting for > link establishment, then that is fine. > > I'm curious how a message could be delivered to enable packets, > when the message itself has to be the content of a packet. > This makes me think that we are using different definitions for > what a "packet" is supposed to be. For me it's a bag of bits, > and can be used at layer 2. > > > MN>>point was to define a deadline for CT to be complete, and > > basing everything on the starting event, does not provide any > > timing requirements for CT, unless you want to leave it open > > for now. > > I suggest that the starting event is the right way, and that > all of the > protocols involved have to be robust enough to work anyway if > something takes longer. We should just make it work as fast > as we can. > > MN>>>> Again see my comments above, I can see the benefit of > using the starting event for the definition over packet arrival > (that we had earlier), as long as you expand the proactive case. > > > > In Mobile IP, we defined 4 scenarios. They were very useful: > - Mobile initiated after departure > - Network initiated after departure > - Mobile initiated before departure > - Network initiated before departure > > MN>> Departure is a bit fuzzy here, does not tell you > what happens to the MN-oldAR or MN-newAR link. > Also whether Mobile initiates or network is not very > critical for CT. But I see that identifying scenarios > are important, and that is why I asked for event sequences > and some people took it the wrong way and interpreted > that I like to see CT and handover to happen in a sequential > manner. > > Context transfer can be sensible in all four of these cases. > > > > ****Unless you offer a clear event sequence and show > different Handover > > > stages and the need of packet delivery for various > feature context, > > > I don't think we can change our definition and base it on an start > > > event.***** > > > > I'm not sure if my example would be welcome, but here goes > > anyway: > > > > 1) Mobile node shows up at new access router (802.11, say) > > 2) Mobile node asks new access router to collect context > > from previous router. Mobile includes authentication data > > that can be checked by previous access router. > > 3) New access router sends request for context transfer to > > previous router. > > 4) Previous access router checks the authentication data, and > > upon approval delivers the requested context features > > 5) New access router installs the delivered context features, > > and (optionally) notifies the mobile node about the status. > > > > This is reactive, and it could be very valuable for certain > > kinds of context. > > > > MN>> what if the newAR receives notification about an iminent > > arrival before the MN actually arrives at the newAR. This is > > common in cellular! Which category does this fall into? > > Proactive? If your proactive includes this, then we are fine. > > By my understanding, this would be proactive; I am guessing that > the new access router receives context information as well as > the basic indication of the arrival of the mobile node. But that > amounts to an (important!) optimization. > > MN>> Then we are in agreement!!!! > > > MN>> Well, I said that since Rajeev was dismissing the > > possibility of having the context to handle packets in time. > > I agree not all systems/ scnearios could support proactive, but > > does that mean we exclude it? > > I definitely propose that we not exclude reactive context transfer. > > > MN>> My question was, don't you think CT should have timing > > requirements, so it introduces zero (proactive) or as little > > delay as possible. Don't take me wrong, I don't know enough > > about all the features to believe 100% in zero delay, but it > > is a scenario, that should be included. > > I think that context transfer should be optimized for the best > performance in time. I don't see how you can realistically put > absolute time bounds on the process, though. What would it > be? 30ms? 300ms? Shouldn't the same protocol work for > transferring video context as well as audio context (if there needed > to be such a thing)? > > MN>> I agree, absolute numbers don't make sense in a general > requirement document, I have always said that. > > Regards, > Madjid N. > > > ------_=_NextPart_001_01C0FE54.651E33C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] CT trigger or CT completion? was: proactive and re = active CT definitions

Madjid, Charlie:

Case two below that Madjid has outlined would be = reactive, IMCO.
Borrowing Madjid's numbers for a previous email, = with an MN moving at
60 kph, being served by a 10Mpbs stream does not = allow any time to
be "proactive" between a possible event = indicating the start of handover
(there are many examples) and "link = establishment) - the network must "react" quickly to transfer = the context.

This whole discussion seems to be focussed on pinning = down reactive ct as a
process triggered by a specific event. To me, the = concepts border, if not
lie directly in solution space. Certainly, I find = the definition far
too restrictive at this stage.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Monday, June 25, 2001 5:40 PM
> To: 'Charlie Perkins'; Nakhjiri = Madjid-MNAKHJI1
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] CT trigger or CT = completion? was: proactive and
> re active CT definitions
>
>
> Hello Charlie,
>
>
> Seems like we have reached an agreement based = on our common
> interpretation of proactive case, please see = below. I added
> the 3 cases
> again, just to make sure.  I cut some of = less important text.
>
> The previous email, that you asked about, is = also attached,
> the cases were
>
> , 1-CT trigger arrives before Handover trigger = (what starts the
> handover, it could be at oldAR, at newAR or at = MN) and naturally
> before link establishment.
>
> 2-CT trigger arrives after handover trigger, = but before link layer
> establishment with newAR.
>
> 3-CT trigger arrives after link layer = establishment with newAR.
>
> If you agree that 1 and 2 are proactive and 3 = is reactive,
> then we are in agreement and you can change the = definition
> of proactive and reactive based on starting = event (link establishment)
>
> I just don't want to have to wait for link = establishment to
> start CT.
>
>
> > MN>> I agree, however, it is not = very hard to change it, to say
> > Packet arrival at newAR (since that is = what matters for CT).
> > Not having feature contexts might make the = packet arrival defintion
> > fuzzier if you don't know how to = interprete packets.
> > However, as I said you can replace packet = arrival with an
> > almost equivalent event (say another = message that makes
> packets arrive
> > at newAR).
>
> Somehow, though, this seems to miss the = point.  For reactive,
> the context transfer should be reacting to = something -- say, the
> arrival of a mobile node at the new access = network.  Whether
> this arrival is determined by the transmission = of a layer-3
> packet is important, yet necessarily comes = after the arrival.
> On the other hand, by protocol the only way we = can detect
> the arrival is by some packet being sent = somewhere.
> That's why I tried to make the definition in = terms of the
> _ability_ of the mobile node to send a = packet.
>
> MN>>>> I agree with you. as I said = if your proactive covers
> the case where handover signaling has started = but link is not
> established but you still can start CT without = waiting for
> link establishment, then that is fine.
>
> I'm curious how a message could be delivered to = enable packets,
> when the message itself has to be the content = of a packet.
> This makes me think that we are using different = definitions for
> what a "packet" is supposed to = be.  For me it's a bag of bits,
> and can be used at layer 2.
>
> > MN>>point was to define a deadline = for CT to be complete, and
> > basing everything on the starting event, = does not provide any
> > timing requirements for CT, unless you = want to leave it open
> > for now.
>
> I suggest that the starting event is the right = way, and that
> all of the
> protocols involved have to be robust enough to = work anyway if
> something takes longer.  We should just = make it work as fast
> as we can.
>
> MN>>>> Again see my comments above, = I can see the benefit of
> using the starting event for the definition = over packet arrival
> (that we had earlier), as long as you expand = the proactive case.
>
>
>
> In Mobile IP, we defined 4 scenarios.  = They were very useful:
> - Mobile initiated after departure
> - Network initiated after departure
> - Mobile initiated before departure
> - Network initiated before departure
>
> MN>> Departure is a bit fuzzy here, does = not tell you
> what happens to the MN-oldAR or MN-newAR link. =
> Also whether Mobile initiates or network is not = very
> critical for CT. But I see that identifying = scenarios
> are important, and that is why I asked for = event sequences
> and some people took it the wrong way and = interpreted
> that I like to see CT and handover to happen in = a sequential
> manner.
>
> Context transfer can be sensible in all four of = these cases.
>
> > > ****Unless you offer a clear event = sequence and show
> different Handover
> > > stages and the need of packet = delivery for various
> feature context,
> > > I don't think we can change our = definition and base it on an start
> > > event.*****
> >
> > I'm not sure if my example would be = welcome, but here goes
> > anyway:
> >
> > 1) Mobile node shows up at new access = router (802.11, say)
> > 2) Mobile node asks new access router to = collect context
> >    from previous = router.  Mobile includes authentication data
> >    that can be checked by = previous access router.
> > 3) New access router sends request for = context transfer to
> >    previous router.
> > 4) Previous access router checks the = authentication data, and
> >    upon approval delivers = the requested context features
> > 5) New access router installs the = delivered context features,
> >    and (optionally) = notifies the mobile node about the status.
> >
> > This is reactive, and it could be very = valuable for certain
> > kinds of context.
> >
> > MN>> what if the newAR receives = notification about an iminent
> > arrival before the MN actually arrives at = the newAR. This is
> > common in cellular! Which category does = this fall into?
> > Proactive? If your proactive includes = this, then we are fine.
>
> By my understanding, this would be proactive; I = am guessing that
> the new access router receives context = information as well as
> the basic indication of the arrival of the = mobile node.  But that
> amounts to an (important!) optimization.
>
> MN>> Then we are in agreement!!!!
>
> > MN>> Well, I said that since Rajeev = was dismissing the
> > possibility of having the context to = handle packets in time.
> > I agree not all systems/ scnearios could = support proactive, but
> > does that mean we exclude it?
>
> I definitely propose that we not exclude = reactive context transfer.
>
> > MN>> My question was, don't you = think CT should have timing
> > requirements, so  it introduces zero = (proactive) or as little
> > delay as possible. Don't take me wrong, I = don't know enough
> > about all the features to believe 100% in = zero delay, but it
> > is a scenario, that should be = included.
>
> I think that context transfer should be = optimized for the best
> performance in time.  I don't see how you = can realistically put
> absolute time bounds on the process, = though.  What would it
> be?  30ms?  300ms?  Shouldn't = the same protocol work for
> transferring video context as well as audio = context (if there needed
> to be such a thing)?
>
> MN>> I agree, absolute numbers don't make = sense in a general
> requirement document, I have always said = that.
>
> Regards,
> Madjid N.
>
>
>

------_=_NextPart_001_01C0FE54.651E33C0-- From owner-seamoby@diameter.org Tue Jun 26 11:39: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 LAA22613 for ; Tue, 26 Jun 2001 11:39:32 -0400 (EDT) Received: (qmail 756 invoked by alias); 26 Jun 2001 15:16:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 750 invoked by uid 200); 26 Jun 2001 15:16:24 -0000 Received: (qmail 745 invoked from network); 26 Jun 2001 15:16:22 -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; 26 Jun 2001 15:16:22 -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 f5QFQh009783 for ; Tue, 26 Jun 2001 11:26:49 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 26 Jun 2001 11:26:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 11:26:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D95@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Charlie Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Tue, 26 Jun 2001 11:26:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE54.651E33C0" 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_01C0FE54.651E33C0 Content-Type: text/plain; charset="iso-8859-1" Madjid, Charlie: Case two below that Madjid has outlined would be reactive, IMCO. Borrowing Madjid's numbers for a previous email, with an MN moving at 60 kph, being served by a 10Mpbs stream does not allow any time to be "proactive" between a possible event indicating the start of handover (there are many examples) and "link establishment) - the network must "react" quickly to transfer the context. This whole discussion seems to be focussed on pinning down reactive ct as a process triggered by a specific event. To me, the concepts border, if not lie directly in solution space. Certainly, I find the definition far too restrictive at this stage. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 25, 2001 5:40 PM > To: 'Charlie Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Hello Charlie, > > > Seems like we have reached an agreement based on our common > interpretation of proactive case, please see below. I added > the 3 cases > again, just to make sure. I cut some of less important text. > > The previous email, that you asked about, is also attached, > the cases were > > , 1-CT trigger arrives before Handover trigger (what starts the > handover, it could be at oldAR, at newAR or at MN) and naturally > before link establishment. > > 2-CT trigger arrives after handover trigger, but before link layer > establishment with newAR. > > 3-CT trigger arrives after link layer establishment with newAR. > > If you agree that 1 and 2 are proactive and 3 is reactive, > then we are in agreement and you can change the definition > of proactive and reactive based on starting event (link establishment) > > I just don't want to have to wait for link establishment to > start CT. > > > > MN>> I agree, however, it is not very hard to change it, to say > > Packet arrival at newAR (since that is what matters for CT). > > Not having feature contexts might make the packet arrival defintion > > fuzzier if you don't know how to interprete packets. > > However, as I said you can replace packet arrival with an > > almost equivalent event (say another message that makes > packets arrive > > at newAR). > > Somehow, though, this seems to miss the point. For reactive, > the context transfer should be reacting to something -- say, the > arrival of a mobile node at the new access network. Whether > this arrival is determined by the transmission of a layer-3 > packet is important, yet necessarily comes after the arrival. > On the other hand, by protocol the only way we can detect > the arrival is by some packet being sent somewhere. > That's why I tried to make the definition in terms of the > _ability_ of the mobile node to send a packet. > > MN>>>> I agree with you. as I said if your proactive covers > the case where handover signaling has started but link is not > established but you still can start CT without waiting for > link establishment, then that is fine. > > I'm curious how a message could be delivered to enable packets, > when the message itself has to be the content of a packet. > This makes me think that we are using different definitions for > what a "packet" is supposed to be. For me it's a bag of bits, > and can be used at layer 2. > > > MN>>point was to define a deadline for CT to be complete, and > > basing everything on the starting event, does not provide any > > timing requirements for CT, unless you want to leave it open > > for now. > > I suggest that the starting event is the right way, and that > all of the > protocols involved have to be robust enough to work anyway if > something takes longer. We should just make it work as fast > as we can. > > MN>>>> Again see my comments above, I can see the benefit of > using the starting event for the definition over packet arrival > (that we had earlier), as long as you expand the proactive case. > > > > In Mobile IP, we defined 4 scenarios. They were very useful: > - Mobile initiated after departure > - Network initiated after departure > - Mobile initiated before departure > - Network initiated before departure > > MN>> Departure is a bit fuzzy here, does not tell you > what happens to the MN-oldAR or MN-newAR link. > Also whether Mobile initiates or network is not very > critical for CT. But I see that identifying scenarios > are important, and that is why I asked for event sequences > and some people took it the wrong way and interpreted > that I like to see CT and handover to happen in a sequential > manner. > > Context transfer can be sensible in all four of these cases. > > > > ****Unless you offer a clear event sequence and show > different Handover > > > stages and the need of packet delivery for various > feature context, > > > I don't think we can change our definition and base it on an start > > > event.***** > > > > I'm not sure if my example would be welcome, but here goes > > anyway: > > > > 1) Mobile node shows up at new access router (802.11, say) > > 2) Mobile node asks new access router to collect context > > from previous router. Mobile includes authentication data > > that can be checked by previous access router. > > 3) New access router sends request for context transfer to > > previous router. > > 4) Previous access router checks the authentication data, and > > upon approval delivers the requested context features > > 5) New access router installs the delivered context features, > > and (optionally) notifies the mobile node about the status. > > > > This is reactive, and it could be very valuable for certain > > kinds of context. > > > > MN>> what if the newAR receives notification about an iminent > > arrival before the MN actually arrives at the newAR. This is > > common in cellular! Which category does this fall into? > > Proactive? If your proactive includes this, then we are fine. > > By my understanding, this would be proactive; I am guessing that > the new access router receives context information as well as > the basic indication of the arrival of the mobile node. But that > amounts to an (important!) optimization. > > MN>> Then we are in agreement!!!! > > > MN>> Well, I said that since Rajeev was dismissing the > > possibility of having the context to handle packets in time. > > I agree not all systems/ scnearios could support proactive, but > > does that mean we exclude it? > > I definitely propose that we not exclude reactive context transfer. > > > MN>> My question was, don't you think CT should have timing > > requirements, so it introduces zero (proactive) or as little > > delay as possible. Don't take me wrong, I don't know enough > > about all the features to believe 100% in zero delay, but it > > is a scenario, that should be included. > > I think that context transfer should be optimized for the best > performance in time. I don't see how you can realistically put > absolute time bounds on the process, though. What would it > be? 30ms? 300ms? Shouldn't the same protocol work for > transferring video context as well as audio context (if there needed > to be such a thing)? > > MN>> I agree, absolute numbers don't make sense in a general > requirement document, I have always said that. > > Regards, > Madjid N. > > > ------_=_NextPart_001_01C0FE54.651E33C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] CT trigger or CT completion? was: proactive and re = active CT definitions

Madjid, Charlie:

Case two below that Madjid has outlined would be = reactive, IMCO.
Borrowing Madjid's numbers for a previous email, = with an MN moving at
60 kph, being served by a 10Mpbs stream does not = allow any time to
be "proactive" between a possible event = indicating the start of handover
(there are many examples) and "link = establishment) - the network must "react" quickly to transfer = the context.

This whole discussion seems to be focussed on pinning = down reactive ct as a
process triggered by a specific event. To me, the = concepts border, if not
lie directly in solution space. Certainly, I find = the definition far
too restrictive at this stage.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Monday, June 25, 2001 5:40 PM
> To: 'Charlie Perkins'; Nakhjiri = Madjid-MNAKHJI1
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] CT trigger or CT = completion? was: proactive and
> re active CT definitions
>
>
> Hello Charlie,
>
>
> Seems like we have reached an agreement based = on our common
> interpretation of proactive case, please see = below. I added
> the 3 cases
> again, just to make sure.  I cut some of = less important text.
>
> The previous email, that you asked about, is = also attached,
> the cases were
>
> , 1-CT trigger arrives before Handover trigger = (what starts the
> handover, it could be at oldAR, at newAR or at = MN) and naturally
> before link establishment.
>
> 2-CT trigger arrives after handover trigger, = but before link layer
> establishment with newAR.
>
> 3-CT trigger arrives after link layer = establishment with newAR.
>
> If you agree that 1 and 2 are proactive and 3 = is reactive,
> then we are in agreement and you can change the = definition
> of proactive and reactive based on starting = event (link establishment)
>
> I just don't want to have to wait for link = establishment to
> start CT.
>
>
> > MN>> I agree, however, it is not = very hard to change it, to say
> > Packet arrival at newAR (since that is = what matters for CT).
> > Not having feature contexts might make the = packet arrival defintion
> > fuzzier if you don't know how to = interprete packets.
> > However, as I said you can replace packet = arrival with an
> > almost equivalent event (say another = message that makes
> packets arrive
> > at newAR).
>
> Somehow, though, this seems to miss the = point.  For reactive,
> the context transfer should be reacting to = something -- say, the
> arrival of a mobile node at the new access = network.  Whether
> this arrival is determined by the transmission = of a layer-3
> packet is important, yet necessarily comes = after the arrival.
> On the other hand, by protocol the only way we = can detect
> the arrival is by some packet being sent = somewhere.
> That's why I tried to make the definition in = terms of the
> _ability_ of the mobile node to send a = packet.
>
> MN>>>> I agree with you. as I said = if your proactive covers
> the case where handover signaling has started = but link is not
> established but you still can start CT without = waiting for
> link establishment, then that is fine.
>
> I'm curious how a message could be delivered to = enable packets,
> when the message itself has to be the content = of a packet.
> This makes me think that we are using different = definitions for
> what a "packet" is supposed to = be.  For me it's a bag of bits,
> and can be used at layer 2.
>
> > MN>>point was to define a deadline = for CT to be complete, and
> > basing everything on the starting event, = does not provide any
> > timing requirements for CT, unless you = want to leave it open
> > for now.
>
> I suggest that the starting event is the right = way, and that
> all of the
> protocols involved have to be robust enough to = work anyway if
> something takes longer.  We should just = make it work as fast
> as we can.
>
> MN>>>> Again see my comments above, = I can see the benefit of
> using the starting event for the definition = over packet arrival
> (that we had earlier), as long as you expand = the proactive case.
>
>
>
> In Mobile IP, we defined 4 scenarios.  = They were very useful:
> - Mobile initiated after departure
> - Network initiated after departure
> - Mobile initiated before departure
> - Network initiated before departure
>
> MN>> Departure is a bit fuzzy here, does = not tell you
> what happens to the MN-oldAR or MN-newAR link. =
> Also whether Mobile initiates or network is not = very
> critical for CT. But I see that identifying = scenarios
> are important, and that is why I asked for = event sequences
> and some people took it the wrong way and = interpreted
> that I like to see CT and handover to happen in = a sequential
> manner.
>
> Context transfer can be sensible in all four of = these cases.
>
> > > ****Unless you offer a clear event = sequence and show
> different Handover
> > > stages and the need of packet = delivery for various
> feature context,
> > > I don't think we can change our = definition and base it on an start
> > > event.*****
> >
> > I'm not sure if my example would be = welcome, but here goes
> > anyway:
> >
> > 1) Mobile node shows up at new access = router (802.11, say)
> > 2) Mobile node asks new access router to = collect context
> >    from previous = router.  Mobile includes authentication data
> >    that can be checked by = previous access router.
> > 3) New access router sends request for = context transfer to
> >    previous router.
> > 4) Previous access router checks the = authentication data, and
> >    upon approval delivers = the requested context features
> > 5) New access router installs the = delivered context features,
> >    and (optionally) = notifies the mobile node about the status.
> >
> > This is reactive, and it could be very = valuable for certain
> > kinds of context.
> >
> > MN>> what if the newAR receives = notification about an iminent
> > arrival before the MN actually arrives at = the newAR. This is
> > common in cellular! Which category does = this fall into?
> > Proactive? If your proactive includes = this, then we are fine.
>
> By my understanding, this would be proactive; I = am guessing that
> the new access router receives context = information as well as
> the basic indication of the arrival of the = mobile node.  But that
> amounts to an (important!) optimization.
>
> MN>> Then we are in agreement!!!!
>
> > MN>> Well, I said that since Rajeev = was dismissing the
> > possibility of having the context to = handle packets in time.
> > I agree not all systems/ scnearios could = support proactive, but
> > does that mean we exclude it?
>
> I definitely propose that we not exclude = reactive context transfer.
>
> > MN>> My question was, don't you = think CT should have timing
> > requirements, so  it introduces zero = (proactive) or as little
> > delay as possible. Don't take me wrong, I = don't know enough
> > about all the features to believe 100% in = zero delay, but it
> > is a scenario, that should be = included.
>
> I think that context transfer should be = optimized for the best
> performance in time.  I don't see how you = can realistically put
> absolute time bounds on the process, = though.  What would it
> be?  30ms?  300ms?  Shouldn't = the same protocol work for
> transferring video context as well as audio = context (if there needed
> to be such a thing)?
>
> MN>> I agree, absolute numbers don't make = sense in a general
> requirement document, I have always said = that.
>
> Regards,
> Madjid N.
>
>
>

------_=_NextPart_001_01C0FE54.651E33C0-- From owner-seamoby@diameter.org Tue Jun 26 12:46: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 MAA26024 for ; Tue, 26 Jun 2001 12:46:37 -0400 (EDT) Received: (qmail 2050 invoked by alias); 26 Jun 2001 16:35:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2044 invoked by uid 200); 26 Jun 2001 16:35:13 -0000 Received: (qmail 2036 invoked from network); 26 Jun 2001 16:35:11 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 16:35:11 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 12:45:50 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445544@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'kempf'" , seamoby@cdma-2000.org, pcalhoun@diameter.org Subject: RE: [seamoby] Question on 4.2 Date: Tue, 26 Jun 2001 12:45:41 -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 Hi James, I have tried to start such an effort many times. Who is this bunch of you? Whenever I have tried in the past, people were not interested. Also, I sent a request to Scott B. a couple of months ago to get this started in the sub-IP area. I wrote up a draft for the WG charter. He never got back. So, I guess I would like to know if you created a mail list or if not I welcome you to use: http://internet.motlabs.com/mailman/listinfo/wirelessinternet Thanks, Phil > -----Original Message----- > From: kempf [mailto:James.Kempf@Sun.COM] > Sent: Saturday, June 23, 2001 12:15 PM > To: seamoby@cdma-2000.org; pcalhoun@diameter.org > Subject: Re: [seamoby] Question on 4.2 > > > Pat, > > A bunch of us are in discussion about doing a draft on abstract L2 > triggers. Currently, there is some unpublished material and the > material embedded in the FMIPv4 draft that we would like to pull > together. This should allow people to refer to a common source > on L2 triggers. We are unclear yet whether this belongs in MIP, > Seamoby, or other. It is clearly important for the MIP fast handoff > work, and also perhaps Seamoby context transfer. > > jak > > From owner-seamoby@diameter.org Tue Jun 26 13:21: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 NAA27835 for ; Tue, 26 Jun 2001 13:21:48 -0400 (EDT) Received: (qmail 2621 invoked by alias); 26 Jun 2001 17:10:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2615 invoked by uid 200); 26 Jun 2001 17:10:08 -0000 Received: (qmail 2610 invoked from network); 26 Jun 2001 17:10:06 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 17:10:06 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 13:20:51 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445545@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'James Kempf'" , "'seamoby@diameter.org'" Subject: RE: [seamoby] Question on 4.2 Date: Tue, 26 Jun 2001 13:20:43 -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 That is unfortunate. A generic L2 triggering mechanism COULD be very useful to QoS WGs, MIP, MANET, and SeaMoby. I do realize the IETF is better suited to work on very narrow problem statements and generalizations have to be done with the "death-by-a-thousand cuts" method. Best regards, Phil > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Tuesday, June 26, 2001 1:01 PM > To: PNeumiller@MeshNetworks.com > Cc: James.Kempf@Sun.COM > Subject: RE: [seamoby] Question on 4.2 > > > Thanx for the pointer, but I think we are going to do this as a draft > rather than a working group, probably through MIP first because > it keeps coming up. > > jak > > >Delivered-To: seamoby-list@charizard.diameter.org > >From: Phillip Neumiller > >To: "'kempf'" , seamoby@cdma-2000.org, > pcalhoun@diameter.org > >Subject: RE: [seamoby] Question on 4.2 > >Date: Tue, 26 Jun 2001 12:45:41 -0400 > > > >Hi James, > > > >I have tried to start such an effort many times. Who is this > >bunch of you? Whenever I have tried in the past, people were > >not interested. Also, I sent a request to Scott B. a > >couple of months ago to get this started in the sub-IP area. > >I wrote up a draft for the WG charter. He never got back. > >So, I guess I would like to know if you created a mail list or > >if not I welcome you to use: > > > >http://internet.motlabs.com/mailman/listinfo/wirelessinternet > > > >Thanks, > > > >Phil > > > >> -----Original Message----- > >> From: kempf [mailto:James.Kempf@Sun.COM] > >> Sent: Saturday, June 23, 2001 12:15 PM > >> To: seamoby@cdma-2000.org; pcalhoun@diameter.org > >> Subject: Re: [seamoby] Question on 4.2 > >> > >> > >> Pat, > >> > >> A bunch of us are in discussion about doing a draft on abstract L2 > >> triggers. Currently, there is some unpublished material and the > >> material embedded in the FMIPv4 draft that we would like to pull > >> together. This should allow people to refer to a common source > >> on L2 triggers. We are unclear yet whether this belongs in MIP, > >> Seamoby, or other. It is clearly important for the MIP fast handoff > >> work, and also perhaps Seamoby context transfer. > >> > >> jak > >> > >> > From owner-seamoby@diameter.org Tue Jun 26 13:27: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 NAA28238 for ; Tue, 26 Jun 2001 13:27:01 -0400 (EDT) Received: (qmail 3104 invoked by alias); 26 Jun 2001 17:15:01 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3098 invoked by uid 200); 26 Jun 2001 17:15:01 -0000 Received: (qmail 3093 invoked from network); 26 Jun 2001 17:14:59 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 17:14:59 -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 LAA21948; Tue, 26 Jun 2001 11:26:08 -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 KAA18558; Tue, 26 Jun 2001 10:26:07 -0700 (PDT) Message-Id: <200106261726.KAA18558@heliopolis.eng.sun.com> Date: Tue, 26 Jun 2001 10:26:07 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Question on 4.2 To: James.Kempf@Sun.COM, seamoby@diameter.org, PNeumiller@MeshNetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MbAzGJ1PMSbKXdmCI1f1kA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Phil, I believe there is an existing draft that addresses designing an L2 to work well with IP, this draft would be the same for mobility. The only reason we are working through MIP is because the need is great. The FMIPv4 draft contains a section on L2 triggers, and we would like to extract that and include it with some other material (like security) about what is needed for a good L2 to support IP mobility. Naturally, Seamoby, MIP, etc. will all get the chance to review. Perhaps at some point it would make sense to make it be a focus for a working group, but it seemed to make more sense to start small and see whether we could complete it in the context of a working group that has a serious need for the work before trying something larger, which, as you indicated, hasn't had much success. jak >From: Phillip Neumiller >To: "'James Kempf'" , "'seamoby@diameter.org'" >Subject: RE: [seamoby] Question on 4.2 >Date: Tue, 26 Jun 2001 13:20:43 -0400 > >That is unfortunate. A generic L2 triggering mechanism COULD >be very useful to QoS WGs, MIP, MANET, and SeaMoby. I do >realize the IETF is better suited to work on very narrow >problem statements and generalizations have to be done with >the "death-by-a-thousand cuts" method. > >Best regards, > >Phil > >> -----Original Message----- >> From: James Kempf [mailto:James.Kempf@Sun.COM] >> Sent: Tuesday, June 26, 2001 1:01 PM >> To: PNeumiller@MeshNetworks.com >> Cc: James.Kempf@Sun.COM >> Subject: RE: [seamoby] Question on 4.2 >> >> >> Thanx for the pointer, but I think we are going to do this as a draft >> rather than a working group, probably through MIP first because >> it keeps coming up. >> >> jak >> >> >Delivered-To: seamoby-list@charizard.diameter.org >> >From: Phillip Neumiller >> >To: "'kempf'" , seamoby@cdma-2000.org, >> pcalhoun@diameter.org >> >Subject: RE: [seamoby] Question on 4.2 >> >Date: Tue, 26 Jun 2001 12:45:41 -0400 >> > >> >Hi James, >> > >> >I have tried to start such an effort many times. Who is this >> >bunch of you? Whenever I have tried in the past, people were >> >not interested. Also, I sent a request to Scott B. a >> >couple of months ago to get this started in the sub-IP area. >> >I wrote up a draft for the WG charter. He never got back. >> >So, I guess I would like to know if you created a mail list or >> >if not I welcome you to use: >> > >> >http://internet.motlabs.com/mailman/listinfo/wirelessinternet >> > >> >Thanks, >> > >> >Phil >> > >> >> -----Original Message----- >> >> From: kempf [mailto:James.Kempf@Sun.COM] >> >> Sent: Saturday, June 23, 2001 12:15 PM >> >> To: seamoby@cdma-2000.org; pcalhoun@diameter.org >> >> Subject: Re: [seamoby] Question on 4.2 >> >> >> >> >> >> Pat, >> >> >> >> A bunch of us are in discussion about doing a draft on abstract L2 >> >> triggers. Currently, there is some unpublished material and the >> >> material embedded in the FMIPv4 draft that we would like to pull >> >> together. This should allow people to refer to a common source >> >> on L2 triggers. We are unclear yet whether this belongs in MIP, >> >> Seamoby, or other. It is clearly important for the MIP fast handoff >> >> work, and also perhaps Seamoby context transfer. >> >> >> >> jak >> >> >> >> >> From owner-seamoby@diameter.org Tue Jun 26 14:23: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 OAA01889 for ; Tue, 26 Jun 2001 14:23:03 -0400 (EDT) Received: (qmail 3813 invoked by alias); 26 Jun 2001 18:10:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3807 invoked by uid 200); 26 Jun 2001 18:10:37 -0000 Received: (qmail 3802 invoked from network); 26 Jun 2001 18:10:36 -0000 Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 18:10:36 -0000 Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f5QIV1b08888; Tue, 26 Jun 2001 11:31:01 -0700 (PDT) Date: Tue, 26 Jun 2001 11:31:01 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: James Kempf cc: seamoby@diameter.org, PNeumiller@MeshNetworks.com Subject: RE: [seamoby] Question on 4.2 In-Reply-To: <200106261726.KAA18558@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk Hi, I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is devoted for describing L2 trigger, required for Pre- and Post-Registration methods. I think the section is well written and really trying to unveil the role of L2 trigger. Actually, it is quite informational as well since we haven't quite seen anything in this detail regarding L2 trigger. IMHO, though, what SeaMoby requires (in terms of handoff trigger) is the superset that not only covers the scope of the triggering mechanism that FMIPv4 draft requires, but also other context. As an example, L2 trigger described in FMIPv4 draft Section 1.3 specifies the recipient, content (IP address/IP address identifier etc.), and timing of the arrival of this special signal. CT trigger may require more information than these. Going back to discussions regarding L2/L3 trigger between Rajeev and Kulwinder, I think SeaMoby also should consider abstract description of this trigger business. I've always thought about pursuiting a work in triggering mechanism, but I wasn't sure I'm digging into the legitimate scope of work for the WG. Can anybody share some thoughts regarding this with me? Lastly, the trigger mechanism should be constructed in the following steps - this is my opinion and you are welcome to disagree with me. 1. Fast movement detection/prediction 2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) 3. Signaling handoff initiator (trigger is in fact a special signal) I need your thoughts on these. THank you, Youngjune On Tue, 26 Jun 2001, James Kempf wrote: > Phil, > > I believe there is an existing draft that addresses designing an L2 > to work well with IP, this draft would be the same for mobility. > The only reason we are working through MIP is because the need is > great. The FMIPv4 draft contains a section on L2 triggers, and > we would like to extract that and include it with some other > material (like security) about what is needed for a good L2 > to support IP mobility. Naturally, Seamoby, MIP, etc. will > all get the chance to review. > > Perhaps at some point it would make sense to make it be a focus > for a working group, but it seemed to make more sense to start > small and see whether we could complete it in the context of > a working group that has a serious need for the work before > trying something larger, which, as you indicated, hasn't had > much success. > > jak > > >From: Phillip Neumiller > >To: "'James Kempf'" , "'seamoby@diameter.org'" > > >Subject: RE: [seamoby] Question on 4.2 > >Date: Tue, 26 Jun 2001 13:20:43 -0400 > > > >That is unfortunate. A generic L2 triggering mechanism COULD > >be very useful to QoS WGs, MIP, MANET, and SeaMoby. I do > >realize the IETF is better suited to work on very narrow > >problem statements and generalizations have to be done with > >the "death-by-a-thousand cuts" method. > > > >Best regards, > > > >Phil > > > >> -----Original Message----- > >> From: James Kempf [mailto:James.Kempf@Sun.COM] > >> Sent: Tuesday, June 26, 2001 1:01 PM > >> To: PNeumiller@MeshNetworks.com > >> Cc: James.Kempf@Sun.COM > >> Subject: RE: [seamoby] Question on 4.2 > >> > >> > >> Thanx for the pointer, but I think we are going to do this as a draft > >> rather than a working group, probably through MIP first because > >> it keeps coming up. > >> > >> jak > >> > >> >Delivered-To: seamoby-list@charizard.diameter.org > >> >From: Phillip Neumiller > >> >To: "'kempf'" , seamoby@cdma-2000.org, > >> pcalhoun@diameter.org > >> >Subject: RE: [seamoby] Question on 4.2 > >> >Date: Tue, 26 Jun 2001 12:45:41 -0400 > >> > > >> >Hi James, > >> > > >> >I have tried to start such an effort many times. Who is this > >> >bunch of you? Whenever I have tried in the past, people were > >> >not interested. Also, I sent a request to Scott B. a > >> >couple of months ago to get this started in the sub-IP area. > >> >I wrote up a draft for the WG charter. He never got back. > >> >So, I guess I would like to know if you created a mail list or > >> >if not I welcome you to use: > >> > > >> >http://internet.motlabs.com/mailman/listinfo/wirelessinternet > >> > > >> >Thanks, > >> > > >> >Phil > >> > > >> >> -----Original Message----- > >> >> From: kempf [mailto:James.Kempf@Sun.COM] > >> >> Sent: Saturday, June 23, 2001 12:15 PM > >> >> To: seamoby@cdma-2000.org; pcalhoun@diameter.org > >> >> Subject: Re: [seamoby] Question on 4.2 > >> >> > >> >> > >> >> Pat, > >> >> > >> >> A bunch of us are in discussion about doing a draft on abstract L2 > >> >> triggers. Currently, there is some unpublished material and the > >> >> material embedded in the FMIPv4 draft that we would like to pull > >> >> together. This should allow people to refer to a common source > >> >> on L2 triggers. We are unclear yet whether this belongs in MIP, > >> >> Seamoby, or other. It is clearly important for the MIP fast handoff > >> >> work, and also perhaps Seamoby context transfer. > >> >> > >> >> jak > >> >> > >> >> > >> > > From owner-seamoby@diameter.org Tue Jun 26 17:34: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 RAA22059 for ; Tue, 26 Jun 2001 17:34:29 -0400 (EDT) Received: (qmail 4854 invoked by alias); 26 Jun 2001 21:22:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4848 invoked by uid 200); 26 Jun 2001 21:22:09 -0000 Received: (qmail 4843 invoked from network); 26 Jun 2001 21:22:06 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 21:22:06 -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 PAA29553; Tue, 26 Jun 2001 15:33:21 -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 OAA26340; Tue, 26 Jun 2001 14:33:21 -0700 (PDT) Message-Id: <200106262133.OAA26340@heliopolis.eng.sun.com> Date: Tue, 26 Jun 2001 14:33:21 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: RE: [seamoby] Question on 4.2 To: James.Kempf@sun.com, gyj@isl.stanford.edu Cc: seamoby@diameter.org, PNeumiller@MeshNetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9/YBKnHQ5l81q8BS6p5Amw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Youngjun, >I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is devoted >for describing L2 trigger, required for Pre- and Post-Registration >methods. I think the section is well written and really trying to unveil >the role of L2 trigger. Actually, it is quite informational as well since >we haven't quite seen anything in this detail regarding L2 trigger. > >IMHO, though, what SeaMoby requires (in terms of handoff trigger) is the >superset that not only covers the scope of the triggering mechanism that >FMIPv4 draft requires, but also other context. > >As an example, L2 trigger described in FMIPv4 draft Section 1.3 specifies >the recipient, content (IP address/IP address identifier etc.), and timing >of the arrival of this special signal. CT trigger may require more >information than these. > I agree that there may need to be some additions to the defined set of L2 triggers in the FMIPv4 draft to cover Seamoby. The discussion in the draft only covers fast handoff, context transfer is likely to impose its own requirements on the L2/L3 interaction. >Going back to discussions regarding L2/L3 trigger between Rajeev and >Kulwinder, I think SeaMoby also should consider abstract description of >this trigger business. I've always thought about pursuiting a work in >triggering mechanism, but I wasn't sure I'm digging into the legitimate >scope of work for the WG. Can anybody share some thoughts regarding this >with me? > I also agree, but I think it might be worthwhile to combine the handoff and context trigger descriptions in one document, since they are likely to be intimately related. >Lastly, the trigger mechanism should be constructed in the following >steps - this is my opinion and you are welcome to disagree with me. > >1. Fast movement detection/prediction Well, actually, I do disagree here. I believe the following view more accurately reflects what is going on between L2 and L3 around handover. Basically, L3 is not concerned with movement, it is concerned with routability changes, L2 is concerned with movement. To be more specific, L3 is only concerned with movement to the extent that a movement at L2 causes a change in routability that requires (for MIP) a change in CoA. If movement causes no change in routability, then L3 should not be involved. Therefore, I believe that the abstract L2 triggers should be designed to convey to L3 information required for fast and efficient re-establishment of routablilty when movement is about to occur or has occured. My motivation for this view is that I think it more accurately reflects the partitioning of functionality between IP as an L3 protocol and the L2 protocols on which it sits. IP is designed primarily for routability between different link layers, wireless to wired is a perfect example. The L2 protocols are designed for establishing the basic link connection, and, for wireless protocols, that means re-establishing a link when radio conditions require moving to a different access point. I think maintaining this distinction (which has been fundamental to IP since its initial design) is important to get a clean abstraction of link layer triggers for handover. >2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) While I can see the benefit of being able to select an access point in a multitechnology handover situation, I believe that it will, in general, be a relatively slow process perhaps even involving the user. Since a multitechnology handover situation is likely to involve multiple interfaces, the MN can take its time setting up the new interface while real time traffic continues on the old, then switch at the last minute. Therefore, while I think this is important, I do not see it as influencing the structure of an abstract L2 trigger design. The only exception is perhaps a software defined radio that can switch a single interface to a different technology access point, but I don't know much about software defined radios (but I have the impression that they are not to the point where one could switch from, say, Bluetooth to 802.11, or GSM, anyway). >3. Signaling handoff initiator (trigger is in fact a special signal) > Yes, this is what the FMIPv4 section on L2 triggers is trying to do. Set up a timeline for handover and define where L2 triggers will help accelerate the process and what information needs to be conveyed from L2 to L3 to help reestablish routability on the new AR as quickly as possible. I imagine the same sort of thing will be needed for Seamoby. jak From owner-seamoby@diameter.org Tue Jun 26 18:14: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 SAA27943 for ; Tue, 26 Jun 2001 18:14:15 -0400 (EDT) Received: (qmail 5387 invoked by alias); 26 Jun 2001 22:01:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5381 invoked by uid 200); 26 Jun 2001 22:01:39 -0000 Received: (qmail 5376 invoked from network); 26 Jun 2001 22:01:37 -0000 Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 22:01:37 -0000 Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f5QMMAs17965; Tue, 26 Jun 2001 15:22:10 -0700 (PDT) Date: Tue, 26 Jun 2001 15:22:09 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: James Kempf cc: seamoby@diameter.org, PNeumiller@MeshNetworks.com Subject: RE: [seamoby] Question on 4.2 In-Reply-To: <200106262133.OAA26340@heliopolis.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk James, Thank you for your quick insight. Please find my comments below ... On Tue, 26 Jun 2001, James Kempf wrote: > Youngjun, > > >I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is devoted > >for describing L2 trigger, required for Pre- and Post-Registration > >methods. I think the section is well written and really trying to unveil > >the role of L2 trigger. Actually, it is quite informational as well since > >we haven't quite seen anything in this detail regarding L2 trigger. > > > >IMHO, though, what SeaMoby requires (in terms of handoff trigger) is the > >superset that not only covers the scope of the triggering mechanism that > >FMIPv4 draft requires, but also other context. > > > >As an example, L2 trigger described in FMIPv4 draft Section 1.3 specifies > >the recipient, content (IP address/IP address identifier etc.), and timing > >of the arrival of this special signal. CT trigger may require more > >information than these. > > > > > I agree that there may need to be some additions to the defined > set of L2 triggers in the FMIPv4 draft to cover Seamoby. The discussion > in the draft only covers fast handoff, context transfer is likely > to impose its own requirements on the L2/L3 interaction. > > > >Going back to discussions regarding L2/L3 trigger between Rajeev and > >Kulwinder, I think SeaMoby also should consider abstract description of > >this trigger business. I've always thought about pursuiting a work in > >triggering mechanism, but I wasn't sure I'm digging into the legitimate > >scope of work for the WG. Can anybody share some thoughts regarding this > >with me? > > > > I also agree, but I think it might be worthwhile to combine the > handoff and context trigger descriptions in one document, since > they are likely to be intimately related. > ===> Yes, this is what I'm trying to say all along. I strongly agree with coming up with a draft about triggering mechanism (abstraction perhaps) that sort of reflects both low-latency, CT point of view, and others (if there's any) in a superset. Objective of the draft is that any sound L3 handoff schemes/CT should be benefitted by the draft. > >Lastly, the trigger mechanism should be constructed in the following > >steps - this is my opinion and you are welcome to disagree with me. > > > >1. Fast movement detection/prediction > > Well, actually, I do disagree here. > > I believe the following view more accurately reflects > what is going on between L2 and L3 around handover. Basically, L3 > is not concerned with movement, it is concerned with routability > changes, L2 is concerned with movement. To be more specific, L3 is > only concerned with movement to the extent that a movement at L2 causes > a change in routability that requires (for MIP) a change in CoA. If movement > causes no change in routability, then L3 should not be involved. Therefore, > I believe that the abstract L2 triggers should be designed to convey > to L3 information required for fast and efficient re-establishment of > routablilty when movement is about to occur or has occured. > > My motivation for this view is that I think it more accurately reflects > the partitioning of functionality between IP as an L3 protocol and > the L2 protocols on which it sits. IP is designed primarily for routability > between different link layers, wireless to wired is a perfect example. The > L2 protocols are designed for establishing the basic link connection, > and, for wireless protocols, that means re-establishing a link when > radio conditions require moving to a different access point. I think > maintaining this distinction (which has been fundamental to IP since > its initial design) is important to get a clean abstraction of link > layer triggers for handover. > ===> Here, I'm not trying to say that L3 method should be replaced for L2! I don't know why you automatically assume my view is pro-L3 method. I understand your point here with your arguments on L2. :) What I am trying to make sense here by fast movement/prediction is that this is the point when preparing trigger should be started, thus should be the part of triggering mechanism. That's all. > >2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) > > While I can see the benefit of being able to select an access point > in a multitechnology handover situation, I believe that it will, in general, be > a relatively slow process perhaps even involving the user. Since a > multitechnology handover situation is likely to involve multiple interfaces, the > MN can take its time setting up the new interface while real time traffic > continues on the old, then switch at the last minute. Therefore, > while I think this is important, I do not see it as influencing the > structure of an abstract L2 trigger design. The only exception is > perhaps a software defined radio that can switch a single interface > to a different technology access point, but I don't know much about > software defined radios (but I have the impression that they are > not to the point where one could switch from, say, Bluetooth to > 802.11, or GSM, anyway). > ===> Information about the next access point is included in the trigger in FMIP sense. Obtaining such info is related to this step. I believe similar processes should be happend for SeaMoby. Also, isn't it required for CT to discover not just AR/nFA ID, but also capabilities, resources available and so forth? As you mentioned, trying to figure out what access technologies are available is also interesting if combined with user preference. > >3. Signaling handoff initiator (trigger is in fact a special signal) > > > > Yes, this is what the FMIPv4 section on L2 triggers is trying to do. > Set up a timeline for handover and define where L2 triggers will help > accelerate the process and what information needs to be conveyed > from L2 to L3 to help reestablish routability on the new AR as > quickly as possible. > > I imagine the same sort of thing will be needed for Seamoby. > > jak > > From owner-seamoby@diameter.org Tue Jun 26 18:54: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 SAA04543 for ; Tue, 26 Jun 2001 18:54:02 -0400 (EDT) Received: (qmail 5949 invoked by alias); 26 Jun 2001 22:42:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5943 invoked by uid 200); 26 Jun 2001 22:42:16 -0000 Received: (qmail 5937 invoked from network); 26 Jun 2001 22:42:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 22:42:14 -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 PAA22498; Tue, 26 Jun 2001 15:53:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5QMr1p26090; Tue, 26 Jun 2001 15:53:01 -0700 X-mProtect: Tue, 26 Jun 2001 15:53:01 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdAXbchX; Tue, 26 Jun 2001 15:52:59 PDT Message-ID: <3B39124C.D2C26EAF@iprg.nokia.com> Date: Tue, 26 Jun 2001 15:53:00 -0700 From: Rajeev Koodli 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: Kulwinder Atwal CC: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8084@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 Hello Kulwinder, Kulwinder Atwal wrote: > ... > > > > Exactly. As soon as the MN detects that it has undergone > > handover, it sends a > > message which includes BU as an encapsulation. The new AR > > sends the CT message > > towards the old AR and the BU towards the mobility agent. > > We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in > > Pittsburgh IETF). > > Post-Connection Context Transfer: > > Yes, I think it would take less time for the newAR to process a message from > the MN that contained the necessary info. The newAR will need to ask the MN > some indentity info anyway like: > > - Who are you? > - Where is your Context located? > - Where is your CoA located? > Rajeev: Basically, you need previous Router address, previous IP address and authentication data that the previous router can verify (to ensure that the request came from the MN). This is the structure of the SHIN message, also available from --ctv6--.txt draft. We hope to present a newer version for the London IETF. > > Why can't the MN send the info needed to start a route change request and a > CT request in the same packet as its identity? > Rajeev: I guess you mean it can use MIP message to request CT as well. This should be possible. > > The MN is already there at the newAR with all the needed info. > > With Post-Connection CT the newAR knows nothing about the MN, so it cannot > use an L2 Trigger, becuase it does not know who the MN is, where its Context > may be, where its CoA maybe. > Rajeev: You can again use SHIN. Regards, -Rajeev > > It may turn out that the Context, and CoA are just too far away to attempt a > CT (Maybe the MN was moving while experiencing a loss in connectivity). > > - Kulwinder. > > > > > Regards, > > > > -Rajeev > > > > > > From owner-seamoby@diameter.org Tue Jun 26 19:18: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 TAA09092 for ; Tue, 26 Jun 2001 19:18:05 -0400 (EDT) Received: (qmail 6456 invoked by alias); 26 Jun 2001 23:05:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6451 invoked by uid 200); 26 Jun 2001 23:05:53 -0000 Received: (qmail 6446 invoked from network); 26 Jun 2001 23:05:52 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jun 2001 23:05:52 -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 QAA24566; Tue, 26 Jun 2001 16:16:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5QNGd608051; Tue, 26 Jun 2001 16:16:39 -0700 X-mProtect: Tue, 26 Jun 2001 16:16:39 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdo0sU3l; Tue, 26 Jun 2001 16:16:37 PDT Message-ID: <3B3917D5.80461B22@iprg.nokia.com> Date: Tue, 26 Jun 2001 16:16:37 -0700 From: Rajeev Koodli 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: Kulwinder Atwal CC: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8082@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: > > > > Rajeev: I like this classification as well. > > > > > > > > > > *this* I like! However, I disagree with your view on > > handoffs. I would > > > > like the pre-handoff and post-handoff context transfer. Pre > > > > or post first > > > > packet doesn't make any sense *at all* to me. How can you > > > > guarantee, or know, > > > > when the first packet will be received?!? > > > > > > I can't. How early to do Pre-Connection Context Transfer > > to get seamless > > > transfer is implementation specific. > > > > > > The viewpoint is the newAR. Either the newAR is notified > > for a need to CT > > > from oldAR, or MN. > > > The difference is on what interface the newAR is notified. > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > 1. before the new AR becomes the MN's default router, or > > 2. after the new AR becomes the MN's default router > > > > Both 1) and 2) are related to handover. > > The point of above text was to indicate that defining context transfer to be independent of handover is perhaps not sensible. Getting it to work with handovers is the challenge we are peddling. If we all agree on this, may be we should try to close the issue ? Regards, -Rajeev > Yes, but handover is pretty vague. Like Gary said, is the start, exact > middle, or end of handover, or some special protocol event in the middle. > In a collision based wired, or a wireless network we can't be certain which > protocol packet will arrive first. > > Also, we all seem to agree that if pre-connection Context Transfer takes too > long due to the uncertain nature of wireless (End-user drives through a > tunnel), it is very likely that several post-connection events will pass > before the transfer is complete. > > So, we may start with the best of intentions with the intent of being early > enough to not affect the user experience, but events may overtake us such > that we find ourselves out of time. > > So, what do we do at that point in time? > > A particular technology may find it advantageous to do post-connection, if > the data is available, even after the user has experienced a distruption, > becuase the connection setup time will be longer than the post-connection > Context Transfer time. > > An other technology may find it advantageous to re-establish new context, > because the Context Transfer time (Round-Trip Times) are greater than new > connection setup. > > - Kulwinder. > > > > > Regards, > > > > -Rajeev > > > > > > > It is up to the implementor to take into account particular > > network and > > > inter-network characteristics and real-time flow > > requirements to determine > > > how early Pre-Connection Context Transfer needs to be done > > to guarrantee > > > seamless. > > > > > > - Kulwinder. > > > > > > > In all cases that I > > > > know of, some > > > > signalling, either at L2 or L3, is used to register the > > > > mobile locally (or > > > > some signal strength measurements), but there is always an > > > > indication of handoff. > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > comes from if we are > > > > > going to process it just the same? > > > > > > > > > > The only thing that is important is that the requesting > > > > entity recieve a > > > > > packet indicating the success or failure mode of the CT > > operation. > > > > > > > > ditto. > > > > > > > > PatC > > > > > > From owner-seamoby@diameter.org Tue Jun 26 19:29: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 TAA11632 for ; Tue, 26 Jun 2001 19:29:12 -0400 (EDT) Received: (qmail 6950 invoked by alias); 26 Jun 2001 23:17:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6944 invoked by uid 200); 26 Jun 2001 23:17:05 -0000 Received: (qmail 6932 invoked by uid 500); 26 Jun 2001 23:17:03 -0000 Date: Tue, 26 Jun 2001 16:17:03 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010626161703.K22915@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Kulwinder Atwal , 'Pat Calhoun' , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8082@NEPTUNE.zucotto.com> <3B3917D5.80461B22@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3917D5.80461B22@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Tue, Jun 26, 2001 at 04:16:37PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > 1. before the new AR becomes the MN's default router, or > > > 2. after the new AR becomes the MN's default router > > > > > > Both 1) and 2) are related to handover. > > > > > > The point of above text was to indicate that defining context transfer to be > independent of handover is perhaps not sensible. Getting it to work with > handovers is the challenge we are peddling. > If we all agree on this, may be we should try to close the issue ? The issue I have is that the current definitions use some random packet destined for the mobile as the timing "event". This, im my mind, makes no sense whatsoever, because one side (oAR) may not know when the packet shows up, and therefore it has no idea whether a reactive or proactive CT is to be invoked. FWIW, some CTs will transfer L2 session keys used for authentication and encryption, so this is where the first packet doesn't make sense. PatC > > Regards, > > -Rajeev > > > > Yes, but handover is pretty vague. Like Gary said, is the start, exact > > middle, or end of handover, or some special protocol event in the middle. > > In a collision based wired, or a wireless network we can't be certain which > > protocol packet will arrive first. > > > > Also, we all seem to agree that if pre-connection Context Transfer takes too > > long due to the uncertain nature of wireless (End-user drives through a > > tunnel), it is very likely that several post-connection events will pass > > before the transfer is complete. > > > > So, we may start with the best of intentions with the intent of being early > > enough to not affect the user experience, but events may overtake us such > > that we find ourselves out of time. > > > > So, what do we do at that point in time? > > > > A particular technology may find it advantageous to do post-connection, if > > the data is available, even after the user has experienced a distruption, > > becuase the connection setup time will be longer than the post-connection > > Context Transfer time. > > > > An other technology may find it advantageous to re-establish new context, > > because the Context Transfer time (Round-Trip Times) are greater than new > > connection setup. > > > > - Kulwinder. > > > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > It is up to the implementor to take into account particular > > > network and > > > > inter-network characteristics and real-time flow > > > requirements to determine > > > > how early Pre-Connection Context Transfer needs to be done > > > to guarrantee > > > > seamless. > > > > > > > > - Kulwinder. > > > > > > > > > In all cases that I > > > > > know of, some > > > > > signalling, either at L2 or L3, is used to register the > > > > > mobile locally (or > > > > > some signal strength measurements), but there is always an > > > > > indication of handoff. > > > > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > > comes from if we are > > > > > > going to process it just the same? > > > > > > > > > > > > The only thing that is important is that the requesting > > > > > entity recieve a > > > > > > packet indicating the success or failure mode of the CT > > > operation. > > > > > > > > > > ditto. > > > > > > > > > > PatC > > > > > > > > > From owner-seamoby@diameter.org Tue Jun 26 23:01: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 XAA12549 for ; Tue, 26 Jun 2001 23:01:16 -0400 (EDT) Received: (qmail 7620 invoked by alias); 27 Jun 2001 02:48:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7613 invoked by uid 200); 27 Jun 2001 02:48:21 -0000 Received: (qmail 7608 invoked from network); 27 Jun 2001 02:48:19 -0000 Received: from hume.neobright.net (root@209.143.19.251) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 02:48:19 -0000 Received: from WRQ1-NorthCoast.bright.net (wrq1-northcoast.bright.net [209.143.22.124]) by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id WAA07773 for ; Tue, 26 Jun 2001 22:59:37 -0400 Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for ; Tue, 26 Jun 2001 22:57:00 -0400 From: "Emil Sturniolo" To: "James Kempf" , Cc: , Subject: RE: [seamoby] Question on 4.2 Date: Tue, 26 Jun 2001 22:56:58 -0400 Message-ID: <009701c0feb4$d5479320$7c168fd1@wrq-nc1.wrq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <200106262133.OAA26340@heliopolis.eng.sun.com> X-MDaemon-Deliver-To: seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit James, ... snip... >1. Fast movement detection/prediction Well, actually, I do disagree here. I believe the following view more accurately reflects what is going on between L2 and L3 around handover. Basically, L3 is not concerned with movement, it is concerned with routability changes, L2 is concerned with movement. To be more specific, L3 is only concerned with movement to the extent that a movement at L2 causes a change in routability that requires (for MIP) a change in CoA. If movement causes no change in routability, then L3 should not be involved. ........ [Emil]. James, I'd like to add one scenario that might slightly change the semantics, if it's within the scope of the conversation. Most of this thread has been concern with the situation where connectivity at L2 is constant and possibly predictive. However, it has been my experience that this is not truly reflective of reality. IMHO L3 should be involved if a mobile node becomes detached and then reattached to the same network, even though no changes in routability may have occurred. L3 needs to be knowledgeable of this event to at least verify routability and possibly facilitate faster recovery at even higher levels in the protocol stack (slings and arrows welcome). Cordially, Emil Sturniolo EmilS@NetMotionWireless.Com www.NetMotionWireless.com 330-723-9099 330-461-0326 - Mobile/Voice Mail ===================== -----Original Message----- From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org] On Behalf Of James Kempf Sent: Tuesday, June 26, 2001 5:33 PM To: James.Kempf@sun.com; gyj@isl.stanford.edu Cc: seamoby@diameter.org; PNeumiller@MeshNetworks.com Subject: RE: [seamoby] Question on 4.2 Youngjun, >I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is devoted >for describing L2 trigger, required for Pre- and Post-Registration >methods. I think the section is well written and really trying to unveil >the role of L2 trigger. Actually, it is quite informational as well since >we haven't quite seen anything in this detail regarding L2 trigger. > >IMHO, though, what SeaMoby requires (in terms of handoff trigger) is the >superset that not only covers the scope of the triggering mechanism that >FMIPv4 draft requires, but also other context. > >As an example, L2 trigger described in FMIPv4 draft Section 1.3 specifies >the recipient, content (IP address/IP address identifier etc.), and timing >of the arrival of this special signal. CT trigger may require more >information than these. > I agree that there may need to be some additions to the defined set of L2 triggers in the FMIPv4 draft to cover Seamoby. The discussion in the draft only covers fast handoff, context transfer is likely to impose its own requirements on the L2/L3 interaction. >Going back to discussions regarding L2/L3 trigger between Rajeev and >Kulwinder, I think SeaMoby also should consider abstract description of >this trigger business. I've always thought about pursuiting a work in >triggering mechanism, but I wasn't sure I'm digging into the legitimate >scope of work for the WG. Can anybody share some thoughts regarding this >with me? > I also agree, but I think it might be worthwhile to combine the handoff and context trigger descriptions in one document, since they are likely to be intimately related. >Lastly, the trigger mechanism should be constructed in the following >steps - this is my opinion and you are welcome to disagree with me. > >1. Fast movement detection/prediction Well, actually, I do disagree here. I believe the following view more accurately reflects what is going on between L2 and L3 around handover. Basically, L3 is not concerned with movement, it is concerned with routability changes, L2 is concerned with movement. To be more specific, L3 is only concerned with movement to the extent that a movement at L2 causes a change in routability that requires (for MIP) a change in CoA. If movement causes no change in routability, then L3 should not be involved. [Emil]. James, I need to add one case that might change the semantics here slightly. IMHO L3 should be involved here if a mobile node becomes detached and then reattached to the network, even though no changes in routability occurred. L3 may need to be involved at this point to at least verify routability and possibly facilitate faster recovery at even higher levels in the stack. Therefore, I believe that the abstract L2 triggers should be designed to convey to L3 information required for fast and efficient re-establishment of routablilty when movement is about to occur or has occured. My motivation for this view is that I think it more accurately reflects the partitioning of functionality between IP as an L3 protocol and the L2 protocols on which it sits. IP is designed primarily for routability between different link layers, wireless to wired is a perfect example. The L2 protocols are designed for establishing the basic link connection, and, for wireless protocols, that means re-establishing a link when radio conditions require moving to a different access point. I think maintaining this distinction (which has been fundamental to IP since its initial design) is important to get a clean abstraction of link layer triggers for handover. >2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) While I can see the benefit of being able to select an access point in a multitechnology handover situation, I believe that it will, in general, be a relatively slow process perhaps even involving the user. Since a multitechnology handover situation is likely to involve multiple interfaces, the MN can take its time setting up the new interface while real time traffic continues on the old, then switch at the last minute. Therefore, while I think this is important, I do not see it as influencing the structure of an abstract L2 trigger design. The only exception is perhaps a software defined radio that can switch a single interface to a different technology access point, but I don't know much about software defined radios (but I have the impression that they are not to the point where one could switch from, say, Bluetooth to 802.11, or GSM, anyway). >3. Signaling handoff initiator (trigger is in fact a special signal) > Yes, this is what the FMIPv4 section on L2 triggers is trying to do. Set up a timeline for handover and define where L2 triggers will help accelerate the process and what information needs to be conveyed from L2 to L3 to help reestablish routability on the new AR as quickly as possible. I imagine the same sort of thing will be needed for Seamoby. jak From owner-seamoby@diameter.org Tue Jun 26 23:15:22 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18019 for ; Tue, 26 Jun 2001 23:15:20 -0400 (EDT) Received: (qmail 8119 invoked by alias); 27 Jun 2001 03:03:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8113 invoked by uid 200); 27 Jun 2001 03:03:56 -0000 Received: (qmail 8108 invoked by uid 500); 27 Jun 2001 03:03:55 -0000 Date: Tue, 26 Jun 2001 20:03:55 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] My interpretation of the consensus on issues Message-ID: <20010626200354.O22915@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, Here is my interpretation on the consensus on certain issues that are pending: 1. Issue 1 -> consensus shows that this change shouldn't be adopted 2. Issue 2 -> consensus seems to favor this issue, but I am having some trouble understand some folks comments. I think that I will need to revisit this one. 3. Issue 3 -> consensus shows that this change should be adopted. 4. Issue 4 -> This is another of those where I feel people favor changing it, but we don't seem to have an agreement on the end result. 5. Issue 5 -> consensus shows that this change should be adopted, but some folks had issues with my text. Perhaps someone could propose new text, or I could give it another shot. 6. Issue 6 -> consensus shows that people favored my option 3, and the text should be worded to reflect consensus. That leave us with 2 and 4 open, and some new text needed for 5. Gary, could you please incorporate 3 and 6 into the draft? Thanks, PatC From owner-seamoby@diameter.org Wed Jun 27 02:16: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 CAA16936 for ; Wed, 27 Jun 2001 02:16:42 -0400 (EDT) Received: (qmail 9007 invoked by alias); 27 Jun 2001 06:04:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9001 invoked by uid 200); 27 Jun 2001 06:04:23 -0000 Received: (qmail 8996 invoked from network); 27 Jun 2001 06:04:21 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 06:04:21 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 02:15:04 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8088@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Wed, 27 Jun 2001 02:15: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: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, June 26, 2001 7:17 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Kulwinder Atwal wrote: > > > > > > > Rajeev: I like this classification as well. > > > > > > > > > > > > > *this* I like! However, I disagree with your view on > > > handoffs. I would > > > > > like the pre-handoff and post-handoff context transfer. Pre > > > > > or post first > > > > > packet doesn't make any sense *at all* to me. How can you > > > > > guarantee, or know, > > > > > when the first packet will be received?!? > > > > > > > > I can't. How early to do Pre-Connection Context Transfer > > > to get seamless > > > > transfer is implementation specific. > > > > > > > > The viewpoint is the newAR. Either the newAR is notified > > > for a need to CT > > > > from oldAR, or MN. > > > > The difference is on what interface the newAR is notified. > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > 1. before the new AR becomes the MN's default router, or > > > 2. after the new AR becomes the MN's default router > > > > > > Both 1) and 2) are related to handover. > > > > > > The point of above text was to indicate that defining context > transfer to be > independent of handover is perhaps not sensible. Getting it > to work with > handovers is the challenge we are peddling. > If we all agree on this, may be we should try to close the issue ? > > Regards, > > -Rajeev How is this: Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the newAR becomes the MN's default router. Post-Handoff Context Transfer: The Context Transfer is initiated after the newAR becomes the MN's default router. -Kulwinder. > > > > Yes, but handover is pretty vague. Like Gary said, is the > start, exact > > middle, or end of handover, or some special protocol event > in the middle. > > In a collision based wired, or a wireless network we can't > be certain which > > protocol packet will arrive first. > > > > Also, we all seem to agree that if pre-connection Context > Transfer takes too > > long due to the uncertain nature of wireless (End-user > drives through a > > tunnel), it is very likely that several post-connection > events will pass > > before the transfer is complete. > > > > So, we may start with the best of intentions with the > intent of being early > > enough to not affect the user experience, but events may > overtake us such > > that we find ourselves out of time. > > > > So, what do we do at that point in time? > > > > A particular technology may find it advantageous to do > post-connection, if > > the data is available, even after the user has experienced > a distruption, > > becuase the connection setup time will be longer than the > post-connection > > Context Transfer time. > > > > An other technology may find it advantageous to > re-establish new context, > > because the Context Transfer time (Round-Trip Times) are > greater than new > > connection setup. > > > > - Kulwinder. > > > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > It is up to the implementor to take into account particular > > > network and > > > > inter-network characteristics and real-time flow > > > requirements to determine > > > > how early Pre-Connection Context Transfer needs to be done > > > to guarrantee > > > > seamless. > > > > > > > > - Kulwinder. > > > > > > > > > In all cases that I > > > > > know of, some > > > > > signalling, either at L2 or L3, is used to register the > > > > > mobile locally (or > > > > > some signal strength measurements), but there is always an > > > > > indication of handoff. > > > > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > > comes from if we are > > > > > > going to process it just the same? > > > > > > > > > > > > The only thing that is important is that the requesting > > > > > entity recieve a > > > > > > packet indicating the success or failure mode of the CT > > > operation. > > > > > > > > > > ditto. > > > > > > > > > > PatC > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 02:24: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 CAA20946 for ; Wed, 27 Jun 2001 02:23:59 -0400 (EDT) Received: (qmail 9482 invoked by alias); 27 Jun 2001 06:11:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9476 invoked by uid 200); 27 Jun 2001 06:11:44 -0000 Received: (qmail 9467 invoked from network); 27 Jun 2001 06:11:42 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 06:11:42 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 02:22:20 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8089@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Rajeev Koodli Cc: Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Wed, 27 Jun 2001 02:22:19 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 26, 2001 7:17 PM > To: Rajeev Koodli > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > 2. after the new AR becomes the MN's default router > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > The point of above text was to indicate that defining > context transfer to be > > independent of handover is perhaps not sensible. Getting it > to work with > > handovers is the challenge we are peddling. > > If we all agree on this, may be we should try to close the issue ? > > The issue I have is that the current definitions use some > random packet destined > for the mobile as the timing "event". This, im my mind, makes > no sense whatsoever, > because one side (oAR) may not know when the packet shows up, > and therefore it > has no idea whether a reactive or proactive CT is to be invoked. The oldAR recieves the signalling message from newAR that states which type of CT to invoke. This is the common IP signalling message from newAR to oldAR on the direct link between newAR and oldAR. The oldAR is provided with everything it needs to know to do CT in the signalling message. - Kulwinder. > > FWIW, some CTs will transfer L2 session keys used for > authentication and > encryption, so this is where the first packet doesn't make sense. > > PatC > > > > Regards, > > > > -Rajeev > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > start, exact > > > middle, or end of handover, or some special protocol > event in the middle. > > > In a collision based wired, or a wireless network we > can't be certain which > > > protocol packet will arrive first. > > > > > > Also, we all seem to agree that if pre-connection Context > Transfer takes too > > > long due to the uncertain nature of wireless (End-user > drives through a > > > tunnel), it is very likely that several post-connection > events will pass > > > before the transfer is complete. > > > > > > So, we may start with the best of intentions with the > intent of being early > > > enough to not affect the user experience, but events may > overtake us such > > > that we find ourselves out of time. > > > > > > So, what do we do at that point in time? > > > > > > A particular technology may find it advantageous to do > post-connection, if > > > the data is available, even after the user has > experienced a distruption, > > > becuase the connection setup time will be longer than the > post-connection > > > Context Transfer time. > > > > > > An other technology may find it advantageous to > re-establish new context, > > > because the Context Transfer time (Round-Trip Times) are > greater than new > > > connection setup. > > > > > > - Kulwinder. > > > > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > It is up to the implementor to take into account particular > > > > network and > > > > > inter-network characteristics and real-time flow > > > > requirements to determine > > > > > how early Pre-Connection Context Transfer needs to be done > > > > to guarrantee > > > > > seamless. > > > > > > > > > > - Kulwinder. > > > > > > > > > > > In all cases that I > > > > > > know of, some > > > > > > signalling, either at L2 or L3, is used to register the > > > > > > mobile locally (or > > > > > > some signal strength measurements), but there is always an > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > > > comes from if we are > > > > > > > going to process it just the same? > > > > > > > > > > > > > > The only thing that is important is that the requesting > > > > > > entity recieve a > > > > > > > packet indicating the success or failure mode of the CT > > > > operation. > > > > > > > > > > > > ditto. > > > > > > > > > > > > PatC > > > > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 02:42: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 CAA29527 for ; Wed, 27 Jun 2001 02:42:09 -0400 (EDT) Received: (qmail 9962 invoked by alias); 27 Jun 2001 06:29:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9956 invoked by uid 200); 27 Jun 2001 06:29:05 -0000 Received: (qmail 9951 invoked from network); 27 Jun 2001 06:29:03 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 06:29:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 02:39:50 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808A@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Emil Sturniolo'" , James Kempf , gyj@isl.stanford.edu Cc: seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: RE: [seamoby] Question on 4.2 Date: Wed, 27 Jun 2001 02:39: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 > -----Original Message----- > From: Emil Sturniolo [mailto:emils@netmotionwireless.com] > Sent: Tuesday, June 26, 2001 10:57 PM > To: James Kempf; gyj@isl.stanford.edu > Cc: seamoby@diameter.org; PNeumiller@meshnetworks.com > Subject: RE: [seamoby] Question on 4.2 > > > James, > > ... snip... > >1. Fast movement detection/prediction > > Well, actually, I do disagree here. > > I believe the following view more accurately reflects > what is going on between L2 and L3 around handover. Basically, L3 > is not concerned with movement, it is concerned with routability > changes, L2 is concerned with movement. To be more specific, L3 is > only concerned with movement to the extent that a movement at L2 > causes > a change in routability that requires (for MIP) a change in CoA. If > movement > causes no change in routability, then L3 should not be involved. > ........ > > [Emil]. James, I'd like to add one scenario that might slightly change > the semantics, if it's within the scope of the conversation. Most of > this thread has been concern with the situation where connectivity at > L2 is constant and possibly predictive. However, it has been my > experience that this is not truly reflective of reality. IMHO L3 > should be involved if a mobile node becomes detached and then > reattached to the same network, even though no changes in routability > may have occurred. > L3 needs to be knowledgeable of this event to at > least verify routability and possibly facilitate faster recovery at > even higher levels in the protocol stack (slings and arrows welcome). I would say that L3 mobility is concerned about routability and not concerned with movement. If a router has mulitiple L2 interfaces then a change from one L2 interface to another will not affect L3. In this case, L2 can verify routability because it is still the same AR. If it is a different AR, then there is a change in routability, and a need to inform L3 mobility. Unless, there is another case that comes to mind. - Kulwinder. > > > Cordially, > Emil Sturniolo > EmilS@NetMotionWireless.Com > www.NetMotionWireless.com > 330-723-9099 > 330-461-0326 - Mobile/Voice Mail > ===================== > > > -----Original Message----- > From: owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org] > On Behalf Of James Kempf > Sent: Tuesday, June 26, 2001 5:33 PM > To: James.Kempf@sun.com; gyj@isl.stanford.edu > Cc: seamoby@diameter.org; PNeumiller@MeshNetworks.com > Subject: RE: [seamoby] Question on 4.2 > > Youngjun, > > >I have looked thru the FMIPv4 draft (-01.txt) and Section 1.3 is > devoted > >for describing L2 trigger, required for Pre- and Post-Registration > >methods. I think the section is well written and really trying to > unveil > >the role of L2 trigger. Actually, it is quite informational as well > since > >we haven't quite seen anything in this detail regarding L2 trigger. > > > >IMHO, though, what SeaMoby requires (in terms of handoff trigger) is > the > >superset that not only covers the scope of the triggering mechanism > that > >FMIPv4 draft requires, but also other context. > > > >As an example, L2 trigger described in FMIPv4 draft Section 1.3 > specifies > >the recipient, content (IP address/IP address identifier etc.), and > timing > >of the arrival of this special signal. CT trigger may require more > >information than these. > > > > > I agree that there may need to be some additions to the defined > set of L2 triggers in the FMIPv4 draft to cover Seamoby. The > discussion > in the draft only covers fast handoff, context transfer is likely > to impose its own requirements on the L2/L3 interaction. > > > >Going back to discussions regarding L2/L3 trigger between Rajeev and > >Kulwinder, I think SeaMoby also should consider abstract description > of > >this trigger business. I've always thought about pursuiting a work in > >triggering mechanism, but I wasn't sure I'm digging into the > legitimate > >scope of work for the WG. Can anybody share some thoughts regarding > this > >with me? > > > > I also agree, but I think it might be worthwhile to combine the > handoff and context trigger descriptions in one document, since > they are likely to be intimately related. > > >Lastly, the trigger mechanism should be constructed in the following > >steps - this is my opinion and you are welcome to disagree with me. > > > >1. Fast movement detection/prediction > > Well, actually, I do disagree here. > > I believe the following view more accurately reflects > what is going on between L2 and L3 around handover. Basically, L3 > is not concerned with movement, it is concerned with routability > changes, L2 is concerned with movement. To be more specific, L3 is > only concerned with movement to the extent that a movement at L2 > causes > a change in routability that requires (for MIP) a change in CoA. If > movement > causes no change in routability, then L3 should not be involved. > > [Emil]. James, I need to add one case that might change the semantics > here slightly. IMHO L3 should be involved here if a mobile node > becomes detached and then reattached to the network, even though no > changes in routability occurred. L3 may need to be involved at this > point to at least verify routability and possibly facilitate faster > recovery at even higher levels in the stack. > > Therefore, > I believe that the abstract L2 triggers should be designed to convey > to L3 information required for fast and efficient re-establishment of > routablilty when movement is about to occur or has occured. > > My motivation for this view is that I think it more accurately > reflects > the partitioning of functionality between IP as an L3 protocol and > the L2 protocols on which it sits. IP is designed primarily for > routability > between different link layers, wireless to wired is a perfect example. > The > L2 protocols are designed for establishing the basic link connection, > and, for wireless protocols, that means re-establishing a link when > radio conditions require moving to a different access point. I think > maintaining this distinction (which has been fundamental to IP since > its initial design) is important to get a clean abstraction of link > layer triggers for handover. > > >2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) > > While I can see the benefit of being able to select an access point > in a multitechnology handover situation, I believe that it will, in > general, be > a relatively slow process perhaps even involving the user. Since a > multitechnology handover situation is likely to involve multiple > interfaces, the > MN can take its time setting up the new interface while real time > traffic > continues on the old, then switch at the last minute. Therefore, > while I think this is important, I do not see it as influencing the > structure of an abstract L2 trigger design. The only exception is > perhaps a software defined radio that can switch a single interface > to a different technology access point, but I don't know much about > software defined radios (but I have the impression that they are > not to the point where one could switch from, say, Bluetooth to > 802.11, or GSM, anyway). > > >3. Signaling handoff initiator (trigger is in fact a special signal) > > > > Yes, this is what the FMIPv4 section on L2 triggers is trying to do. > Set up a timeline for handover and define where L2 triggers will help > accelerate the process and what information needs to be conveyed > from L2 to L3 to help reestablish routability on the new AR as > quickly as possible. > > I imagine the same sort of thing will be needed for Seamoby. > > jak > > From owner-seamoby@diameter.org Wed Jun 27 02:51: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 CAA05291 for ; Wed, 27 Jun 2001 02:51:33 -0400 (EDT) Received: (qmail 10496 invoked by alias); 27 Jun 2001 06:39:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10490 invoked by uid 200); 27 Jun 2001 06:39:05 -0000 Received: (qmail 10485 invoked from network); 27 Jun 2001 06:39:03 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 06:39:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 02:49:51 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808B@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'James Kempf'" , gyj@isl.stanford.edu Cc: seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: RE: [seamoby] Question on 4.2 Date: Wed, 27 Jun 2001 02:49: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: Tuesday, June 26, 2001 5:33 PM > To: James.Kempf@sun.com; gyj@isl.stanford.edu > Cc: seamoby@diameter.org; PNeumiller@meshnetworks.com > Subject: RE: [seamoby] Question on 4.2 > > > Youngjun, > > >I have looked thru the FMIPv4 draft (-01.txt) and Section > 1.3 is devoted > >for describing L2 trigger, required for Pre- and Post-Registration > >methods. I think the section is well written and really > trying to unveil > >the role of L2 trigger. Actually, it is quite informational > as well since > >we haven't quite seen anything in this detail regarding L2 trigger. > > > >IMHO, though, what SeaMoby requires (in terms of handoff > trigger) is the > >superset that not only covers the scope of the triggering > mechanism that > >FMIPv4 draft requires, but also other context. > > > >As an example, L2 trigger described in FMIPv4 draft Section > 1.3 specifies > >the recipient, content (IP address/IP address identifier > etc.), and timing > >of the arrival of this special signal. CT trigger may require more > >information than these. > > > > > I agree that there may need to be some additions to the defined > set of L2 triggers in the FMIPv4 draft to cover Seamoby. The > discussion > in the draft only covers fast handoff, context transfer is likely > to impose its own requirements on the L2/L3 interaction. > > > >Going back to discussions regarding L2/L3 trigger between Rajeev and > >Kulwinder, I think SeaMoby also should consider abstract > description of > >this trigger business. I've always thought about pursuiting a work in > >triggering mechanism, but I wasn't sure I'm digging into the > legitimate > >scope of work for the WG. Can anybody share some thoughts > regarding this > >with me? > > > > I also agree, but I think it might be worthwhile to combine the > handoff and context trigger descriptions in one document, since > they are likely to be intimately related. > > >Lastly, the trigger mechanism should be constructed in the following > >steps - this is my opinion and you are welcome to disagree with me. > > > >1. Fast movement detection/prediction > > Well, actually, I do disagree here. > > I believe the following view more accurately reflects > what is going on between L2 and L3 around handover. Basically, L3 > is not concerned with movement, it is concerned with routability > changes, L2 is concerned with movement. To be more specific, L3 is > only concerned with movement to the extent that a movement at > L2 causes > a change in routability that requires (for MIP) a change in > CoA. If movement > causes no change in routability, then L3 should not be > involved. Therefore, > I believe that the abstract L2 triggers should be designed to convey > to L3 information required for fast and efficient re-establishment of > routablilty when movement is about to occur or has occured. > > My motivation for this view is that I think it more > accurately reflects > the partitioning of functionality between IP as an L3 protocol and > the L2 protocols on which it sits. IP is designed primarily > for routability > between different link layers, wireless to wired is a perfect > example. The > L2 protocols are designed for establishing the basic link connection, > and, for wireless protocols, that means re-establishing a link when > radio conditions require moving to a different access point. I think > maintaining this distinction (which has been fundamental to IP since > its initial design) is important to get a clean abstraction of link > layer triggers for handover. > > >2. Handoff Candidate Discovery (e.g. obtaining nFA IP Addr ID) > > While I can see the benefit of being able to select an access point > in a multitechnology handover situation, I believe that it > will, in general, be > a relatively slow process perhaps even involving the user. If the user sets up an handover policy stating user preferences the MN can use this policy in selecting an AR. > Since a > multitechnology handover situation is likely to involve > multiple interfaces, the > MN can take its time setting up the new interface while real > time traffic > continues on the old, then switch at the last minute. Therefore, > while I think this is important, I do not see it as influencing the > structure of an abstract L2 trigger design. The only exception is > perhaps a software defined radio that can switch a single interface > to a different technology access point, It can be done at the IP level. IP just sees different radio-modems as different L2 interfaces. If each radio-modem is assigned an IPv6 interface ID, it can be done with IP switching between different IP interfaces. http://www.ietf.org/rfc/rfc1884.txt?number=1884 - Kulwinder. > but I don't know much about > software defined radios (but I have the impression that they are > not to the point where one could switch from, say, Bluetooth to > 802.11, or GSM, anyway). > > >3. Signaling handoff initiator (trigger is in fact a special signal) > > > > Yes, this is what the FMIPv4 section on L2 triggers is trying to do. > Set up a timeline for handover and define where L2 triggers will help > accelerate the process and what information needs to be conveyed > from L2 to L3 to help reestablish routability on the new AR as > quickly as possible. > > I imagine the same sort of thing will be needed for Seamoby. > > jak > From owner-seamoby@diameter.org Wed Jun 27 09:03: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 JAA12096 for ; Wed, 27 Jun 2001 09:03:02 -0400 (EDT) Received: (qmail 11940 invoked by alias); 27 Jun 2001 12:51:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11934 invoked by uid 200); 27 Jun 2001 12:51:03 -0000 Received: (qmail 11929 invoked from network); 27 Jun 2001 12:51:01 -0000 Received: from hume.neobright.net (root@209.143.19.251) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 12:51:01 -0000 Received: from WRQ1-NorthCoast.bright.net (wrq1-northcoast.bright.net [209.143.22.124]) by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id JAA05021 for ; Wed, 27 Jun 2001 09:02:19 -0400 Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for ; Wed, 27 Jun 2001 08:58:43 -0400 From: "Emil Sturniolo" To: "Kulwinder Atwal" , "James Kempf" , Cc: , Subject: RE: [seamoby] Question on 4.2 Date: Wed, 27 Jun 2001 08:58:42 -0400 Message-ID: <009b01c0ff08$e4964b10$7c168fd1@wrq-nc1.wrq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808A@NEPTUNE.zucotto.com> X-MDaemon-Deliver-To: seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Kulwinder. > James, > > ... snip... > >1. Fast movement detection/prediction > > Well, actually, I do disagree here. > > I believe the following view more accurately reflects > what is going on between L2 and L3 around handover. Basically, L3 > is not concerned with movement, it is concerned with routability > changes, L2 is concerned with movement. To be more specific, L3 is > only concerned with movement to the extent that a movement at L2 > causes > a change in routability that requires (for MIP) a change in CoA. If > movement > causes no change in routability, then L3 should not be involved. > ........ > > [Emil]. James, I'd like to add one scenario that might slightly change > the semantics, if it's within the scope of the conversation. Most of > this thread has been concern with the situation where connectivity at > L2 is constant and possibly predictive. However, it has been my > experience that this is not truly reflective of reality. IMHO L3 > should be involved if a mobile node becomes detached and then > reattached to the same network, even though no changes in routability > may have occurred. > L3 needs to be knowledgeable of this event to at > least verify routability and possibly facilitate faster recovery at > even higher levels in the protocol stack (slings and arrows welcome). I would say that L3 mobility is concerned about routability and not concerned with movement. If a router has mulitiple L2 interfaces then a change from one L2 interface to another will not affect L3. In this case, L2 can verify routability because it is still the same AR. If it is a different AR, then there is a change in routability, and a need to inform L3 mobility. Unless, there is another case that comes to mind. - Kulwinder. [Emil] Kulwinder, what I was trying to point out is that even though it is still the same AR it is still useful to signal L3 that connectivity has been re-established. Off the top of my head, depending on when and the length of time that the MN was disconnected, after L2 connectivity is reaffirmed, it may need to determine if its own addressibility is still valid Furthermore, as I said in my original note, this indication may also help facilitate recovery further up the stack. Maybe this is a different trigger that I am describing here, but it does seem to be consistent with acquisition/continuation of L2 connectivity. Cordially, Emil Sturniolo EmilS@NetMotionWireless.Com www.NetMotionWireless.com 330-723-9099 330-461-0326 - Mobile/Voice Mail ===================== From owner-seamoby@diameter.org Wed Jun 27 09:14:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19555 for ; Wed, 27 Jun 2001 09:14:46 -0400 (EDT) Received: (qmail 12419 invoked by alias); 27 Jun 2001 13:03:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12413 invoked by uid 200); 27 Jun 2001 13:03:04 -0000 Received: (qmail 12408 invoked from network); 27 Jun 2001 13:03:03 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 13:03:03 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 09:13:52 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808C@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Emil Sturniolo'" , James Kempf , gyj@isl.stanford.edu Cc: seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: RE: [seamoby] Question on 4.2 Date: Wed, 27 Jun 2001 09:13: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 > -----Original Message----- > From: Emil Sturniolo [mailto:emils@netmotionwireless.com] > Sent: Wednesday, June 27, 2001 8:59 AM > To: Kulwinder Atwal; James Kempf; gyj@isl.stanford.edu > Cc: seamoby@diameter.org; PNeumiller@meshnetworks.com > Subject: RE: [seamoby] Question on 4.2 > > > > [Emil] Kulwinder, what I was trying to point out is that even though > it is still the same AR it is still useful to signal L3 that > connectivity has been re-established. Off the top of my head, > depending on when and the length of time that the MN was disconnected, > after L2 connectivity is reaffirmed, it may need to determine if its > own addressibility is still valid Furthermore, as I said in my > original note, this indication may also help facilitate recovery > further up the stack. Maybe this is a different trigger that I am > describing here, but it does seem to be consistent with > acquisition/continuation of L2 connectivity. Maybe these triggers could be called: 1. Link Lost Trigger 2. Link Connected Trigger - Kulwinder. > > Cordially, > Emil Sturniolo > EmilS@NetMotionWireless.Com > www.NetMotionWireless.com > 330-723-9099 > 330-461-0326 - Mobile/Voice Mail > ===================== > > From owner-seamoby@diameter.org Wed Jun 27 10:08:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22403 for ; Wed, 27 Jun 2001 10:08:54 -0400 (EDT) Received: (qmail 12941 invoked by alias); 27 Jun 2001 13:56:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12935 invoked by uid 200); 27 Jun 2001 13:56:37 -0000 Received: (qmail 12923 invoked by uid 500); 27 Jun 2001 13:56:34 -0000 Date: Wed, 27 Jun 2001 06:56:34 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Pat Calhoun'" , Rajeev Koodli , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Message-ID: <20010627065634.R22915@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Pat Calhoun' , Rajeev Koodli , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8089@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8089@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Wed, Jun 27, 2001 at 02:22:19AM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 02:22:19AM -0400, Kulwinder Atwal wrote: > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > The point of above text was to indicate that defining > > context transfer to be > > > independent of handover is perhaps not sensible. Getting it > > to work with > > > handovers is the challenge we are peddling. > > > If we all agree on this, may be we should try to close the issue ? > > > > The issue I have is that the current definitions use some > > random packet destined > > for the mobile as the timing "event". This, im my mind, makes > > no sense whatsoever, > > because one side (oAR) may not know when the packet shows up, > > and therefore it > > has no idea whether a reactive or proactive CT is to be invoked. > > The oldAR recieves the signalling message from newAR that states which type > of CT to invoke. > This is the common IP signalling message from newAR to oldAR on the direct > link between newAR and oldAR. > > The oldAR is provided with everything it needs to know to do CT in the > signalling message. Now sure that you meant to generalize here, but you are assuming a target trigger. How would it work in source triggers? PatC From owner-seamoby@diameter.org Wed Jun 27 10:25: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 KAA27246 for ; Wed, 27 Jun 2001 10:25:27 -0400 (EDT) Received: (qmail 13444 invoked by alias); 27 Jun 2001 14:13:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13438 invoked by uid 200); 27 Jun 2001 14:13:06 -0000 Received: (qmail 13429 invoked from network); 27 Jun 2001 14:13:03 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 14:13:03 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA09114 for ; Wed, 27 Jun 2001 07:24:21 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA18760 for ; Wed, 27 Jun 2001 07:24:21 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 09:24:21 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Kulwinder Atwal'" , "'Rajeev Koodli'" Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 09:24:16 -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 With Post-Connection CT the newAR knows nothing about the MN, so it cannot use an L2 Trigger, becuase it does not know who the MN is, where its Context may be, where its CoA maybe. Ajoy: L2 trigger can provide MN-ID and oldAR address info which can be used by newAR to initiate CT. This is similar to the link layer trigger at oldAR where trigger will have to provide IP address of newAR. -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Monday, June 25, 2001 10:23 PM To: 'Rajeev Koodli'; Kulwinder Atwal Cc: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Monday, June 25, 2001 9:00 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > Kulwinder Atwal wrote: > > > > > Additionally, a MN message on a high bandwidth link could > be forwarded by > > the currentAR to the oldAR to request CT, and at the _same_ > time a MN > > message could be forwarded by the currentAR to the ParentAR > to affect a > > route change. > > > > The route change message may travel to a different entity > along a different > > link, than the Context Transfer request message. Having > them happen in > > parrallel could significantly reduce Reactive Context Transfer. > > > > > > Exactly. As soon as the MN detects that it has undergone > handover, it sends a > message which includes BU as an encapsulation. The new AR > sends the CT message > towards the old AR and the BU towards the mobility agent. > We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in > Pittsburgh IETF). Post-Connection Context Transfer: Yes, I think it would take less time for the newAR to process a message from the MN that contained the necessary info. The newAR will need to ask the MN some indentity info anyway like: - Who are you? - Where is your Context located? - Where is your CoA located? Why can't the MN send the info needed to start a route change request and a CT request in the same packet as its identity? The MN is already there at the newAR with all the needed info. With Post-Connection CT the newAR knows nothing about the MN, so it cannot use an L2 Trigger, because it does not know who the MN is, where its Context may be, where its CoA maybe. It may turn out that the Context, and CoA are just too far away to attempt a CT (Maybe the MN was moving while experiencing a loss in connectivity). - Kulwinder. > > Regards, > > -Rajeev > > > From owner-seamoby@diameter.org Wed Jun 27 11:20: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 LAA26378 for ; Wed, 27 Jun 2001 11:20:15 -0400 (EDT) Received: (qmail 14071 invoked by alias); 27 Jun 2001 15:08:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14065 invoked by uid 200); 27 Jun 2001 15:08:19 -0000 Received: (qmail 14056 invoked from network); 27 Jun 2001 15:08:16 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 15:08:16 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 11:19:06 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808E@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Singh Ajoy-ASINGH1'" , "'Rajeev Koodli'" Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 11:18:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, June 27, 2001 10:24 AM > To: 'Kulwinder Atwal'; 'Rajeev Koodli' > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > With Post-Connection CT the newAR knows nothing about the MN, > so it cannot > use an L2 Trigger, becuase it does not know who the MN is, > where its Context > may be, where its CoA maybe. > > Ajoy: L2 trigger can provide MN-ID and oldAR address info > which can be > used by newAR to initiate CT. This is similar to the link > layer trigger at oldAR where > trigger will have to provide IP address of newAR. How does the newAR learn the IP address of the old AR? - Kulwinder > > > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Monday, June 25, 2001 10:23 PM > To: 'Rajeev Koodli'; Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Monday, June 25, 2001 9:00 PM > > To: Kulwinder Atwal > > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > > > > Kulwinder Atwal wrote: > > > > > > > > Additionally, a MN message on a high bandwidth link could > > be forwarded by > > > the currentAR to the oldAR to request CT, and at the _same_ > > time a MN > > > message could be forwarded by the currentAR to the ParentAR > > to affect a > > > route change. > > > > > > The route change message may travel to a different entity > > along a different > > > link, than the Context Transfer request message. Having > > them happen in > > > parrallel could significantly reduce Reactive Context Transfer. > > > > > > > > > > Exactly. As soon as the MN detects that it has undergone > > handover, it sends a > > message which includes BU as an encapsulation. The new AR > > sends the CT message > > towards the old AR and the BU towards the mobility agent. > > We proposed this (the message is SHIN) in our > -smoothv6-.txt draft (in > > Pittsburgh IETF). > > > Post-Connection Context Transfer: > > Yes, I think it would take less time for the newAR to process > a message from > the MN that contained the necessary info. The newAR will > need to ask the MN > some indentity info anyway like: > > - Who are you? > - Where is your Context located? > - Where is your CoA located? > > Why can't the MN send the info needed to start a route change > request and a > CT request in the same packet as its identity? > > The MN is already there at the newAR with all the needed info. > > With Post-Connection CT the newAR knows nothing about the MN, > so it cannot > use an L2 Trigger, because it does not know who the MN is, > where its Context > may be, where its CoA maybe. > > It may turn out that the Context, and CoA are just too far > away to attempt a > CT (Maybe the MN was moving while experiencing a loss in > connectivity). > > - Kulwinder. > > > > > Regards, > > > > -Rajeev > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 11:38: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 LAA07614 for ; Wed, 27 Jun 2001 11:38:18 -0400 (EDT) Received: (qmail 14587 invoked by alias); 27 Jun 2001 15:24:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14581 invoked by uid 200); 27 Jun 2001 15:24:34 -0000 Received: (qmail 14576 invoked from network); 27 Jun 2001 15:24:32 -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; 27 Jun 2001 15:24:32 -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 f5RFZ7005515 for ; Wed, 27 Jun 2001 11:35:08 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 27 Jun 2001 11:35:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 11:35:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D9C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] My interpretation of the consensus on issues Date: Wed, 27 Jun 2001 11:35:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FF1E.C0D462A0" 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_01C0FF1E.C0D462A0 Content-Type: text/plain; charset="iso-8859-1" Pat: For what it's worth... > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 26, 2001 11:04 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] My interpretation of the consensus on issues > > > > All, > > Here is my interpretation on the consensus on certain issues > that are pending: > > 1. Issue 1 -> consensus shows that this change shouldn't be adopted > 2. Issue 2 -> consensus seems to favor this issue, but I am having > some trouble understand some folks comments. I think that I will > need to revisit this one. I support Kulwinder's change. The language of 4.3 is a bit soft, but at least it removes the specific references to layer 2 triggers, and the following text does explain the requirement well. > 3. Issue 3 -> consensus shows that this change should be adopted. > 4. Issue 4 -> This is another of those where I feel people favor > changing it, but we don't seem to have an agreement on the end > result. The discussion that has been going on the list has been cantered around implementation issues. Each suggestion has been valid, perhaps, in the context of the networking technology that the author has been working on, but there are simply too many different "triggering" alternatives. About the only suggestion I have at this point is to scrap the whole concept and simply change the requirement that context transfer SHOULD be initiated as early as possible. bleh. One last note: requiring that "reactive transfer" be defined by packets arriving, or links being established at the new AR, ignores all the tricks one can perform at layer one/two to detect the arrival of an MN in a new cell (e.g. by detecting a sudden shift in signal strength), and provide some warning to the network that a handover has initiated (what's the definition of the start of a handover? well, the first requirement has to be that the demodulators at the two receivers be able to detect and decode 1's and 0's with a sufficiently low probability of error; what the network does beyond that to set up other layer one/two facilities, and generated triggers to layer 3 is way out of scope for SeaMoby). No mobile wireless designer is going to throw out this bag of tricks simply to conform to a convenient definition of the start of "reactive" ct. Certainly there are, and probably will be, layer one/two designs that do not provide such forewarning. However, ct is supposed to work with a wide range of mobile wireless data networks. > 5. Issue 5 -> consensus shows that this change should be adopted, but > some folks had issues with my text. Perhaps someone could propose > new text, or I could give it another shot. I would ask that the references to "size" and "priority" be removed. I sense some echoing of this view on the list. "priority" can be replaced by "delivered as the context is needed" or "delivered as the context becomes available" or similar phrases. "priority" is a very loaded term (e.g. my comment about operators taking exception to the idea that "accounting context is low priority" was only half in jest; accounting context is extremely important to some, it's just not likely that it needs to be transferred right away). > 6. Issue 6 -> consensus shows that people favored my option 3, and > the text should be worded to reflect consensus. > > That leave us with 2 and 4 open, and some new text needed for 5. Gary, > could you please incorporate 3 and 6 into the draft? Done. You are welcome, Gary > > Thanks, > > PatC > ------_=_NextPart_001_01C0FF1E.C0D462A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [seamoby] My interpretation of the consensus on = issues

Pat:

  For what it's worth...

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> Sent: Tuesday, June 26, 2001 11:04 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] My interpretation of the = consensus on issues
>
>
>
> All,
>
> Here is my interpretation on the consensus on = certain issues
> that are pending:
>
> 1. Issue 1 -> consensus shows that this = change shouldn't be adopted
> 2. Issue 2 -> consensus seems to favor this = issue, but I am having
>    some trouble understand some = folks comments. I think that I will
>    need to revisit this = one.

I support Kulwinder's change. The language of 4.3 is = a bit soft, but at
least it removes the specific references to layer 2 = triggers, and the following
text does explain the requirement well.

> 3. Issue 3 -> consensus shows that this = change should be adopted.
> 4. Issue 4 -> This is another of those where = I feel people favor
>    changing it, but we don't = seem to have an agreement on the end
>    result.

The discussion that has been going on the list has = been cantered around
implementation issues. Each suggestion has been = valid, perhaps, in the context of the networking technology that the = author has been working on, but there are simply too many different = "triggering" alternatives. About the only suggestion I have = at this point is to scrap the whole concept and simply change the = requirement that context transfer SHOULD be initiated as early as = possible. bleh.

One last note: requiring that "reactive = transfer" be defined by packets arriving, or links being = established at the new AR, ignores all the tricks one can perform at = layer one/two to detect the arrival of an MN in a new cell (e.g. by = detecting a sudden shift in signal strength), and provide some warning = to the network that a handover has initiated (what's the definition of = the start of a handover? well, the first requirement has to be that the = demodulators at the two receivers be able to detect and decode 1's and = 0's with a sufficiently low probability of error; what the network does = beyond that to set up other layer one/two facilities, and generated = triggers to layer 3 is way out of scope for SeaMoby). No mobile = wireless designer is going to throw out this bag of tricks simply to = conform to a convenient definition of the start of "reactive" = ct.

Certainly there are, and probably will be, layer = one/two designs that do not provide such forewarning. However, ct is = supposed to work with a wide range of mobile wireless data = networks.

> 5. Issue 5 -> consensus shows that this = change should be adopted, but
>    some folks had issues with my = text. Perhaps someone could propose
>    new text, or I could give it = another shot.

I would ask that the references to "size" = and "priority" be removed. I sense some echoing of this view = on the list. "priority" can be replaced by "delivered as = the context is needed" or "delivered as the context becomes = available" or similar phrases. "priority" is a very = loaded term (e.g. my comment about operators taking exception to the = idea that "accounting context is low priority" was

only half in jest; accounting context is extremely = important to some, it's just not likely that it needs to be transferred = right away).

> 6. Issue 6 -> consensus shows that people = favored my option 3, and
>    the text should be worded to = reflect consensus.
>
> That leave us with 2 and 4 open, and some new = text needed for 5. Gary,
> could you please incorporate 3 and 6 into the = draft?

Done.

You are welcome,
Gary

>
> Thanks,
>
> PatC
>

------_=_NextPart_001_01C0FF1E.C0D462A0-- From owner-seamoby@diameter.org Wed Jun 27 12:10: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 MAA29734 for ; Wed, 27 Jun 2001 12:10:19 -0400 (EDT) Received: (qmail 15130 invoked by alias); 27 Jun 2001 15:58:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15124 invoked by uid 200); 27 Jun 2001 15:58:28 -0000 Received: (qmail 15115 invoked from network); 27 Jun 2001 15:58:26 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 15:58:26 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:09:15 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808F@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Kulwinder Atwal Cc: Rajeev Koodli , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Wed, 27 Jun 2001 12:09:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 27, 2001 9:57 AM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; Rajeev Koodli; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > an d re active CT definitions > > > On Wed, Jun 27, 2001 at 02:22:19AM -0400, Kulwinder Atwal wrote: > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > context transfer to be > > > > independent of handover is perhaps not sensible. Getting it > > > to work with > > > > handovers is the challenge we are peddling. > > > > If we all agree on this, may be we should try to close > the issue ? > > > > > > The issue I have is that the current definitions use some > > > random packet destined > > > for the mobile as the timing "event". This, im my mind, makes > > > no sense whatsoever, > > > because one side (oAR) may not know when the packet shows up, > > > and therefore it > > > has no idea whether a reactive or proactive CT is to be invoked. > > > > The oldAR recieves the signalling message from newAR that > states which type > > of CT to invoke. > > This is the common IP signalling message from newAR to > oldAR on the direct > > link between newAR and oldAR. > > > > The oldAR is provided with everything it needs to know to > do CT in the > > signalling message. > > Now sure that you meant to generalize here, but you are > assuming a target trigger. > How would it work in source triggers? Here is the general idea. The message could be combined with the CT in the forward direction (oldAR to newAR). I am not implying the use of, or absence of, any transport here. Just the general idea. Post-Connection: 1. From newAR to oldAR IP Header CT Header MN IP address newAR IP address From oldAR to newAR IP Header CT Header MN IP address newAR IP address + Context Pre-Connection: 2. From oldAR to newAR IP Header CT Header MN IP address newAR IP address + Context 3. From other Entity to oldAR IP Header CT Header MN IP address newAR IP address Followed by from oldAR to newAR IP Header CT Header MN IP address newAR IP address + Context - Kulwinder. > > PatC > From owner-seamoby@diameter.org Wed Jun 27 12:15: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 MAA03093 for ; Wed, 27 Jun 2001 12:15:07 -0400 (EDT) Received: (qmail 15635 invoked by alias); 27 Jun 2001 16:02:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15629 invoked by uid 200); 27 Jun 2001 16:02:22 -0000 Received: (qmail 15621 invoked from network); 27 Jun 2001 16:02:21 -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; 27 Jun 2001 16:02:21 -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 f5RGCu010399 for ; Wed, 27 Jun 2001 12:12:56 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 27 Jun 2001 12:12:49 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:12:52 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D9D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] My interpretation of the consensus on issues Date: Wed, 27 Jun 2001 12:12:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FF24.03E504A0" 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_01C0FF24.03E504A0 Content-Type: text/plain; charset="iso-8859-1" Pat: One additional question: the use of the Nagle algorithm to fulfill the requirement for aggregation would seem to be at odds with the proposal for multiphasic ct (issue 5). In other words, if ctp is performing the aggregation, it would have control over the when the "chunks" are sent. If it is the transport protocol that is supporting aggregation, then there must be some sort of "flush" command available. Since the IETF does not standardize on APIs, relying on the Nagle command would seem to make compliance to issue 5 potentially difficult, and might even violate some of the timing requirements (e.g. 5.4.5). Again, this is a question. Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, June 26, 2001 11:04 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] My interpretation of the consensus on issues > > > > All, > > Here is my interpretation on the consensus on certain issues > that are pending: > > 1. Issue 1 -> consensus shows that this change shouldn't be adopted > 2. Issue 2 -> consensus seems to favor this issue, but I am having > some trouble understand some folks comments. I think that I will > need to revisit this one. > 3. Issue 3 -> consensus shows that this change should be adopted. > 4. Issue 4 -> This is another of those where I feel people favor > changing it, but we don't seem to have an agreement on the end > result. > 5. Issue 5 -> consensus shows that this change should be adopted, but > some folks had issues with my text. Perhaps someone could propose > new text, or I could give it another shot. > 6. Issue 6 -> consensus shows that people favored my option 3, and > the text should be worded to reflect consensus. > > That leave us with 2 and 4 open, and some new text needed for 5. Gary, > could you please incorporate 3 and 6 into the draft? > > Thanks, > > PatC > ------_=_NextPart_001_01C0FF24.03E504A0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] My interpretation of the consensus on issues

Pat:

  One additional question: the use of the Nagle algorithm to
fulfill the requirement for aggregation would seem to be at odds
with the proposal for multiphasic ct (issue 5).

  In other words, if ctp is performing the aggregation, it would
have control over the when the "chunks" are sent. If it is the
transport protocol that is supporting aggregation, then there must
be some sort of "flush" command available. Since the IETF does not
standardize on APIs, relying on the Nagle command would seem to make
compliance to issue 5 potentially difficult, and might even violate
some of the timing requirements (e.g. 5.4.5).

  Again, this is a question.
Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, June 26, 2001 11:04 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] My interpretation of the consensus on issues
>
>
>
> All,
>
> Here is my interpretation on the consensus on certain issues
> that are pending:
>
> 1. Issue 1 -> consensus shows that this change shouldn't be adopted
> 2. Issue 2 -> consensus seems to favor this issue, but I am having
>    some trouble understand some folks comments. I think that I will
>    need to revisit this one.
> 3. Issue 3 -> consensus shows that this change should be adopted.
> 4. Issue 4 -> This is another of those where I feel people favor
>    changing it, but we don't seem to have an agreement on the end
>    result.
> 5. Issue 5 -> consensus shows that this change should be adopted, but
>    some folks had issues with my text. Perhaps someone could propose
>    new text, or I could give it another shot.
> 6. Issue 6 -> consensus shows that people favored my option 3, and
>    the text should be worded to reflect consensus.
>
> That leave us with 2 and 4 open, and some new text needed for 5. Gary,
> could you please incorporate 3 and 6 into the draft?
>
> Thanks,
>
> PatC
>

------_=_NextPart_001_01C0FF24.03E504A0-- From owner-seamoby@diameter.org Wed Jun 27 12:18: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 MAA05134 for ; Wed, 27 Jun 2001 12:18:06 -0400 (EDT) Received: (qmail 16055 invoked by alias); 27 Jun 2001 16:05:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16045 invoked by uid 200); 27 Jun 2001 16:05:48 -0000 Received: (qmail 16037 invoked from network); 27 Jun 2001 16:05:45 -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; 27 Jun 2001 16:05:45 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5RGGI010842 for ; Wed, 27 Jun 2001 12:16:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Wed, 27 Jun 2001 12:16:22 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:16:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5D9E@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: [seamoby] issue 6: proposed changes to text Date: Wed, 27 Jun 2001 12:16:21 -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 5.4.6 The context transfer solution MUST provide for the aggregation of multiple contexts. 5.4.7 If aggregation is not support by the transport protocol (via the Nagle algorithm []) then the context transfer protocol MUST provide for context aggregation. Comments? Gary From owner-seamoby@diameter.org Wed Jun 27 12:28: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 MAA10528 for ; Wed, 27 Jun 2001 12:28:10 -0400 (EDT) Received: (qmail 16636 invoked by alias); 27 Jun 2001 16:15:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16630 invoked by uid 200); 27 Jun 2001 16:15:59 -0000 Received: (qmail 16625 invoked from network); 27 Jun 2001 16:15:57 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 16:15:57 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA04611 for ; Wed, 27 Jun 2001 09:26:38 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA06429 for ; Wed, 27 Jun 2001 09:19:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 11:26:36 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Kulwinder Atwal'" , Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 11:26:36 -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 How does the newAR learn the IP address of the old AR? Ajoy: This can be sent in some layer 2 handoff request message from oldAR to newAR. There are other ways too. Please note that in cellular old BSC and new BSC exchange some information before MN is tuned to different frequency at the new BSC. -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Wednesday, June 27, 2001 10:19 AM To: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli' Cc: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, June 27, 2001 10:24 AM > To: 'Kulwinder Atwal'; 'Rajeev Koodli' > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > With Post-Connection CT the newAR knows nothing about the MN, > so it cannot > use an L2 Trigger, becuase it does not know who the MN is, > where its Context > may be, where its CoA maybe. > > Ajoy: L2 trigger can provide MN-ID and oldAR address info > which can be > used by newAR to initiate CT. This is similar to the link > layer trigger at oldAR where > trigger will have to provide IP address of newAR. How does the newAR learn the IP address of the old AR? - Kulwinder > > > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Monday, June 25, 2001 10:23 PM > To: 'Rajeev Koodli'; Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Monday, June 25, 2001 9:00 PM > > To: Kulwinder Atwal > > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > > > > Kulwinder Atwal wrote: > > > > > > > > Additionally, a MN message on a high bandwidth link could > > be forwarded by > > > the currentAR to the oldAR to request CT, and at the _same_ > > time a MN > > > message could be forwarded by the currentAR to the ParentAR > > to affect a > > > route change. > > > > > > The route change message may travel to a different entity > > along a different > > > link, than the Context Transfer request message. Having > > them happen in > > > parrallel could significantly reduce Reactive Context Transfer. > > > > > > > > > > Exactly. As soon as the MN detects that it has undergone > > handover, it sends a > > message which includes BU as an encapsulation. The new AR > > sends the CT message > > towards the old AR and the BU towards the mobility agent. > > We proposed this (the message is SHIN) in our > -smoothv6-.txt draft (in > > Pittsburgh IETF). > > > Post-Connection Context Transfer: > > Yes, I think it would take less time for the newAR to process > a message from > the MN that contained the necessary info. The newAR will > need to ask the MN > some indentity info anyway like: > > - Who are you? > - Where is your Context located? > - Where is your CoA located? > > Why can't the MN send the info needed to start a route change > request and a > CT request in the same packet as its identity? > > The MN is already there at the newAR with all the needed info. > > With Post-Connection CT the newAR knows nothing about the MN, > so it cannot > use an L2 Trigger, because it does not know who the MN is, > where its Context > may be, where its CoA maybe. > > It may turn out that the Context, and CoA are just too far > away to attempt a > CT (Maybe the MN was moving while experiencing a loss in > connectivity). > > - Kulwinder. > > > > > Regards, > > > > -Rajeev > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 12:50:10 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21022 for ; Wed, 27 Jun 2001 12:50:10 -0400 (EDT) Received: (qmail 17223 invoked by alias); 27 Jun 2001 16:38:25 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17217 invoked by uid 200); 27 Jun 2001 16:38:24 -0000 Received: (qmail 17205 invoked by uid 500); 27 Jun 2001 16:38:21 -0000 Date: Wed, 27 Jun 2001 09:38:21 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Pat Calhoun'" , Rajeev Koodli , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Message-ID: <20010627093821.U22915@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Pat Calhoun' , Rajeev Koodli , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808F@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F808F@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Wed, Jun 27, 2001 at 12:09:06PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 12:09:06PM -0400, Kulwinder Atwal wrote: > > Now sure that you meant to generalize here, but you are > > assuming a target trigger. > > How would it work in source triggers? > > Here is the general idea. The message could be combined with the CT in the > forward direction > (oldAR to newAR). I am not implying the use of, or absence of, any > transport here. Just the general idea. > Right, but all of your examples assume that the handoff is initiated by the target (newAR). There are many cases where the source (oldAR) can initiate the handoff. If we bind the protocol to your recommendation below, a source trigger would require an additional trip between oldAR to newAR to get CT initiated. Hence my problem, PatC > Post-Connection: > > 1. From newAR to oldAR > > IP Header > CT Header > MN IP address > newAR IP address > > From oldAR to newAR > > IP Header > CT Header > MN IP address > newAR IP address > + Context > > Pre-Connection: > > 2. From oldAR to newAR > > IP Header > CT Header > MN IP address > newAR IP address > + Context > > > 3. From other Entity to oldAR > > IP Header > CT Header > MN IP address > newAR IP address > > Followed by from oldAR to newAR > > IP Header > CT Header > MN IP address > newAR IP address > + Context > > - Kulwinder. > > > > > > PatC > > From owner-seamoby@diameter.org Wed Jun 27 12:57: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 MAA24141 for ; Wed, 27 Jun 2001 12:57:55 -0400 (EDT) Received: (qmail 17520 invoked by alias); 27 Jun 2001 16:39:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17513 invoked by uid 200); 27 Jun 2001 16:39:47 -0000 Received: (qmail 17506 invoked by uid 500); 27 Jun 2001 16:39:44 -0000 Date: Wed, 27 Jun 2001 09:39:44 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'seamoby'" Subject: Re: [seamoby] issue 6: proposed changes to text Message-ID: <20010627093944.V22915@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'seamoby' References: <9FBD322B7824D511B36900508BF93C9C9F5D9E@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: <9FBD322B7824D511B36900508BF93C9C9F5D9E@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jun 27, 2001 at 12:16:21PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 12:16:21PM -0400, Gary Kenward wrote: > > 5.4.6 The context transfer solution MUST provide for the aggregation of > multiple contexts. > > 5.4.7 If aggregation is not support by the transport protocol > (via the Nagle algorithm []) then the context transfer protocol > MUST provide for context aggregation. > great start, but I don't see the need for 5.4.6. I think that 5.4.7 is sufficient. PatC From owner-seamoby@diameter.org Wed Jun 27 13:00: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 NAA24292 for ; Wed, 27 Jun 2001 13:00:58 -0400 (EDT) Received: (qmail 17656 invoked by alias); 27 Jun 2001 16:41:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17650 invoked by uid 200); 27 Jun 2001 16:41:10 -0000 Received: (qmail 17641 invoked from network); 27 Jun 2001 16:41:08 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 16:41:08 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:51:56 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445554@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'seamoby@diameter.org'" Subject: [seamoby] CT transfer duration vs MN dwell time Date: Wed, 27 Jun 2001 12:51:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, The dwell time of a MN on a given AR may be getting shorter and shorter with newer technologies. In fact it could only be a few packets with emerging technologies before the MN has commenced communication with a new set of ARs. Think of high speed vehicles moving across micro-cells. For this reason it seems reasonable to introuce a method for AR clustering in the CT sense perhaps independent of security. For example a given CT cluster may have a pre-ordained implied trust relationship that is independent of the actual AD boundaries. This also may allow for a better way to handle the multi-phasic transfers, i.e. the "hot" context is still sent inside an MTU but the "cold" stuff can just be slushed between CT clusters. Thoughts? Thanks, Phil -- Mesh Networks, Inc. (www.meshnetworks.com) Phillip D. Neumiller pneumiller@meshnetworks.com PH: 1-407-659-5387 From owner-seamoby@diameter.org Wed Jun 27 13:05: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 NAA24515 for ; Wed, 27 Jun 2001 13:05:28 -0400 (EDT) Received: (qmail 17748 invoked by alias); 27 Jun 2001 16:41:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17742 invoked by uid 200); 27 Jun 2001 16:41:57 -0000 Received: (qmail 17727 invoked by uid 500); 27 Jun 2001 16:41:54 -0000 Date: Wed, 27 Jun 2001 09:41:54 -0700 From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: "'Kulwinder Atwal'" , "'Rajeev Koodli'" , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010627094154.W22915@charizard.diameter.org> Mail-Followup-To: Singh Ajoy-ASINGH1 , 'Kulwinder Atwal' , 'Rajeev Koodli' , 'Pat Calhoun' , seamoby@cdma-2000.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 ASINGH1@motorola.com on Wed, Jun 27, 2001 at 11:26:36AM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 11:26:36AM -0500, Singh Ajoy-ASINGH1 wrote: > > How does the newAR learn the IP address of the old AR? > > Ajoy: This can be sent in some layer 2 handoff request message > from oldAR to newAR. There are other ways too. Please > note that in cellular old BSC and new BSC exchange some > information before MN is tuned to different frequency at the > new BSC. there could be a static BSC ID -> IP Address table. Alternatively, some protocol could be used to fetch this information (e.g. ldap). Or even cooler, some SRV record, such as: ._ct@domain (of course, this assumes we know the domain, which is another problem altogether :( PatC From owner-seamoby@diameter.org Wed Jun 27 13:12: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 NAA24802 for ; Wed, 27 Jun 2001 13:12:04 -0400 (EDT) Received: (qmail 19227 invoked by alias); 27 Jun 2001 16:56:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19221 invoked by uid 200); 27 Jun 2001 16:56:34 -0000 Received: (qmail 19211 invoked by uid 500); 27 Jun 2001 16:56:29 -0000 Date: Wed, 27 Jun 2001 09:56:29 -0700 From: Pat Calhoun To: Gary Kenward Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] My interpretation of the consensus on issues Message-ID: <20010627095629.X22915@charizard.diameter.org> Mail-Followup-To: Gary Kenward , 'Pat Calhoun' , seamoby@cdma-2000.org References: <9FBD322B7824D511B36900508BF93C9C9F5D9D@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: <9FBD322B7824D511B36900508BF93C9C9F5D9D@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jun 27, 2001 at 12:12:51PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 12:12:51PM -0400, Gary Kenward wrote: > One additional question: the use of the Nagle algorithm to > fulfill the requirement for aggregation would seem to be at odds > with the proposal for multiphasic ct (issue 5). > > In other words, if ctp is performing the aggregation, it would > have control over the when the "chunks" are sent. If it is the > transport protocol that is supporting aggregation, then there must > be some sort of "flush" command available. Since the IETF does not > standardize on APIs, relying on the Nagle command would seem to make > compliance to issue 5 potentially difficult, and might even violate > some of the timing requirements (e.g. 5.4.5). you may be right, and we will need to consider that when filling out the yet unseen transport questionaire. However, the nagle algorithm doesn't hold on to packets for seconds at a time, but you are correct that the added latency may be undesired. PatC > > Again, this is a question. > Gary > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, June 26, 2001 11:04 PM > > To: seamoby@cdma-2000.org > > Subject: [seamoby] My interpretation of the consensus on issues > > > > > > > > All, > > > > Here is my interpretation on the consensus on certain issues > > that are pending: > > > > 1. Issue 1 -> consensus shows that this change shouldn't be adopted > > 2. Issue 2 -> consensus seems to favor this issue, but I am having > > some trouble understand some folks comments. I think that I will > > need to revisit this one. > > 3. Issue 3 -> consensus shows that this change should be adopted. > > 4. Issue 4 -> This is another of those where I feel people favor > > changing it, but we don't seem to have an agreement on the end > > result. > > 5. Issue 5 -> consensus shows that this change should be adopted, but > > some folks had issues with my text. Perhaps someone could propose > > new text, or I could give it another shot. > > 6. Issue 6 -> consensus shows that people favored my option 3, and > > the text should be worded to reflect consensus. > > > > That leave us with 2 and 4 open, and some new text needed for 5. Gary, > > could you please incorporate 3 and 6 into the draft? > > > > Thanks, > > > > PatC > > From owner-seamoby@diameter.org Wed Jun 27 13:23: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 NAA26155 for ; Wed, 27 Jun 2001 13:23:06 -0400 (EDT) Received: (qmail 19896 invoked by alias); 27 Jun 2001 17:10:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19890 invoked by uid 200); 27 Jun 2001 17:10:57 -0000 Received: (qmail 19882 invoked from network); 27 Jun 2001 17:10:53 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 17:10:53 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA05182 for ; Wed, 27 Jun 2001 10:22:12 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA20100 for ; Wed, 27 Jun 2001 10:22:11 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:22:11 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , Singh Ajoy-ASINGH1 Cc: "'Kulwinder Atwal'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 12:22:08 -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 Hello Pat: You are right. There are several ways to accomplish this. I guess we just have to say that both in pre and post connection cases, L2 trigger may be available at the new AR. We do not have to provide the exact trigger mechanism. won't this work ? regards, ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, June 27, 2001 11:42 AM To: Singh Ajoy-ASINGH1 Cc: 'Kulwinder Atwal'; 'Rajeev Koodli'; 'Pat Calhoun'; seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform On Wed, Jun 27, 2001 at 11:26:36AM -0500, Singh Ajoy-ASINGH1 wrote: > > How does the newAR learn the IP address of the old AR? > > Ajoy: This can be sent in some layer 2 handoff request message > from oldAR to newAR. There are other ways too. Please > note that in cellular old BSC and new BSC exchange some > information before MN is tuned to different frequency at the > new BSC. there could be a static BSC ID -> IP Address table. Alternatively, some protocol could be used to fetch this information (e.g. ldap). Or even cooler, some SRV record, such as: ._ct@domain (of course, this assumes we know the domain, which is another problem altogether :( PatC From owner-seamoby@diameter.org Wed Jun 27 13:28:09 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29606 for ; Wed, 27 Jun 2001 13:28:08 -0400 (EDT) Received: (qmail 20129 invoked by alias); 27 Jun 2001 17:12:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20122 invoked by uid 200); 27 Jun 2001 17:12:20 -0000 Received: (qmail 20109 invoked by uid 500); 27 Jun 2001 17:12:17 -0000 Date: Wed, 27 Jun 2001 10:12:16 -0700 From: Pat Calhoun To: Singh Ajoy-ASINGH1 Cc: "'Pat Calhoun'" , "'Kulwinder Atwal'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010627101216.Z22915@charizard.diameter.org> Mail-Followup-To: Singh Ajoy-ASINGH1 , 'Pat Calhoun' , 'Kulwinder Atwal' , 'Rajeev Koodli' , seamoby@cdma-2000.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 ASINGH1@motorola.com on Wed, Jun 27, 2001 at 12:22:08PM -0500 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 12:22:08PM -0500, Singh Ajoy-ASINGH1 wrote: > Hello Pat: > You are right. There are several ways to accomplish this. > I guess we just have to say that both in pre and post > connection cases, L2 trigger may be available at the new AR. > We do not have to provide the exact trigger mechanism. > won't this work ? That is my preference. My issue was binding direction to a particular scheme is the wrong approach. PatC From owner-seamoby@diameter.org Wed Jun 27 13:30: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 NAA01108 for ; Wed, 27 Jun 2001 13:30:15 -0400 (EDT) Received: (qmail 20595 invoked by alias); 27 Jun 2001 17:16:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20588 invoked by uid 200); 27 Jun 2001 17:16:52 -0000 Received: (qmail 20571 invoked from network); 27 Jun 2001 17:16:43 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 17:16:43 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA10901 for ; Wed, 27 Jun 2001 10:28:01 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA06866 for ; Wed, 27 Jun 2001 10:28:01 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 12:28:00 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Pat Calhoun'" , Singh Ajoy-ASINGH1 Cc: "'Kulwinder Atwal'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 12:28:00 -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 Great. We are in agreement. regards, ajoy -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, June 27, 2001 12:12 PM To: Singh Ajoy-ASINGH1 Cc: 'Pat Calhoun'; 'Kulwinder Atwal'; 'Rajeev Koodli'; seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform On Wed, Jun 27, 2001 at 12:22:08PM -0500, Singh Ajoy-ASINGH1 wrote: > Hello Pat: > You are right. There are several ways to accomplish this. > I guess we just have to say that both in pre and post > connection cases, L2 trigger may be available at the new AR. > We do not have to provide the exact trigger mechanism. > won't this work ? That is my preference. My issue was binding direction to a particular scheme is the wrong approach. PatC From owner-seamoby@diameter.org Wed Jun 27 13:47: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 NAA12102 for ; Wed, 27 Jun 2001 13:47:30 -0400 (EDT) Received: (qmail 21477 invoked by alias); 27 Jun 2001 17:34:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21471 invoked by uid 200); 27 Jun 2001 17:34:54 -0000 Received: (qmail 21461 invoked from network); 27 Jun 2001 17:34:50 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 17:34:50 -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 LAA28442; Wed, 27 Jun 2001 11:46:07 -0600 (MDT) Received: from awe171-106 (awe195-95.AWE.Sun.COM [192.29.195.95]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA13007; Wed, 27 Jun 2001 08:46:07 -0700 (PDT) Message-Id: <200106271546.IAA13007@heliopolis.eng.sun.com> Date: Wed, 27 Jun 2001 07:37:42 -0700 (PDT) From: kempf Reply-To: kempf Subject: RE: [seamoby] Issue 2: Make IP messages uniform To: ASINGH1@motorola.com, rajeev@iprg.nokia.com, kulwinder.atwal@zucotto.com Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lAqbxB5Ol4pi6M9sv6bmrg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-seamoby@diameter.org Precedence: bulk >> Ajoy: L2 trigger can provide MN-ID and oldAR address info >> which can be >> used by newAR to initiate CT. This is similar to the link >> layer trigger at oldAR where >> trigger will have to provide IP address of newAR. > >How does the newAR learn the IP address of the old AR? > The L2 trigger contains either the L2 address of the old AR that can be mapped to the IP address or its IP address directly, what's called an IP address identifier in draft-ietf-mobileip-lowlatencyhandoffs-ipv4-01.txt. jak From owner-seamoby@diameter.org Wed Jun 27 15:12:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03507 for ; Wed, 27 Jun 2001 15:12:36 -0400 (EDT) Received: (qmail 22602 invoked by alias); 27 Jun 2001 18:49:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22596 invoked by uid 200); 27 Jun 2001 18:49:55 -0000 Received: (qmail 22585 invoked by uid 500); 27 Jun 2001 18:49:52 -0000 Date: Wed, 27 Jun 2001 11:49:52 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Singh Ajoy-ASINGH1'" , "'Rajeev Koodli'" , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010627114952.F22915@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Singh Ajoy-ASINGH1' , 'Rajeev Koodli' , 'Pat Calhoun' , seamoby@cdma-2000.org References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8091@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8091@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Wed, Jun 27, 2001 at 02:58:01PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote: > > How does the newAR learn the IP address of the old AR? > > > > Ajoy: This can be sent in some layer 2 handoff request message > > from oldAR to newAR. There are other ways too. Please > > note that in cellular old BSC and new BSC exchange some > > information before MN is tuned to different frequency at the > > new BSC. > > > > Yes, but in Bluetooth there is no L2 protocol message for passing the oldAR > IP address. I need an IP message. It seems you have a chicken and egg problem. If you cannot figure out the IP address of the peer, how is a L3 message, being sent to an IP address that you don't know, going to help? PatC From owner-seamoby@diameter.org Wed Jun 27 15:20:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09770 for ; Wed, 27 Jun 2001 15:20:53 -0400 (EDT) Received: (qmail 22871 invoked by alias); 27 Jun 2001 18:54:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22865 invoked by uid 200); 27 Jun 2001 18:54:54 -0000 Received: (qmail 22846 invoked from network); 27 Jun 2001 18:54:43 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 18:54:43 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 15:05:16 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8092@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Kulwinder Atwal Cc: Rajeev Koodli , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Wed, 27 Jun 2001 15:05:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 27, 2001 12:38 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; Rajeev Koodli; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > an d re active CT definitions > > > On Wed, Jun 27, 2001 at 12:09:06PM -0400, Kulwinder Atwal wrote: > > > Now sure that you meant to generalize here, but you are > > > assuming a target trigger. > > > How would it work in source triggers? > > > > Here is the general idea. The message could be combined > with the CT in the > > forward direction > > (oldAR to newAR). I am not implying the use of, or absence of, any > > transport here. Just the general idea. > > > > Right, but all of your examples assume that the handoff is > initiated by > the target (newAR). There are many cases where the source (oldAR) can > initiate the handoff. > > If we bind the protocol to your recommendation below, a source trigger > would require an additional trip between oldAR to newAR to > get CT initiated. > > Hence my problem, > > PatC The below example is triggered by oldAR. All or some of the context is sent with the CT message in this case. In the forward direction, oldAR to newAR, the CT req msg can be combined with Context. The CT req msg in this case can be thought of as a subset of the Context Transfer packet. - Kulwinder. > > Post-Connection: > > > > Pre-Connection: > > > > 2. From oldAR to newAR > > > > IP Header > > CT Header > > MN IP address > > newAR IP address > > + Context > > > > From owner-seamoby@diameter.org Wed Jun 27 15:23: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 PAA11935 for ; Wed, 27 Jun 2001 15:23:48 -0400 (EDT) Received: (qmail 23386 invoked by alias); 27 Jun 2001 19:03:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23379 invoked by uid 200); 27 Jun 2001 19:03:52 -0000 Received: (qmail 23367 invoked by uid 500); 27 Jun 2001 19:03:47 -0000 Date: Wed, 27 Jun 2001 12:03:47 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Pat Calhoun'" , Rajeev Koodli , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Message-ID: <20010627120347.I22915@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Pat Calhoun' , Rajeev Koodli , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8092@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8092@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Wed, Jun 27, 2001 at 03:05:06PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 03:05:06PM -0400, Kulwinder Atwal wrote: > > If we bind the protocol to your recommendation below, a source trigger > > would require an additional trip between oldAR to newAR to > > get CT initiated. > > The below example is triggered by oldAR. All or some of the context is sent > with the CT message in this case. In the forward direction, oldAR to newAR, > the CT req msg can be combined with Context. The CT req msg in this case > can be thought of as a subset of the Context Transfer packet. > > > > Post-Connection: > > > > > > Pre-Connection: > > > > > > 2. From oldAR to newAR > > > > > > IP Header > > > CT Header > > > MN IP address > > > newAR IP address > > > + Context ok, perhaps I missed something in your text. So both pre and post connection can occur in both directions, right? As someone else stated, I think that this is just becoming more and more complicated. Why not just define the protocol, and leave the implementor to decide when CT occurs? The messages would most likely be exactly the same in both cases anyways. With support for Multi-Phasic transfer, it allows critical info to be transferred to do things such as setup the L2 and L3 connections. PatC From owner-seamoby@diameter.org Wed Jun 27 15:25: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 PAA13101 for ; Wed, 27 Jun 2001 15:25:27 -0400 (EDT) Received: (qmail 22434 invoked by alias); 27 Jun 2001 18:47:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22427 invoked by uid 200); 27 Jun 2001 18:47:31 -0000 Received: (qmail 22421 invoked from network); 27 Jun 2001 18:47:27 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 18:47:27 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 14:58:06 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8091@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Singh Ajoy-ASINGH1'" , Kulwinder Atwal , "'Rajeev Koodli'" Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 14:58:01 -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: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, June 27, 2001 12:27 PM > To: 'Kulwinder Atwal'; Singh Ajoy-ASINGH1; 'Rajeev Koodli' > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > How does the newAR learn the IP address of the old AR? > > Ajoy: This can be sent in some layer 2 handoff request message > from oldAR to newAR. There are other ways too. Please > note that in cellular old BSC and new BSC exchange some > information before MN is tuned to different frequency at the > new BSC. > Yes, but in Bluetooth there is no L2 protocol message for passing the oldAR IP address. I need an IP message. -Kulwinder > > > -----Original Message----- > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > Sent: Wednesday, June 27, 2001 10:19 AM > To: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli' > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > -----Original Message----- > > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > > Sent: Wednesday, June 27, 2001 10:24 AM > > To: 'Kulwinder Atwal'; 'Rajeev Koodli' > > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > > > With Post-Connection CT the newAR knows nothing about the MN, > > so it cannot > > use an L2 Trigger, becuase it does not know who the MN is, > > where its Context > > may be, where its CoA maybe. > > > > Ajoy: L2 trigger can provide MN-ID and oldAR address info > > which can be > > used by newAR to initiate CT. This is similar to the link > > layer trigger at oldAR where > > trigger will have to provide IP address of newAR. > > How does the newAR learn the IP address of the old AR? > > - Kulwinder > > > > > > > > > -----Original Message----- > > From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] > > Sent: Monday, June 25, 2001 10:23 PM > > To: 'Rajeev Koodli'; Kulwinder Atwal > > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Monday, June 25, 2001 9:00 PM > > > To: Kulwinder Atwal > > > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > > > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > > > > > > > Kulwinder Atwal wrote: > > > > > > > > > > > Additionally, a MN message on a high bandwidth link could > > > be forwarded by > > > > the currentAR to the oldAR to request CT, and at the _same_ > > > time a MN > > > > message could be forwarded by the currentAR to the ParentAR > > > to affect a > > > > route change. > > > > > > > > The route change message may travel to a different entity > > > along a different > > > > link, than the Context Transfer request message. Having > > > them happen in > > > > parrallel could significantly reduce Reactive Context Transfer. > > > > > > > > > > > > > > Exactly. As soon as the MN detects that it has undergone > > > handover, it sends a > > > message which includes BU as an encapsulation. The new AR > > > sends the CT message > > > towards the old AR and the BU towards the mobility agent. > > > We proposed this (the message is SHIN) in our > > -smoothv6-.txt draft (in > > > Pittsburgh IETF). > > > > > > Post-Connection Context Transfer: > > > > Yes, I think it would take less time for the newAR to process > > a message from > > the MN that contained the necessary info. The newAR will > > need to ask the MN > > some indentity info anyway like: > > > > - Who are you? > > - Where is your Context located? > > - Where is your CoA located? > > > > Why can't the MN send the info needed to start a route change > > request and a > > CT request in the same packet as its identity? > > > > The MN is already there at the newAR with all the needed info. > > > > With Post-Connection CT the newAR knows nothing about the MN, > > so it cannot > > use an L2 Trigger, because it does not know who the MN is, > > where its Context > > may be, where its CoA maybe. > > > > It may turn out that the Context, and CoA are just too far > > away to attempt a > > CT (Maybe the MN was moving while experiencing a loss in > > connectivity). > > > > - Kulwinder. > > > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 15:27: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 PAA14871 for ; Wed, 27 Jun 2001 15:27:51 -0400 (EDT) Received: (qmail 23545 invoked by alias); 27 Jun 2001 19:06:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23538 invoked by uid 200); 27 Jun 2001 19:06:15 -0000 Received: (qmail 23528 invoked from network); 27 Jun 2001 19:06:12 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 19:06:12 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 15:16:56 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8093@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Pat Calhoun'" , Kulwinder Atwal Cc: "'Singh Ajoy-ASINGH1'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 15:16:49 -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: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 27, 2001 2:50 PM > To: Kulwinder Atwal > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; 'Pat Calhoun'; > seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote: > > > How does the newAR learn the IP address of the old AR? > > > > > > Ajoy: This can be sent in some layer 2 handoff request message > > > from oldAR to newAR. There are other ways too. Please > > > note that in cellular old BSC and new BSC exchange some > > > information before MN is tuned to different frequency at the > > > new BSC. > > > > > > > Yes, but in Bluetooth there is no L2 protocol message for > passing the oldAR > > IP address. I need an IP message. > > It seems you have a chicken and egg problem. If you cannot figure out > the IP address of the peer, how is a L3 message, being sent to an IP > address that you don't know, going to help? The MN does know the address of the oldAR, because it was just there. The MN tells the newAR the oldAR's IP address. Remember this is Post-Connection. The newAR may not know which AR the MN came from. The fastest way for it to find out is to ask the MN. The MN makes the introduction after L2 setup. - Kulwinder. > > PatC > From owner-seamoby@diameter.org Wed Jun 27 15:31: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 PAA16701 for ; Wed, 27 Jun 2001 15:31:04 -0400 (EDT) Received: (qmail 23657 invoked by alias); 27 Jun 2001 19:08:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23650 invoked by uid 200); 27 Jun 2001 19:08:36 -0000 Received: (qmail 23639 invoked by uid 500); 27 Jun 2001 19:08:32 -0000 Date: Wed, 27 Jun 2001 12:08:32 -0700 From: Pat Calhoun To: Kulwinder Atwal Cc: "'Pat Calhoun'" , "'Singh Ajoy-ASINGH1'" , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform Message-ID: <20010627120831.L22915@charizard.diameter.org> Mail-Followup-To: Kulwinder Atwal , 'Pat Calhoun' , 'Singh Ajoy-ASINGH1' , 'Rajeev Koodli' , seamoby@cdma-2000.org References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8093@NEPTUNE.zucotto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8093@NEPTUNE.zucotto.com>; from kulwinder.atwal@zucotto.com on Wed, Jun 27, 2001 at 03:16:49PM -0400 Sender: owner-seamoby@diameter.org Precedence: bulk On Wed, Jun 27, 2001 at 03:16:49PM -0400, Kulwinder Atwal wrote: > > > Yes, but in Bluetooth there is no L2 protocol message for > > passing the oldAR > > > IP address. I need an IP message. > > > > It seems you have a chicken and egg problem. If you cannot figure out > > the IP address of the peer, how is a L3 message, being sent to an IP > > address that you don't know, going to help? > > The MN does know the address of the oldAR, because it was just there. The > MN tells the newAR the oldAR's IP address. > > Remember this is Post-Connection. The newAR may not know which AR the MN > came from. The fastest way for it to find out is to ask the MN. The MN > makes the introduction after L2 setup. check. re-reading the requested change, I see that this is really a request for MN initiated CT. I got confused there for a moment. Thanks for your patience, PatC From owner-seamoby@diameter.org Wed Jun 27 17:43: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 RAA28308 for ; Wed, 27 Jun 2001 17:43:14 -0400 (EDT) Received: (qmail 26266 invoked by alias); 27 Jun 2001 21:31:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26260 invoked by uid 200); 27 Jun 2001 21:31:11 -0000 Received: (qmail 26253 invoked from network); 27 Jun 2001 21:31:09 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 21:31:09 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA18128 for ; Wed, 27 Jun 2001 14:42:29 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA18373 for ; Wed, 27 Jun 2001 14:42:28 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 16:42:28 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Kulwinder Atwal'" , "'Pat Calhoun'" Cc: Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 16:42:19 -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: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Wednesday, June 27, 2001 2:17 PM To: 'Pat Calhoun'; Kulwinder Atwal Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, June 27, 2001 2:50 PM > To: Kulwinder Atwal > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; 'Pat Calhoun'; > seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote: > > > How does the newAR learn the IP address of the old AR? > > > > > > Ajoy: This can be sent in some layer 2 handoff request message > > > from oldAR to newAR. There are other ways too. Please > > > note that in cellular old BSC and new BSC exchange some > > > information before MN is tuned to different frequency at the > > > new BSC. > > > > > > > Yes, but in Bluetooth there is no L2 protocol message for > passing the oldAR > > IP address. I need an IP message. > > It seems you have a chicken and egg problem. If you cannot figure out > the IP address of the peer, how is a L3 message, being sent to an IP > address that you don't know, going to help? The MN does know the address of the oldAR, because it was just there. The MN tells the newAR the oldAR's IP address. ajoy: Well this may work in some cases. Perhaps, we should also keep the option of MN sending some layer 3 message whenever link layer trigger is not available. I would rather prefer if Seamoby just defines Context transfer protocol and implementer can choose the appropriate trigger according to their need. The fastest way for it to find out is to ask the MN. The MN makes the introduction after L2 setup. ajoy: I do not think this assumption is always correct. Generally MN can exchange packet with new AR upon completion of following steps: 1. Radio link (L1) is established with new access network. 2. The PPP or some other link layer protocol is negotiated which may be used for framing. You may argue PPP is not always required so perhaps this is not valid in those cases. 3.In lossy link some protocol is required for error correction. I think most of the data link layer protocol requires synchronization between MN and network before it can exchange higher layer traffic. If step 2 and 3 are not present and RF bandwidth is more than wired bandwidth, then perhaps your assumption is correct. - Kulwinder. > > PatC > From owner-seamoby@diameter.org Wed Jun 27 17:52:55 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 RAA05130 for ; Wed, 27 Jun 2001 17:52:54 -0400 (EDT) Received: (qmail 26767 invoked by alias); 27 Jun 2001 21:40:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 26761 invoked by uid 200); 27 Jun 2001 21:40:52 -0000 Received: (qmail 26752 invoked from network); 27 Jun 2001 21:40:49 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 21:40:49 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 17:51:37 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8098@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Singh Ajoy-ASINGH1'" , Kulwinder Atwal , "'Pat Calhoun'" Cc: "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 17:51:33 -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: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, June 27, 2001 5:42 PM > To: 'Kulwinder Atwal'; 'Pat Calhoun' > Cc: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > -----Original Message---From: Kulwinder Atwal > [mailto:kulwinder.atwal@zucotto.com] > Sent: Wednesday, June 27, 2001 2:17 PM > To: 'Pat Calhoun'; Kulwinder Atwal > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Wednesday, June 27, 2001 2:50 PM > > To: Kulwinder Atwal > > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; 'Pat Calhoun'; > > seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > > > > On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote: > > > > How does the newAR learn the IP address of the old AR? > > > > > > > > Ajoy: This can be sent in some layer 2 handoff request message > > > > from oldAR to newAR. There are other ways too. Please > > > > note that in cellular old BSC and new BSC exchange some > > > > information before MN is tuned to different frequency at the > > > > new BSC. > > > > > > > > > > Yes, but in Bluetooth there is no L2 protocol message for > > passing the oldAR > > > IP address. I need an IP message. > > > > It seems you have a chicken and egg problem. If you cannot > figure out > > the IP address of the peer, how is a L3 message, being sent to an IP > > address that you don't know, going to help? > > The MN does know the address of the oldAR, because it was > just there. The > MN tells the newAR the oldAR's IP address. > > ajoy: Well this may work in some cases. Perhaps, we should also > keep the option of MN sending some layer 3 message whenever link layer > trigger is not available. I would rather prefer if Seamoby > just defines > Context transfer protocol and implementer can choose the > appropriate trigger > according to their need. > > The fastest way for it to find out is to ask the MN. The MN > makes the introduction after L2 setup. > > ajoy: I do not think this assumption is always correct. Generally > MN can exchange packet with new AR upon completion of following steps: > > 1. Radio link (L1) is established with new access network. > > 2. The PPP or some other link layer protocol is negotiated > which may be > used for framing. You may argue PPP is not always > required so perhaps this is not valid in those cases. > > 3.In lossy link some protocol is required for error correction. > I think most of the data link layer protocol requires > synchronization between > MN and network before it can exchange higher layer traffic. > > If step 2 and 3 are not present and RF bandwidth is more than > wired bandwidth, > then perhaps your assumption is correct. In your network it may be this way, but for me: Step 2 is not present. step 1, 3 are one step. In Post-Connection, there is no wire for the MN to use. The MN only has the wireless link to convey the oldAR IP address. - Kulwinder. > > > > > > PatC > > > From owner-seamoby@diameter.org Wed Jun 27 19:19: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 TAA02144 for ; Wed, 27 Jun 2001 19:19:34 -0400 (EDT) Received: (qmail 27446 invoked by alias); 27 Jun 2001 23:07:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27440 invoked by uid 200); 27 Jun 2001 23:07:03 -0000 Received: (qmail 27435 invoked from network); 27 Jun 2001 23:07:01 -0000 Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 23:07:01 -0000 Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f5RNQdx28445; Wed, 27 Jun 2001 16:26:39 -0700 (PDT) Date: Wed, 27 Jun 2001 16:26:39 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: Emil Sturniolo cc: Kulwinder Atwal , James Kempf , seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: RE: [seamoby] Question on 4.2 In-Reply-To: <009b01c0ff08$e4964b10$7c168fd1@wrq-nc1.wrq.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk I sort of agree with Emil and let me give you an example I have thought about. Consider the picture below to illustrate my point. | <--> +----+ ========= [] # |AP 1|---------| AR 1 |-----+ MN | +----+ / ========= | | / | | / | | | / | ------- | | / +--|ANG 1|---+ | +----+ / | ------- | V |AP 2|/ | | +----+ | | | | If a MN moves from AP1 to AP2, where both APs are connected to the same L3 entity, AR1, there is no MIP process should be involved since the MN does not change in terms of MIP. This puts the MN's mobility support, pretty much, relying completely on the L2 technology of AP1 & AP2. My question is that what if AP1 and AP2 does not support fast/smooth handoff at L2. Does this mean automatically that the L3 communication during this move is disrupted, blacked out, or discontinuous for a short time? In other words, the choice of the L2 technology may be crucial for the outcomes at L3? In any cases, independently from the L2 capability, L3 can still be seamless without interruptions. This can be possible if L3 is aware of what events are occurred at L2. To certain degree, I agree L3 should also be involved in movement matters by interacting with the lower layer. Maybe, this is not really the scope of SeaMoby or IETF since this case is within a single L3 entity while switching only between L2 entities. Secondly, if AP1 and AP2 are running different access technolgoies, it gets even more interesting because there is no clear definition of L2 handoff. It may get to a problem where L3 is choosing one link from two simultaneously available connections. User preference may also come in to play in this case. I just recall that L2 trigger is a special case of this L2-L3 interaction. At the same time, L2 trigger is a kind of L3-awaring mechanism about the mobility of a MN itself. Any thoughts? Arguments? Objections? Let me know... Youngjune On Wed, 27 Jun 2001, Emil Sturniolo wrote: > Kulwinder. > > > James, > > > > ... snip... > > >1. Fast movement detection/prediction > > > > Well, actually, I do disagree here. > > > > I believe the following view more accurately reflects > > what is going on between L2 and L3 around handover. Basically, L3 > > is not concerned with movement, it is concerned with routability > > changes, L2 is concerned with movement. To be more specific, L3 is > > only concerned with movement to the extent that a movement at L2 > > causes > > a change in routability that requires (for MIP) a change in CoA. If > > movement > > causes no change in routability, then L3 should not be involved. > > ........ > > > > [Emil]. James, I'd like to add one scenario that might slightly > change > > the semantics, if it's within the scope of the conversation. Most of > > this thread has been concern with the situation where connectivity > at > > L2 is constant and possibly predictive. However, it has been my > > experience that this is not truly reflective of reality. IMHO L3 > > should be involved if a mobile node becomes detached and then > > reattached to the same network, even though no changes in > routability > > may have occurred. > > > L3 needs to be knowledgeable of this event to at > > least verify routability and possibly facilitate faster recovery at > > even higher levels in the protocol stack (slings and arrows > welcome). > > I would say that L3 mobility is concerned about routability and not > concerned with movement. > If a router has mulitiple L2 interfaces then a change from one L2 > interface > to another will not affect L3. In this case, L2 can verify > routability > because it is still the same AR. > > If it is a different AR, then there is a change in routability, and a > need > to inform L3 mobility. > > Unless, there is another case that comes to mind. > > - Kulwinder. > > [Emil] Kulwinder, what I was trying to point out is that even though > it is still the same AR it is still useful to signal L3 that > connectivity has been re-established. Off the top of my head, > depending on when and the length of time that the MN was disconnected, > after L2 connectivity is reaffirmed, it may need to determine if its > own addressibility is still valid Furthermore, as I said in my > original note, this indication may also help facilitate recovery > further up the stack. Maybe this is a different trigger that I am > describing here, but it does seem to be consistent with > acquisition/continuation of L2 connectivity. > > Cordially, > Emil Sturniolo > EmilS@NetMotionWireless.Com > www.NetMotionWireless.com > 330-723-9099 > 330-461-0326 - Mobile/Voice Mail > ===================== > > > From owner-seamoby@diameter.org Wed Jun 27 19: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 TAA04420 for ; Wed, 27 Jun 2001 19:23:10 -0400 (EDT) Received: (qmail 27914 invoked by alias); 27 Jun 2001 23:10:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27904 invoked by uid 200); 27 Jun 2001 23:10:36 -0000 Received: (qmail 27884 invoked from network); 27 Jun 2001 23:10:31 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jun 2001 23:10:31 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA05128 for ; Wed, 27 Jun 2001 16:14:46 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA02660 for ; Wed, 27 Jun 2001 16:21:37 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 18:21:36 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Kulwinder Atwal'" , Singh Ajoy-ASINGH1 , "'Pat Calhoun'" Cc: "'Rajeev Koodli'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Wed, 27 Jun 2001 18:21:35 -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 In your network it may be this way, but for me: Step 2 is not present. step 1, 3 are one step. In Post-Connection, there is no wire for the MN to use. The MN only has the wireless link to convey the oldAR IP address. Ajoy: I did not mean that there is a wire between MN and access network. I meant any L2 message sent from oldAR to new AR over wired link will be faster than message from MN to newAR. I suppose you were claiming that fastest way to inform AR is to send layer 3 message from MN to new AR. -----Original Message----- From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Wednesday, June 27, 2001 4:52 PM To: 'Singh Ajoy-ASINGH1'; Kulwinder Atwal; 'Pat Calhoun' Cc: 'Rajeev Koodli'; seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, June 27, 2001 5:42 PM > To: 'Kulwinder Atwal'; 'Pat Calhoun' > Cc: Singh Ajoy-ASINGH1; 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > -----Original Message---From: Kulwinder Atwal > [mailto:kulwinder.atwal@zucotto.com] > Sent: Wednesday, June 27, 2001 2:17 PM > To: 'Pat Calhoun'; Kulwinder Atwal > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; seamoby@cdma-2000.org > Subject: RE: [seamoby] Issue 2: Make IP messages uniform > > > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Wednesday, June 27, 2001 2:50 PM > > To: Kulwinder Atwal > > Cc: 'Singh Ajoy-ASINGH1'; 'Rajeev Koodli'; 'Pat Calhoun'; > > seamoby@cdma-2000.org > > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > > > > On Wed, Jun 27, 2001 at 02:58:01PM -0400, Kulwinder Atwal wrote: > > > > How does the newAR learn the IP address of the old AR? > > > > > > > > Ajoy: This can be sent in some layer 2 handoff request message > > > > from oldAR to newAR. There are other ways too. Please > > > > note that in cellular old BSC and new BSC exchange some > > > > information before MN is tuned to different frequency at the > > > > new BSC. > > > > > > > > > > Yes, but in Bluetooth there is no L2 protocol message for > > passing the oldAR > > > IP address. I need an IP message. > > > > It seems you have a chicken and egg problem. If you cannot > figure out > > the IP address of the peer, how is a L3 message, being sent to an IP > > address that you don't know, going to help? > > The MN does know the address of the oldAR, because it was > just there. The > MN tells the newAR the oldAR's IP address. > > ajoy: Well this may work in some cases. Perhaps, we should also > keep the option of MN sending some layer 3 message whenever link layer > trigger is not available. I would rather prefer if Seamoby > just defines > Context transfer protocol and implementer can choose the > appropriate trigger > according to their need. > > The fastest way for it to find out is to ask the MN. The MN > makes the introduction after L2 setup. > > ajoy: I do not think this assumption is always correct. Generally > MN can exchange packet with new AR upon completion of following steps: > > 1. Radio link (L1) is established with new access network. > > 2. The PPP or some other link layer protocol is negotiated > which may be > used for framing. You may argue PPP is not always > required so perhaps this is not valid in those cases. > > 3.In lossy link some protocol is required for error correction. > I think most of the data link layer protocol requires > synchronization between > MN and network before it can exchange higher layer traffic. > > If step 2 and 3 are not present and RF bandwidth is more than > wired bandwidth, > then perhaps your assumption is correct. In your network it may be this way, but for me: Step 2 is not present. step 1, 3 are one step. In Post-Connection, there is no wire for the MN to use. The MN only has the wireless link to convey the oldAR IP address. - Kulwinder. > > > > > > PatC > > > From owner-seamoby@diameter.org Wed Jun 27 20:20: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 UAA13518 for ; Wed, 27 Jun 2001 20:20:06 -0400 (EDT) Received: (qmail 28543 invoked by alias); 28 Jun 2001 00:07:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28537 invoked by uid 200); 28 Jun 2001 00:07:51 -0000 Received: (qmail 28531 invoked from network); 28 Jun 2001 00:07:48 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 00:07:48 -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 RAA01224; Wed, 27 Jun 2001 17:18:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5S0Ic030473; Wed, 27 Jun 2001 17:18:38 -0700 X-mProtect: Wed, 27 Jun 2001 17:18:38 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdazDDVk; Wed, 27 Jun 2001 17:18:36 PDT Message-ID: <3B3A77DC.FBAC9D92@iprg.nokia.com> Date: Wed, 27 Jun 2001 17:18:37 -0700 From: Rajeev Koodli 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: Kulwinder Atwal CC: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8088@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: > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > 2. after the new AR becomes the MN's default router > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > The point of above text was to indicate that defining context > > transfer to be > > independent of handover is perhaps not sensible. Getting it > > to work with > > handovers is the challenge we are peddling. > > If we all agree on this, may be we should try to close the issue ? > > > > Regards, > > > > -Rajeev > > How is this: > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the > newAR becomes the MN's default router. > > Post-Handoff Context Transfer: The Context Transfer is initiated after the > newAR becomes the MN's default router. > > -Kulwinder. > > Rajeev: This would work for me. May be we should ask PatC on how to proceed next? Regards, -Rajeev > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > > start, exact > > > middle, or end of handover, or some special protocol event > > in the middle. > > > In a collision based wired, or a wireless network we can't > > be certain which > > > protocol packet will arrive first. > > > > > > Also, we all seem to agree that if pre-connection Context > > Transfer takes too > > > long due to the uncertain nature of wireless (End-user > > drives through a > > > tunnel), it is very likely that several post-connection > > events will pass > > > before the transfer is complete. > > > > > > So, we may start with the best of intentions with the > > intent of being early > > > enough to not affect the user experience, but events may > > overtake us such > > > that we find ourselves out of time. > > > > > > So, what do we do at that point in time? > > > > > > A particular technology may find it advantageous to do > > post-connection, if > > > the data is available, even after the user has experienced > > a distruption, > > > becuase the connection setup time will be longer than the > > post-connection > > > Context Transfer time. > > > > > > An other technology may find it advantageous to > > re-establish new context, > > > because the Context Transfer time (Round-Trip Times) are > > greater than new > > > connection setup. > > > > > > - Kulwinder. > > > > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > It is up to the implementor to take into account particular > > > > network and > > > > > inter-network characteristics and real-time flow > > > > requirements to determine > > > > > how early Pre-Connection Context Transfer needs to be done > > > > to guarrantee > > > > > seamless. > > > > > > > > > > - Kulwinder. > > > > > > > > > > > In all cases that I > > > > > > know of, some > > > > > > signalling, either at L2 or L3, is used to register the > > > > > > mobile locally (or > > > > > > some signal strength measurements), but there is always an > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > > > comes from if we are > > > > > > > going to process it just the same? > > > > > > > > > > > > > > The only thing that is important is that the requesting > > > > > > entity recieve a > > > > > > > packet indicating the success or failure mode of the CT > > > > operation. > > > > > > > > > > > > ditto. > > > > > > > > > > > > PatC > > > > > > > > > > > > From owner-seamoby@diameter.org Wed Jun 27 20:28: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 UAA19400 for ; Wed, 27 Jun 2001 20:28:35 -0400 (EDT) Received: (qmail 29036 invoked by alias); 28 Jun 2001 00:16:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29030 invoked by uid 200); 28 Jun 2001 00:16:49 -0000 Received: (qmail 29021 invoked from network); 28 Jun 2001 00:16:45 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 00:16:45 -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 RAA01694; Wed, 27 Jun 2001 17:27:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5S0RZk05398; Wed, 27 Jun 2001 17:27:35 -0700 X-mProtect: Wed, 27 Jun 2001 17:27:35 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpduntcQE; Wed, 27 Jun 2001 17:27:33 PDT Message-ID: <3B3A79F6.121C8EFE@iprg.nokia.com> Date: Wed, 27 Jun 2001 17:27:34 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8082@NEPTUNE.zucotto.com> <3B3917D5.80461B22@iprg.nokia.com> <20010626161703.K22915@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > 2. after the new AR becomes the MN's default router > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > The point of above text was to indicate that defining context transfer to be > > independent of handover is perhaps not sensible. Getting it to work with > > handovers is the challenge we are peddling. > > If we all agree on this, may be we should try to close the issue ? > > The issue I have is that the current definitions use some random packet destined > for the mobile as the timing "event". This, im my mind, makes no sense whatsoever, > because one side (oAR) may not know when the packet shows up, and therefore it > has no idea whether a reactive or proactive CT is to be invoked. > > FWIW, some CTs will transfer L2 session keys used for authentication and > encryption, so this is where the first packet doesn't make sense. > > Rajeev: But the above text (and the text Kulwinder sent today) does not say anything about the "first" packet. It is based on whether CT is initiated when the new AR is (not) the default router. -Rajeev > PatC > > > > Regards, > > > > -Rajeev > > > > From owner-seamoby@diameter.org Thu Jun 28 03:13: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 DAA08201 for ; Thu, 28 Jun 2001 03:13:40 -0400 (EDT) Received: (qmail 29954 invoked by alias); 28 Jun 2001 07:01:57 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29948 invoked by uid 200); 28 Jun 2001 07:01:56 -0000 Received: (qmail 29943 invoked from network); 28 Jun 2001 07:01:53 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 07:01:53 -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 AAA15637; Thu, 28 Jun 2001 00:12:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5S7CiX05698; Thu, 28 Jun 2001 00:12:44 -0700 X-mProtect: Thu, 28 Jun 2001 00:12:44 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin1.iprg.nokia.com (205.226.20.231, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBHxgKJ; Thu, 28 Jun 2001 00:12:42 PDT Message-ID: <3B3AD915.B97629EC@iprg.nokia.com> Date: Thu, 28 Jun 2001 00:13:25 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Koodli , Kulwinder Atwal CC: "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8088@NEPTUNE.zucotto.com> <3B3A77DC.FBAC9D92@iprg.nokia.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, Rajeev Koodli wrote: > > How is this: > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the > > newAR becomes the MN's default router. > > > > Post-Handoff Context Transfer: The Context Transfer is initiated after the > > newAR becomes the MN's default router. > > > > -Kulwinder. > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to proceed > next? From this, I gather that the words "reactive" and "proactive" aren't going to be used. Suppose a mobile node shows up, and detects a beacon from the new access router (not at layer 3). Then it sends a signal to the router to initiate handover and context transfer. System design dictates that the new router becomes the default router as a consequence of installing the context features. Is this a "pre-" or "post-" handover context transfer? I would say that it happens _at the same time_ as handover, and furthermore that it is reactive. Anyway, the definitions chosen should not preclude sensible understanding of this scenario. Regards, Charlie P. From owner-seamoby@diameter.org Thu Jun 28 08:28: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 IAA13602 for ; Thu, 28 Jun 2001 08:28:17 -0400 (EDT) Received: (qmail 31150 invoked by alias); 28 Jun 2001 11:53:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31144 invoked by uid 200); 28 Jun 2001 11:53:28 -0000 Received: (qmail 31139 invoked from network); 28 Jun 2001 11:53:25 -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; 28 Jun 2001 11:53:25 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SC43016720 for ; Thu, 28 Jun 2001 08:04:03 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 08:04:00 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 08:03:43 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD116@zcard031.ca.nortel.com> From: "Hamid Syed" To: "'Charlie Perkins'" Cc: "'seamoby@cdma-2000.org'" , Rajeev Koodli , Kulwinder Atwal Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 08:03:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFCA.61AABCF0" 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_01C0FFCA.61AABCF0 Content-Type: text/plain Hello Charlie, see my comments below > -----Original Message----- > From: Charlie Perkins [SMTP:charliep@IPRG.nokia.com] > Sent: Thursday, June 28, 2001 3:13 AM > To: Rajeev Koodli; Kulwinder Atwal > Cc: 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive and re active CT definitions > > > > Hello folks, > > Rajeev Koodli wrote: > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior > to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is initiated > after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to > proceed > > next? > > From this, I gather that the words "reactive" and "proactive" aren't going > to be > used. > > Suppose a mobile node shows up, and detects a beacon from the > new access router (not at layer 3). Then it sends a signal to the router > to initiate handover and context transfer. System design dictates that > the new router becomes the default router as a consequence of installing > the context features. Is this a "pre-" or "post-" handover context > transfer? > I would say that it happens _at the same time_ as handover, and > furthermore that it is reactive. [Syed, Hamid [WDLN2:AN22:EXCH]] Of course, the scenario you described here is reactive context transfer where the same event initiated the context transfer and the handover of the Mobile's flows. But this is one of the many possible scenarios. What about the cases where the events initiating CT and handover are different? A separate event could be used whenever a mobile is detected by an AR to initiate the context transfer. This does not guarantee that a handover of the mobile's flows would happen to the same AR. The default is still the old AR. I would call it a proactive context transfer. > Anyway, the definitions chosen should not preclude sensible understanding > of this scenario. > > Regards, > Charlie P. > > ------_=_NextPart_001_01C0FFCA.61AABCF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: [seamoby] CT trigger or CT completion? was: proactive = and re active CT definitions

Hello = Charlie,

see my comments = below

    -----Original Message-----
    From:   Charlie Perkins = [SMTP:charliep@IPRG.nokia.com]
    Sent:   Thursday, June 28, 2001 3:13 AM
    To:     Rajeev Koodli; Kulwinder Atwal
    Cc:     'seamoby@cdma-2000.org'
    Subject:       = Re: FW: [seamoby] CT trigger or CT = completion? was: proactive and re  active CT definitions



    Hello folks,

    Rajeev Koodli wrote:

    > > How is this:
    > >
    > > Pre-Handoff Context = Transfer: The Context Transfer is initiated prior to the
    > > newAR becomes the MN's = default router.
    > >
    > > Post-Handoff Context = Transfer:  The Context Transfer is initiated after the
    > > newAR becomes the MN's = default router.
    > >
    > > -Kulwinder.
    > >
    > >
    >
    > Rajeev: This would work for = me.  May be we should ask PatC on how to proceed
    > next?

    From this, I gather that the words = "reactive" and "proactive" aren't going to = be
    used.

    Suppose a mobile node shows up, and = detects a beacon from the
    new access router (not at layer = 3).  Then it sends a signal to the router
    to initiate handover and context = transfer.  System design dictates that
    the new router becomes the default = router as a consequence of installing
    the context features.  Is this a = "pre-" or "post-" handover context transfer?
    I would say that it happens _at the = same time_ as handover, and
    furthermore that it is = reactive.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Of course, the scenario you described here is = reactive context transfer where the same event initiated the context = transfer and the handover of the Mobile's flows. But this is one of the = many possible scenarios.

    What about the cases = where the events initiating CT and handover are different? A separate = event could be used whenever a mobile is detected by an AR to initiate = the context transfer. This does not guarantee that a handover of the = mobile's flows would happen to the same AR. The default is still the = old AR. I would call it a proactive context transfer.

    Anyway, the definitions chosen should = not preclude sensible understanding
    of this scenario.

    Regards,
    Charlie P.


------_=_NextPart_001_01C0FFCA.61AABCF0-- From owner-seamoby@diameter.org Thu Jun 28 09:40:26 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05889 for ; Thu, 28 Jun 2001 09:40:20 -0400 (EDT) Received: (qmail 31800 invoked by alias); 28 Jun 2001 13:27:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31794 invoked by uid 200); 28 Jun 2001 13:27:38 -0000 Received: (qmail 31783 invoked by uid 500); 28 Jun 2001 13:27:36 -0000 Date: Thu, 28 Jun 2001 06:27:35 -0700 From: Pat Calhoun To: Youngjune Lee Gwon Cc: Emil Sturniolo , Kulwinder Atwal , James Kempf , seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: Re: [seamoby] Question on 4.2 Message-ID: <20010628062735.H22915@charizard.diameter.org> Mail-Followup-To: Youngjune Lee Gwon , Emil Sturniolo , Kulwinder Atwal , James Kempf , seamoby@diameter.org, PNeumiller@meshnetworks.com References: <009b01c0ff08$e4964b10$7c168fd1@wrq-nc1.wrq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gyj@dcl.docomo-usa.com on Wed, Jun 27, 2001 at 04:26:39PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk If I understand you correctly, I am in agreement. Even if the link layer doesn't provide "fast handoff", but L3 (e.g. Mobile IP) does (perhaps via Fast MIP), you can still get seamless service. My point all along, btw, was that in order for this to occur, we really need to minimize the number of round trips over the air, and re-using existing messages in the L3 mobility management protocol is the best approach. In the MIP case, we are talking about the BU. PatC On Wed, Jun 27, 2001 at 04:26:39PM -0700, Youngjune Lee Gwon wrote: > I sort of agree with Emil and let me give you an example I have thought > about. Consider the picture below to illustrate my point. > > > | <--> +----+ ========= > [] # |AP 1|---------| AR 1 |-----+ > MN | +----+ / ========= | > | / | > | / | | > | / | ------- | > | / +--|ANG 1|---+ > | +----+ / | ------- | > V |AP 2|/ | | > +----+ | | > | | > > If a MN moves from AP1 to AP2, where both APs are connected to the same L3 > entity, AR1, there is no MIP process should be involved since the MN does > not change in terms of MIP. > > This puts the MN's mobility support, pretty much, relying completely on > the L2 technology of AP1 & AP2. My question is that what if AP1 and AP2 > does not support fast/smooth handoff at L2. Does this mean automatically > that the L3 communication during this move is disrupted, blacked out, or > discontinuous for a short time? In other words, the choice of the L2 > technology may be crucial for the outcomes at L3? > > In any cases, independently from the L2 capability, L3 can still be > seamless without interruptions. This can be possible if L3 is aware of > what events are occurred at L2. To certain degree, I agree L3 should also > be involved in movement matters by interacting with the lower layer. > > Maybe, this is not really the scope of SeaMoby or IETF since this case is > within a single L3 entity while switching only between L2 entities. > > Secondly, if AP1 and AP2 are running different access technolgoies, it > gets even more interesting because there is no clear definition of L2 > handoff. It may get to a problem where L3 is choosing one link from two > simultaneously available connections. User preference may also come in to > play in this case. > > I just recall that L2 trigger is a special case of this L2-L3 interaction. > At the same time, L2 trigger is a kind of L3-awaring mechanism about the > mobility of a MN itself. > > Any thoughts? Arguments? Objections? Let me know... > > Youngjune > > On Wed, 27 Jun 2001, Emil Sturniolo wrote: > > > Kulwinder. > > > > > James, > > > > > > ... snip... > > > >1. Fast movement detection/prediction > > > > > > Well, actually, I do disagree here. > > > > > > I believe the following view more accurately reflects > > > what is going on between L2 and L3 around handover. Basically, L3 > > > is not concerned with movement, it is concerned with routability > > > changes, L2 is concerned with movement. To be more specific, L3 is > > > only concerned with movement to the extent that a movement at L2 > > > causes > > > a change in routability that requires (for MIP) a change in CoA. If > > > movement > > > causes no change in routability, then L3 should not be involved. > > > ........ > > > > > > [Emil]. James, I'd like to add one scenario that might slightly > > change > > > the semantics, if it's within the scope of the conversation. Most of > > > this thread has been concern with the situation where connectivity > > at > > > L2 is constant and possibly predictive. However, it has been my > > > experience that this is not truly reflective of reality. IMHO L3 > > > should be involved if a mobile node becomes detached and then > > > reattached to the same network, even though no changes in > > routability > > > may have occurred. > > > > > L3 needs to be knowledgeable of this event to at > > > least verify routability and possibly facilitate faster recovery at > > > even higher levels in the protocol stack (slings and arrows > > welcome). > > > > I would say that L3 mobility is concerned about routability and not > > concerned with movement. > > If a router has mulitiple L2 interfaces then a change from one L2 > > interface > > to another will not affect L3. In this case, L2 can verify > > routability > > because it is still the same AR. > > > > If it is a different AR, then there is a change in routability, and a > > need > > to inform L3 mobility. > > > > Unless, there is another case that comes to mind. > > > > - Kulwinder. > > > > [Emil] Kulwinder, what I was trying to point out is that even though > > it is still the same AR it is still useful to signal L3 that > > connectivity has been re-established. Off the top of my head, > > depending on when and the length of time that the MN was disconnected, > > after L2 connectivity is reaffirmed, it may need to determine if its > > own addressibility is still valid Furthermore, as I said in my > > original note, this indication may also help facilitate recovery > > further up the stack. Maybe this is a different trigger that I am > > describing here, but it does seem to be consistent with > > acquisition/continuation of L2 connectivity. > > > > Cordially, > > Emil Sturniolo > > EmilS@NetMotionWireless.Com > > www.NetMotionWireless.com > > 330-723-9099 > > 330-461-0326 - Mobile/Voice Mail > > ===================== > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 09:48: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 JAA12226 for ; Thu, 28 Jun 2001 09:48:01 -0400 (EDT) Received: (qmail 32285 invoked by alias); 28 Jun 2001 13:33:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32274 invoked by uid 200); 28 Jun 2001 13:33:05 -0000 Received: (qmail 32261 invoked from network); 28 Jun 2001 13:33:02 -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; 28 Jun 2001 13:33:02 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SDhe001851 for ; Thu, 28 Jun 2001 09:43:40 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 09:43:39 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 09:43:21 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DA8@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 09:43:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFD8.4BF77020" 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_01C0FFD8.4BF77020 Content-Type: text/plain; charset="iso-8859-1" Define "handoff". Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 27, 2001 8:19 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Kulwinder Atwal wrote: > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > The point of above text was to indicate that defining context > > > transfer to be > > > independent of handover is perhaps not sensible. Getting it > > > to work with > > > handovers is the challenge we are peddling. > > > If we all agree on this, may be we should try to close the issue ? > > > > > > Regards, > > > > > > -Rajeev > > > > How is this: > > > > Pre-Handoff Context Transfer: The Context Transfer is > initiated prior to the > > newAR becomes the MN's default router. > > > > Post-Handoff Context Transfer: The Context Transfer is > initiated after the > > newAR becomes the MN's default router. > > > > -Kulwinder. > > > > > > Rajeev: This would work for me. May be we should ask PatC on > how to proceed > next? > > Regards, > > -Rajeev > > > > > > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > > > start, exact > > > > middle, or end of handover, or some special protocol event > > > in the middle. > > > > In a collision based wired, or a wireless network we can't > > > be certain which > > > > protocol packet will arrive first. > > > > > > > > Also, we all seem to agree that if pre-connection Context > > > Transfer takes too > > > > long due to the uncertain nature of wireless (End-user > > > drives through a > > > > tunnel), it is very likely that several post-connection > > > events will pass > > > > before the transfer is complete. > > > > > > > > So, we may start with the best of intentions with the > > > intent of being early > > > > enough to not affect the user experience, but events may > > > overtake us such > > > > that we find ourselves out of time. > > > > > > > > So, what do we do at that point in time? > > > > > > > > A particular technology may find it advantageous to do > > > post-connection, if > > > > the data is available, even after the user has experienced > > > a distruption, > > > > becuase the connection setup time will be longer than the > > > post-connection > > > > Context Transfer time. > > > > > > > > An other technology may find it advantageous to > > > re-establish new context, > > > > because the Context Transfer time (Round-Trip Times) are > > > greater than new > > > > connection setup. > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > It is up to the implementor to take into account particular > > > > > network and > > > > > > inter-network characteristics and real-time flow > > > > > requirements to determine > > > > > > how early Pre-Connection Context Transfer needs to be done > > > > > to guarrantee > > > > > > seamless. > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > In all cases that I > > > > > > > know of, some > > > > > > > signalling, either at L2 or L3, is used to register the > > > > > > > mobile locally (or > > > > > > > some signal strength measurements), but there is always an > > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > > > > But, really why should we care where the request for CT > > > > > > > comes from if we are > > > > > > > > going to process it just the same? > > > > > > > > > > > > > > > > The only thing that is important is that the requesting > > > > > > > entity recieve a > > > > > > > > packet indicating the success or failure mode of the CT > > > > > operation. > > > > > > > > > > > > > > ditto. > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0FFD8.4BF77020 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

Define "handoff".

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Wednesday, June 27, 2001 8:19 PM
> To: Kulwinder Atwal
> Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
> Kulwinder Atwal wrote:
>
> > > > >
> > > > > Rajeev: I guess the point is that you would do CT either
> > > > >
> > > > > 1. before the new AR becomes the MN's default router, or
> > > > > 2. after the new AR becomes the MN's default router
> > > > >
> > > > > Both 1) and 2) are related to handover.
> > > >
> > > >
> > >
> > > The point of above text was to indicate that defining context
> > > transfer to be
> > > independent of handover is perhaps not sensible. Getting it
> > > to work with
> > > handovers is the challenge we are peddling.
> > > If we all agree on this, may be we should try to close the issue ?
> > >
> > > Regards,
> > >
> > > -Rajeev
> >
> > How is this:
> >
> > Pre-Handoff Context Transfer: The Context Transfer is
> initiated prior to the
> > newAR becomes the MN's default router.
> >
> > Post-Handoff Context Transfer:  The Context Transfer is
> initiated after the
> > newAR becomes the MN's default router.
> >
> > -Kulwinder.
> >
> >
>
> Rajeev: This would work for me.  May be we should ask PatC on
> how to proceed
> next?
>
> Regards,
>
> -Rajeev
>
>
> > >
> > >
> > > > Yes, but handover is pretty vague. Like Gary said, is the
> > > start, exact
> > > > middle, or end of handover, or some special protocol event
> > > in the middle.
> > > > In a collision based wired, or a wireless network we can't
> > > be certain which
> > > > protocol packet will arrive first.
> > > >
> > > > Also, we all seem to agree that if pre-connection Context
> > > Transfer takes too
> > > > long due to the uncertain nature of wireless (End-user
> > > drives through a
> > > > tunnel), it is very likely that several post-connection
> > > events will pass
> > > > before the transfer is complete.
> > > >
> > > > So, we may start with the best of intentions with the
> > > intent of being early
> > > > enough to not affect the user experience, but events may
> > > overtake us such
> > > > that we find ourselves out of time.
> > > >
> > > > So, what do we do at that point in time?
> > > >
> > > > A particular technology may find it advantageous to do
> > > post-connection, if
> > > > the data is available, even after the user has experienced
> > > a distruption,
> > > > becuase the connection setup time will be longer than the
> > > post-connection
> > > > Context Transfer time.
> > > >
> > > > An other technology may find it advantageous to
> > > re-establish new context,
> > > > because the Context Transfer time (Round-Trip Times) are
> > > greater than new
> > > > connection setup.
> > > >
> > > > - Kulwinder.
> > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > > It is up to the implementor to take into account particular
> > > > > network and
> > > > > > inter-network characteristics and real-time flow
> > > > > requirements to determine
> > > > > > how early Pre-Connection Context Transfer needs to be done
> > > > > to guarrantee
> > > > > > seamless.
> > > > > >
> > > > > > - Kulwinder.
> > > > > >
> > > > > > > In all cases that I
> > > > > > > know of, some
> > > > > > > signalling, either at L2 or L3, is used to register the
> > > > > > > mobile locally (or
> > > > > > > some signal strength measurements), but there is always an
> > > > > > > indication of handoff.
> > > > > > >
> > > > > > >
> > > > > > > > But, really why should we care where the request for CT
> > > > > > > comes from if we are
> > > > > > > > going to process it just the same?
> > > > > > > >
> > > > > > > > The only thing that is important is that the requesting
> > > > > > > entity recieve a
> > > > > > > > packet indicating the success or failure mode of the CT
> > > > > operation.
> > > > > > >
> > > > > > > ditto.
> > > > > > >
> > > > > > > PatC
> > > > > > >
> > > > >
> > >
>
>

------_=_NextPart_001_01C0FFD8.4BF77020-- From owner-seamoby@diameter.org Thu Jun 28 09:53: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 JAA16140 for ; Thu, 28 Jun 2001 09:53:38 -0400 (EDT) Received: (qmail 32454 invoked by alias); 28 Jun 2001 13:35:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32448 invoked by uid 200); 28 Jun 2001 13:35:40 -0000 Received: (qmail 32438 invoked by uid 500); 28 Jun 2001 13:35:36 -0000 Date: Thu, 28 Jun 2001 06:35:36 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010628063536.J22915@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Kulwinder Atwal , 'Pat Calhoun' , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8088@NEPTUNE.zucotto.com> <3B3A77DC.FBAC9D92@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3A77DC.FBAC9D92@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Wed, Jun 27, 2001 at 05:18:37PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > > How is this: > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the > > newAR becomes the MN's default router. > > > > Post-Handoff Context Transfer: The Context Transfer is initiated after the > > newAR becomes the MN's default router. > > > > -Kulwinder. > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to proceed > next? what do folks think about using this terminology? Is this preferred over the existing terminology in the draft? PatC From owner-seamoby@diameter.org Thu Jun 28 09:57: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 JAA19090 for ; Thu, 28 Jun 2001 09:57:52 -0400 (EDT) Received: (qmail 773 invoked by alias); 28 Jun 2001 13:43:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 766 invoked by uid 200); 28 Jun 2001 13:43:56 -0000 Received: (qmail 748 invoked from network); 28 Jun 2001 13:43:50 -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; 28 Jun 2001 13:43:50 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SDsS004006 for ; Thu, 28 Jun 2001 09:54:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 09:54:17 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 09:53:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DA9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Pat Calhoun Cc: Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 09:53:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFD9.BDB3B0B0" 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_01C0FFD9.BDB3B0B0 Content-Type: text/plain; charset="iso-8859-1" To expand a bit on my previous question: what defines a "default router" in a mobile wireless access network? This is a similar issue to defining "what is a handoff or handover". Before everyone starts talking MIP, be reminded that the charter (and the problem statement, and the requirements) state that ct should work with with different wireless networks and different mobility solutions and not just with MIP (if ct is to be an augmentation of MIP, fine, let Pat rewrite the charter and those of use who need to work on non-MIP ct can move on). Clearly, from the discussion that has transpired, if we all really believe that defining an "event" for reactive mode in the requirements draft is key to making ct work, then we should define what a handover is. As everyone knows by now, I do not believe it is required by for the requirement document, and even more important, I suspect that a general definition of handover will take a long time to work out. However, if the wg believes it is needed, then let's make the valiant attempt. Regards, Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Wednesday, June 27, 2001 8:28 PM > To: Pat Calhoun > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Pat Calhoun wrote: > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > The point of above text was to indicate that defining > context transfer to be > > > independent of handover is perhaps not sensible. Getting > it to work with > > > handovers is the challenge we are peddling. > > > If we all agree on this, may be we should try to close the issue ? > > > > The issue I have is that the current definitions use some > random packet destined > > for the mobile as the timing "event". This, im my mind, > makes no sense whatsoever, > > because one side (oAR) may not know when the packet shows > up, and therefore it > > has no idea whether a reactive or proactive CT is to be invoked. > > > > FWIW, some CTs will transfer L2 session keys used for > authentication and > > encryption, so this is where the first packet doesn't make sense. > > > > > > Rajeev: But the above text (and the text Kulwinder sent > today) does not say anything > about the "first" packet. It is based on whether CT is > initiated when the new AR is > (not) the default router. > > -Rajeev > > > > PatC > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > ------_=_NextPart_001_01C0FFD9.BDB3B0B0 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

To expand a bit on my previous question: what defines a "default router"
in a mobile wireless access network? This is a similar issue to defining
"what is a handoff or handover".

Before everyone starts talking MIP, be reminded that the charter (and the
problem statement, and the requirements) state that ct should work with
with different wireless networks and different mobility solutions and not
just with MIP (if ct is to be an augmentation of MIP, fine, let Pat rewrite
the charter and those of use who need to work on non-MIP ct can move on).

Clearly, from the discussion that has transpired, if we all really believe
that defining an "event" for reactive mode in the requirements draft is key
to making ct work, then we should define what a handover is. As everyone
knows by now, I do not believe it is required by for the requirement document,
and even more important, I suspect that a general definition of handover
will take a long time to work out. However, if the wg believes it is needed,
then let's make the valiant attempt.

Regards,
Gary


> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Wednesday, June 27, 2001 8:28 PM
> To: Pat Calhoun
> Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
> Pat Calhoun wrote:
>
> > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote:
> > > > >
> > > > > Rajeev: I guess the point is that you would do CT either
> > > > >
> > > > > 1. before the new AR becomes the MN's default router, or
> > > > > 2. after the new AR becomes the MN's default router
> > > > >
> > > > > Both 1) and 2) are related to handover.
> > > >
> > > >
> > >
> > > The point of above text was to indicate that defining
> context transfer to be
> > > independent of handover is perhaps not sensible. Getting
> it to work with
> > > handovers is the challenge we are peddling.
> > > If we all agree on this, may be we should try to close the issue ?
> >
> > The issue I have is that the current definitions use some
> random packet destined
> > for the mobile as the timing "event". This, im my mind,
> makes no sense whatsoever,
> > because one side (oAR) may not know when the packet shows
> up, and therefore it
> > has no idea whether a reactive or proactive CT is to be invoked.
> >
> > FWIW, some CTs will transfer L2 session keys used for
> authentication and
> > encryption, so this is where the first packet doesn't make sense.
> >
> >
>
> Rajeev: But the above text (and the text Kulwinder sent
> today) does not say anything
> about the "first" packet. It is based on whether CT is
> initiated when the new AR is
> (not) the default router.
>
> -Rajeev
>
>
> > PatC
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
>
>

------_=_NextPart_001_01C0FFD9.BDB3B0B0-- From owner-seamoby@diameter.org Thu Jun 28 10:02: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 KAA22409 for ; Thu, 28 Jun 2001 10:02:30 -0400 (EDT) Received: (qmail 1001 invoked by alias); 28 Jun 2001 13:46:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 991 invoked by uid 200); 28 Jun 2001 13:46:00 -0000 Received: (qmail 981 invoked by uid 500); 28 Jun 2001 13:45:58 -0000 Date: Thu, 28 Jun 2001 06:45:58 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010628064558.L22915@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org References: <01D91AFB08B6D211BFD00008C7EABAE10680B1FC@eseis04nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680B1FC@eseis04nok>; from john.loughney@nokia.com on Thu, Jun 28, 2001 at 04:50:04PM +0300 Sender: owner-seamoby@diameter.org Precedence: bulk > Define "handoff". I believe that what we mean by handoff is the event which an AR receives that causes it to start providing service to a mobile. This could be a L2 event, either from the oldAR or the MN (IS-41 handoff message and 802.11 associate, respectively), or via an L3 message (BU). PatC From owner-seamoby@diameter.org Thu Jun 28 10:05: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 KAA24282 for ; Thu, 28 Jun 2001 10:05:05 -0400 (EDT) Received: (qmail 1113 invoked by alias); 28 Jun 2001 13:47:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1106 invoked by uid 200); 28 Jun 2001 13:47:10 -0000 Received: (qmail 1094 invoked from network); 28 Jun 2001 13:47:05 -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; 28 Jun 2001 13:47:05 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SDve004600 for ; Thu, 28 Jun 2001 09:57:40 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 09:57:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 09:57:10 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DAA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" , Rajeev Koodli , Kulwinder Atwal Cc: "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 09:57:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFDA.3AC9A1E0" 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_01C0FFDA.3AC9A1E0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Thursday, June 28, 2001 3:13 AM > To: Rajeev Koodli; Kulwinder Atwal > Cc: 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > *snip* > > Anyway, the definitions chosen should not preclude sensible > understanding > of this scenario Yes! The nomenclature is not the issue (nomenclature is an issue for the terminology draft), the issue is whether there is a shared understanding of what's going on, and whether that concept allows for all the various scenarios each of us wishes to find solutions for. Gary > > Regards, > Charlie P. > > > ------_=_NextPart_001_01C0FFDA.3AC9A1E0 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@IPRG.nokia.com]
> Sent: Thursday, June 28, 2001 3:13 AM
> To: Rajeev Koodli; Kulwinder Atwal
> Cc: 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>

*snip*

>
> Anyway, the definitions chosen should not preclude sensible
> understanding
> of this scenario

Yes! The nomenclature is not the issue (nomenclature is an issue for the
terminology draft), the issue is whether there is a shared understanding
of what's going on, and whether that concept allows for all the various
scenarios each of us wishes to find solutions for.

Gary

>
> Regards,
> Charlie P.
>
>
>

------_=_NextPart_001_01C0FFDA.3AC9A1E0-- From owner-seamoby@diameter.org Thu Jun 28 10:08: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 KAA26910 for ; Thu, 28 Jun 2001 10:08:50 -0400 (EDT) Received: (qmail 1328 invoked by alias); 28 Jun 2001 13:50:00 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1322 invoked by uid 200); 28 Jun 2001 13:50:00 -0000 Received: (qmail 1313 invoked from network); 28 Jun 2001 13:49:55 -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; 28 Jun 2001 13:49:55 -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 f5SE0U005160 for ; Thu, 28 Jun 2001 10:00:30 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 28 Jun 2001 10:00:16 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:00:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DAB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Pat Calhoun'" Cc: "'seamoby'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 10:00:11 -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 No, it is not preferred. Not because it is better/worse, but simply because it is based upon concepts that are at least just as ambiguous as the previous definitions (which are ambiguous on purpose, btw). Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 28, 2001 9:36 AM > To: Rajeev Koodli > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > initiated prior to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is > initiated after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > on how to proceed > > next? > > what do folks think about using this terminology? Is this > preferred over the > existing terminology in the draft? > > PatC > From owner-seamoby@diameter.org Thu Jun 28 10:11: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 KAA28802 for ; Thu, 28 Jun 2001 10:11:27 -0400 (EDT) Received: (qmail 2022 invoked by alias); 28 Jun 2001 13:53:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2014 invoked by uid 200); 28 Jun 2001 13:53:50 -0000 Received: (qmail 1983 invoked from network); 28 Jun 2001 13:53:44 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 13:53:44 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:04:33 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844555D@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Pat Calhoun'" , Rajeev Koodli Cc: Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Thu, 28 Jun 2001 10:04: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 Only if in-handoff context transfer is allowed as well. :-) > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 28, 2001 9:36 AM > To: Rajeev Koodli > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > initiated prior to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is > initiated after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > on how to proceed > > next? > > what do folks think about using this terminology? Is this > preferred over the > existing terminology in the draft? > > PatC > From owner-seamoby@diameter.org Thu Jun 28 10:34: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 KAA15142 for ; Thu, 28 Jun 2001 10:34:44 -0400 (EDT) Received: (qmail 3358 invoked by alias); 28 Jun 2001 14:22:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3351 invoked by uid 200); 28 Jun 2001 14:22:52 -0000 Received: (qmail 3346 invoked from network); 28 Jun 2001 14:22:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 14:22:50 -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 HAA01352; Thu, 28 Jun 2001 07:33:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SEXcg00637; Thu, 28 Jun 2001 07:33:38 -0700 X-mProtect: Thu, 28 Jun 2001 07:33:38 -0700 Nokia Silicon Valley Messaging Protection Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdviLbCe; Thu, 28 Jun 2001 07:33:36 PDT Message-ID: <3B3B401E.D0EB6F3C@iprg.nokia.com> Date: Thu, 28 Jun 2001 07:33:02 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Neumiller CC: "'Pat Calhoun'" , Rajeev Koodli , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <0DF9FBC42474A24CA50F7A27FB08E04844555D@meshpdc.meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit I find it confusing: it is counter-intuitive that a CT that completes a long time after the newAR becomes default router could still be called a pre-handoff CT. Pre-handoff initiated context transfer would not lead to this confusion (but it ain't as sexy as proactive for sure). Cedric. Phillip Neumiller wrote: > Only if in-handoff context transfer is allowed as well. :-) > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 28, 2001 9:36 AM > > To: Rajeev Koodli > > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > > Madjid-MNAKHJI1'; 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > > and re active CT definitions > > > > > > > > How is this: > > > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > initiated prior to the > > > > newAR becomes the MN's default router. > > > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > initiated after the > > > > newAR becomes the MN's default router. > > > > > > > > -Kulwinder. > > > > > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > > on how to proceed > > > next? > > > > what do folks think about using this terminology? Is this > > preferred over the > > existing terminology in the draft? > > > > PatC > > From owner-seamoby@diameter.org Thu Jun 28 10:54:34 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29159 for ; Thu, 28 Jun 2001 10:54:32 -0400 (EDT) Received: (qmail 3909 invoked by alias); 28 Jun 2001 14:41:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3903 invoked by uid 200); 28 Jun 2001 14:41:37 -0000 Received: (qmail 3898 invoked from network); 28 Jun 2001 14:41:35 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 14:41:35 -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 HAA02035; Thu, 28 Jun 2001 07:52:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SEqQu15394; Thu, 28 Jun 2001 07:52:26 -0700 X-mProtect: Thu, 28 Jun 2001 07:52:26 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin15.iprg.nokia.com (205.226.20.245, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdAXAl48; Thu, 28 Jun 2001 07:52:23 PDT Message-ID: <3B3B44D3.4A185472@iprg.nokia.com> Date: Thu, 28 Jun 2001 07:53:07 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Youngjune Lee Gwon CC: Emil Sturniolo , seamoby@diameter.org Subject: Re: [seamoby] Question on 4.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I do not understand why this scenario makes sense. In order for the layer-3 protocol to operate, there would need to be a previous access router and a new access router. Here there is none. Instead, we have a layer-2 trigger that should initiate a layer-2 context transfer. If that layer-2 context transfer is carried out by the access router, then that's fine, but I don't see why it needs to be the concern of the [seamoby] layer-3 context transfer protocol. Regards, Charlie P. Youngjune Lee Gwon wrote: > I sort of agree with Emil and let me give you an example I have thought > about. Consider the picture below to illustrate my point. > > | <--> +----+ ========= > [] # |AP 1|---------| AR 1 |-----+ > MN | +----+ / ========= | > | / | > | / | | > | / | ------- | > | / +--|ANG 1|---+ > | +----+ / | ------- | > V |AP 2|/ | | > +----+ | | > | | > > If a MN moves from AP1 to AP2, where both APs are connected to the same L3 > entity, AR1, there is no MIP process should be involved since the MN does > not change in terms of MIP. > > This puts the MN's mobility support, pretty much, relying completely on > the L2 technology of AP1 & AP2. My question is that what if AP1 and AP2 > does not support fast/smooth handoff at L2. Does this mean automatically > that the L3 communication during this move is disrupted, blacked out, or > discontinuous for a short time? In other words, the choice of the L2 > technology may be crucial for the outcomes at L3? > > In any cases, independently from the L2 capability, L3 can still be > seamless without interruptions. This can be possible if L3 is aware of > what events are occurred at L2. To certain degree, I agree L3 should also > be involved in movement matters by interacting with the lower layer. > > Maybe, this is not really the scope of SeaMoby or IETF since this case is > within a single L3 entity while switching only between L2 entities. > > Secondly, if AP1 and AP2 are running different access technolgoies, it > gets even more interesting because there is no clear definition of L2 > handoff. It may get to a problem where L3 is choosing one link from two > simultaneously available connections. User preference may also come in to > play in this case. > > I just recall that L2 trigger is a special case of this L2-L3 interaction. > At the same time, L2 trigger is a kind of L3-awaring mechanism about the > mobility of a MN itself. > > Any thoughts? Arguments? Objections? Let me know... > > Youngjune > > On Wed, 27 Jun 2001, Emil Sturniolo wrote: > > > Kulwinder. > > > > > James, > > > > > > ... snip... > > > >1. Fast movement detection/prediction > > > > > > Well, actually, I do disagree here. > > > > > > I believe the following view more accurately reflects > > > what is going on between L2 and L3 around handover. Basically, L3 > > > is not concerned with movement, it is concerned with routability > > > changes, L2 is concerned with movement. To be more specific, L3 is > > > only concerned with movement to the extent that a movement at L2 > > > causes > > > a change in routability that requires (for MIP) a change in CoA. If > > > movement > > > causes no change in routability, then L3 should not be involved. > > > ........ > > > > > > [Emil]. James, I'd like to add one scenario that might slightly > > change > > > the semantics, if it's within the scope of the conversation. Most of > > > this thread has been concern with the situation where connectivity > > at > > > L2 is constant and possibly predictive. However, it has been my > > > experience that this is not truly reflective of reality. IMHO L3 > > > should be involved if a mobile node becomes detached and then > > > reattached to the same network, even though no changes in > > routability > > > may have occurred. > > > > > L3 needs to be knowledgeable of this event to at > > > least verify routability and possibly facilitate faster recovery at > > > even higher levels in the protocol stack (slings and arrows > > welcome). > > > > I would say that L3 mobility is concerned about routability and not > > concerned with movement. > > If a router has mulitiple L2 interfaces then a change from one L2 > > interface > > to another will not affect L3. In this case, L2 can verify > > routability > > because it is still the same AR. > > > > If it is a different AR, then there is a change in routability, and a > > need > > to inform L3 mobility. > > > > Unless, there is another case that comes to mind. > > > > - Kulwinder. > > > > [Emil] Kulwinder, what I was trying to point out is that even though > > it is still the same AR it is still useful to signal L3 that > > connectivity has been re-established. Off the top of my head, > > depending on when and the length of time that the MN was disconnected, > > after L2 connectivity is reaffirmed, it may need to determine if its > > own addressibility is still valid Furthermore, as I said in my > > original note, this indication may also help facilitate recovery > > further up the stack. Maybe this is a different trigger that I am > > describing here, but it does seem to be consistent with > > acquisition/continuation of L2 connectivity. > > > > Cordially, > > Emil Sturniolo > > EmilS@NetMotionWireless.Com > > www.NetMotionWireless.com > > 330-723-9099 > > 330-461-0326 - Mobile/Voice Mail > > ===================== > > > > > > From owner-seamoby@diameter.org Thu Jun 28 11:59:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15933 for ; Thu, 28 Jun 2001 11:59:38 -0400 (EDT) Received: (qmail 4636 invoked by alias); 28 Jun 2001 15:47:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4630 invoked by uid 200); 28 Jun 2001 15:47:11 -0000 Received: (qmail 4625 invoked from network); 28 Jun 2001 15:47:10 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 15:47:10 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA20201 for ; Thu, 28 Jun 2001 08:58:31 -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 IAA04134 for ; Thu, 28 Jun 2001 08:58:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:58:26 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E28@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Rajeev Koodli Cc: Kulwinder Atwal , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Thu, 28 Jun 2001 10:58:21 -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 I don't like this one, I seem to be chasing a moving target (definition of reactive, proactive). Last week we were talking about whether to use link establishment or not, this week it is about default router. I started to like Charlie's definition based on link establishment, (however, we accepted that by link we are talking about L2) since L2 establishment is more crisp than completed handover. and we explored different cases, so we don't miss all the cases. The draft versus Charlie's definition of reactive/ proactive definitions in the two turned out to cover different set of scenarios without changing the outcome too much. I don't see how this new definition that pop up everyday are making the CT better. I am the newAR, How long do I have to wait until I make sure I am the default router, say in a FMIPv6 case: until I get the NA and make sure MN has a valid newCoA? What if the MN still has to use its oldCoA and a tunnel between newAR and oldAR, how long do I have to wait to start CT, this introduces unnecessary delay for CT. Another confusing thing is folks on the list keep using their own favorite words and definitions in the continuing conversations without paying attention what the other ends understanding of that word is, Lets finish off the link establishment discussion and if it is not good enough, see what is better, the way it is going I am not sure we are making a lot of progress in wrapping things up. Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 28, 2001 8:36 AM To: Rajeev Koodli Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org' Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions > > How is this: > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the > > newAR becomes the MN's default router. > > > > Post-Handoff Context Transfer: The Context Transfer is initiated after the > > newAR becomes the MN's default router. > > > > -Kulwinder. > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to proceed > next? what do folks think about using this terminology? Is this preferred over the existing terminology in the draft? PatC From owner-seamoby@diameter.org Thu Jun 28 12:03: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 MAA18996 for ; Thu, 28 Jun 2001 12:03:51 -0400 (EDT) Received: (qmail 5112 invoked by alias); 28 Jun 2001 15:51:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5106 invoked by uid 200); 28 Jun 2001 15:51:44 -0000 Received: (qmail 5098 invoked from network); 28 Jun 2001 15:51:42 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 15:51:42 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA19181 for ; Thu, 28 Jun 2001 09:03:04 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA08735 for ; Thu, 28 Jun 2001 08:56:08 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:03:03 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E29@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT Date: Thu, 28 Jun 2001 11:02: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 Pat, I see. Maybe then you want to make your point of packet size and "fast" context, a recommendation (May? rather than a requirement), I am not sure whether recommendations (without using May, should,...) can be included in a requirement document? Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, June 25, 2001 5:05 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Pat Calhoun'; seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT On Mon, Jun 25, 2001 at 02:02:33PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > Pat, > > I think this is a good idea. > I just have one question, since your text emphasizes on > the size of low priority packets. I can see that accounting > could include a lot of data, but why the emphasis that every > high priority context has small packet size and every low priority > context has large packet size? Isn't that a bit of generalization? yes it is. Perhaps packet size is the wrong thing to point out here, but my point is that packet construction, transmission, reception and parsing is much faster for small packets than larger packets (well, transmission and reception is in the noise, but you get my drift). So, things like L2 security info needs to be there REAL fast! PatC > > Madjid > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 21, 2001 5:37 PM > To: seamoby@cdma-2000.org > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > Issue 5: Support for multi-phase CT > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@eng.sun.com > Date first submitted: June 21,2001 > Reference: > Comment type: T > Priority: 1 > Section: 4.9 > > Rationale/Explanation of issue: > The current requirement in section 4.9 states that a CT can only > occur once all of the state has been gathered. The CT protocol > must allow for state to be transferred in phases, where the high > priority state (e.g. Header Compression, session keys) is sent > first, and low priority items are sent at a later time (e.g. > accounting information). > > This would reduce the size of the high priority CT packets, > lower the computational cost of processing the packet, and decrease > the handoff latency. > > Requested change: > Change 4.9 to state something like: > > "4.9 Context information MAY be transferred in phases, allowing for > higher priority state to be sent first, and lower priority > state to be sent at a later time. > > The total cost of processing a smaller packet with high priority > state is smaller, and would decrease any latency introduced by CT. Each > > CT profile would need to specify whether it is to be considered > as a high or low priority state." > > Proposal: > Adopt the text above in the -01 version of the requirements spec. From owner-seamoby@diameter.org Thu Jun 28 12:08:54 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22216 for ; Thu, 28 Jun 2001 12:08:53 -0400 (EDT) Received: (qmail 5482 invoked by alias); 28 Jun 2001 15:54:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5474 invoked by uid 200); 28 Jun 2001 15:54:13 -0000 Received: (qmail 5468 invoked from network); 28 Jun 2001 15:54:12 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 15:54:12 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA01473 for ; Thu, 28 Jun 2001 08:58:36 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA10817 for ; Thu, 28 Jun 2001 09:05:29 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:05:29 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E2A@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Pat Calhoun'" , Nakhjiri Madjid-MNAKHJI1 Cc: Kulwinder Atwal , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Thu, 28 Jun 2001 11:05:28 -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 Pat, Do you mean a separate profile for each of the technologies that you mentioned? I guess that would be too elaborate right now. I am sure such profiles will pop up in future drafs. Now if you are talking about a general abstract wireless tech. profile, maybe that is more fitting? Madjid -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, June 25, 2001 5:06 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Pat Calhoun'; Kulwinder Atwal; seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform On Mon, Jun 25, 2001 at 02:24:42PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote: > I prefer that we don't introduce explicit messaging, at least for now. > Defining a general CT trigger that each technology can map onto should be > good enough. > > I am with option 2. so if I understand correctly, perhaps a wireless technology profile would be useful (e.g. 802.11 profile, mip profile (for non-l2 signalling), cdma2000 profile) PatC > > Madjid > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, June 22, 2001 5:05 PM > To: Kulwinder Atwal > Cc: 'Pat Calhoun'; seamoby@cdma-2000.org > Subject: Re: [seamoby] Issue 2: Make IP messages uniform > > > On Fri, Jun 22, 2001 at 02:39:35AM -0400, Kulwinder Atwal wrote: > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, June 21, 2001 6:45 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] Issue 2: Make IP messages uniform > > > > > > > > > If I understand this particular issue properly, it is a > > > request for a layer 3 > > > message be created to initiate CT. However, I believe that > > > the mobility management > > > used already has messages that initiate L3 handoffs, and > > > these could be used > > > to initiate CT. > > > > > > So, we have two options: > > > 1. Create a message, which will introduce additional over the > > > air latency in > > > getting the CT initiated. > > > > The newAR will need to request CT from a peer AR. Are you suggesting that > > MIPv6 uses the Peer-to-Peer model such that the oldAR will hold the CoA? > > Or, is it quite possible that the CoA and the oldAR may not be co-located? > > > > Also, if the MN to AR link is 55 Mbps, as Charlie has suggested, for some > > technology do we really care about over the air latency for a few bytes? > > no, but look at option 2 below. My point is that there is already some > signalling, either at L2 (e.g. signal strength), or at L3 (binding update). > Why require another message, since we've already agreed to co-locate with > other MM protocols. > > > > > Of course some lower bandwidth technologies will use an L2 Trigger at the > > newAR, but the choice is really technology specific. > > right, so we allow for L2 or L3. The question is whether CT needs to define > another message, or if an existing one can be used. > > I much prefer the latter. > > > > > Further, I would hope that if the CoA were not co-located with the oldAR > > that some time could be saved by sending a change in route to the parent AR > > on the newAR-to-ParentAR link, while at the _same_ time sending a message to > > the oldAR on the oldAR-to-newAR link to transfer Context. > > > > Since time is very critical in Reactive Context Transfer it would seem like > > a very useful method to reduce latency. > > right, but I don't see how a CT L3 message would be faster, and therefore enable > reactive CT, than would a binding update. > > > Additionally, a MN message on a high bandwidth link could be forwarded by > > the currentAR to the oldAR to request CT, and at the _same_ time a MN > > message could be forwarded by the currentAR to the ParentAR to affect a > > route change. > > > > The route change message may travel to a different entity along a different > > link, than the Context Transfer request message. Having them happen in > > parrallel could significantly reduce Reactive Context Transfer. > > ok, this is the one and first argument that I've heard that could convince > me to agree to MN-initiated CT. > > PatC From owner-seamoby@diameter.org Thu Jun 28 12:21: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 MAA01368 for ; Thu, 28 Jun 2001 12:21:26 -0400 (EDT) Received: (qmail 6107 invoked by alias); 28 Jun 2001 16:08:23 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6102 invoked by uid 200); 28 Jun 2001 16:08:22 -0000 Received: (qmail 6094 invoked from network); 28 Jun 2001 16:08:20 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 16:08:20 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA11054 for ; Thu, 28 Jun 2001 09:19:43 -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 JAA07616 for ; Thu, 28 Jun 2001 09:19:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:19:42 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E2B@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Kulwinder Atwal Cc: "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: RE: [seamoby] Issue 2: Make IP messages uniform Date: Thu, 28 Jun 2001 11:19:25 -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 Exactly. As soon as the MN detects that it has undergone handover, it sends a message which includes BU as an encapsulation. The new AR sends the CT message towards the old AR and the BU towards the mobility agent. We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in Pittsburgh IETF). MN>> Rajeev, sorry I have not read the draft, so I am trying to see if I understand this. Could you define: "MN detects it has undergone handover", is it L2 signals from oldAR, PrRtAdv, L2 establishment at newAR? MN sends the BU to oldAR, right? How would newAR know about BU right then? Would It not make more sense if oldAR starts the CT messaging? Madjid From owner-seamoby@diameter.org Thu Jun 28 12:26: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 MAA05112 for ; Thu, 28 Jun 2001 12:26:39 -0400 (EDT) Received: (qmail 6589 invoked by alias); 28 Jun 2001 16:14:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6582 invoked by uid 200); 28 Jun 2001 16:14:50 -0000 Received: (qmail 6577 invoked from network); 28 Jun 2001 16:14:48 -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; 28 Jun 2001 16:14:48 -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 f5SGPM028008 for ; Thu, 28 Jun 2001 12:25:22 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 28 Jun 2001 12:25:10 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 12:25:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DAC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: [seamoby] proactive and reactive ct Date: Thu, 28 Jun 2001 12:25:10 -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 In a discussion with a colleague today, I came up with another view of what reactive ct is all about. I don't pretend that this will satisfy everyone's need for a better definition, but maybe it will help provoke some new thinking. Reactive CT occurs when the access network determines that the old AR can no longer support an MNs traffic, and that the potential candidates for handover of the MNs traffic have not been prepared with the appropriate context. Thus, the earliest initiating event for reactive CT would be the same event that initiates handover. This could be any number of L2/L3 events, depending upon the networking technology. Reactive CT completes when a new AR has the appropriate context to forward the MNs traffic. Ideally, reactive CT completes before or at the same time as the first packet from the MNs traffic is scheduled to be forwarded. Ideally, because in the real wireless world, the exception is the rule, and the packet may scheduled to be forwarded before the context is in place; in this case, the decision to forward the packet without the complete feature context is out of scope of ct. I would add that the completion event (and mitigating conditions) for Proactive CT is the same as for reactive CT. I do hope this helps. Gary From owner-seamoby@diameter.org Thu Jun 28 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 MAA07378 for ; Thu, 28 Jun 2001 12:29:50 -0400 (EDT) Received: (qmail 6872 invoked by alias); 28 Jun 2001 16:16:14 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6866 invoked by uid 200); 28 Jun 2001 16:16:13 -0000 Received: (qmail 6854 invoked from network); 28 Jun 2001 16:16:10 -0000 Received: from ftpbox.mot.com (129.188.136.101) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 16:16:10 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA27007 for ; Thu, 28 Jun 2001 09:27:33 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA29460 for ; Thu, 28 Jun 2001 09:20:37 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:27:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E2C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Kulwinder Atwal'" , Nakhjiri Madjid-MNAKHJI1 , "'Charles E. Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 11:27:32 -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: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com] Sent: Monday, June 25, 2001 11:03 PM To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Charles E. Perkins' Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, June 25, 2001 4:45 PM > To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins' > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Kulwinder, > So timing is important. > If you look at the archive, I have always said we are > better off removing timing requirements, if cannot come > up with something better than "timely" or "fast" there. > I think Charlie has brought up a lot of good points and > we are making good progress. Would it be impossible to wait for both Handover Complete and Context Transfer Complete before forwarding packets? MN>> It is not impossible, but is it the best we can do? First of all I am saying we could separate HO and CT from each other. You agree that L2 HO must be complete (we can get away with tunneling if L3 HO is not complete) for packet delivery, right? So you don't always have to wait for L3 HO completion for packet delivery. MN>>Second, some context might not be needed for packet delivery and some are needed, depending on how you design it. It would seem that a good design would need to ensure that both were present before forwarding packets. MN>> Yes, but you said yourself, we don't live in a perfect world. See my response above. If it is timing that you are concerned with maybe between 2 to 3 Round-Trip-Times would be a better measure of how soon Context Transfer and Handover need to complete. MN>> RTT is one of the concerns. limiting number of Round trips when you have long distances and low bandwidth might not be good enough. My goal (I think yours too) is increase the degree of parallelism between CT and HO. Madjid - Kulwinder. > > If you read my other emails, I said, I don't care what > you call reactive or proactive, as long as we cover > all the scenarios, I am fine. > > Madjid From owner-seamoby@diameter.org Thu Jun 28 12:33: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 MAA09919 for ; Thu, 28 Jun 2001 12:33:33 -0400 (EDT) Received: (qmail 7543 invoked by alias); 28 Jun 2001 16:21:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7537 invoked by uid 200); 28 Jun 2001 16:21:04 -0000 Received: (qmail 7529 invoked from network); 28 Jun 2001 16:21:01 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 16:21:01 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA22700 for ; Thu, 28 Jun 2001 09:32:21 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA03416 for ; Thu, 28 Jun 2001 09:25:25 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:32:21 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E2D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Cedric Westphal'" , Pat Calhoun Cc: Gary Kenward , seamoby@cdma-2000.org Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT Date: Thu, 28 Jun 2001 11:32:11 -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 Hi cedric, -----Original Message----- From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] Sent: Tuesday, June 26, 2001 9:35 AM To: Pat Calhoun Cc: Gary Kenward; seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT I agree with this (the support for multi-phase ct proposal) and would actually go one step further: requirement: a proactive transfer MUST be multiphasic (so that accounting transfer can be transfered after the handoff and config transfer before the handoff) a reactive transfer SHOULD be monophasic. MN>> I don't agree, I think it is actually more important to have a multiphasic CT for reactive than it is for proactive. If you had to wait for packet delivery until the end of CT (which I am not proposing) then You would loose more packets in reactive. Hence you should break CT into pieces. After sending the more urgent context, you could resume packet delivery and at the same time, take your time with less urgent context. and the distinction between proactive and reactive becomes one of a number of phases. MN>> yet another proactive/ reactive definition, please give us a break :) Madjid Cedric. Pat Calhoun wrote: > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote: > > I with you up until that last two paragraphs of the proposed new texts. > > The second to last paragraph is editorial, and presumes much about the > > context, > > the ctp design and the implementation. > > ok, I am certainly open to suggestions. > > > As for the last paragraph, I do not see the need to add priority to CTP. > > It is already required that the receiving AR process the context in the > > order received, and this yields the same result (priority can always be > > translated to a measurable performance criteria, such as "processed sooner" > > or "given more resources"). I do not see the utility of a "priority" bit. > > Perhaps you could > > elaborate? > > This isn't a question of a bit. It has to do with sending critical CT > information that is REQUIRED in order to deliver a single packet to the > mobile. This could include HC state, session keys, etc. This state info > is sent first when a handoff is occuring. > > Later (say, 1+ seconds later) additional state is sent. Although this > info is important, it may only be necessary when doing things such as > generating accounting messages, which are infrequent, and not required > during the handoff process. > > > Otherwise I have no problem with the additional requirement (although I > > wonder what an operator would say about "accounting" being "low priority" > > ;^}). > > :) > > PatC > > > > > Gary > > > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Thursday, June 21, 2001 6:37 PM > > > To: seamoby@cdma-2000.org > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > > > > > > > Issue 5: Support for multi-phase CT > > > > > > Submitter name: Pat Calhoun > > > Submitter email address: pcalhoun@eng.sun.com > > > Date first submitted: June 21,2001 > > > Reference: > > > Comment type: T > > > Priority: 1 > > > Section: 4.9 > > > > > > Rationale/Explanation of issue: > > > The current requirement in section 4.9 states that a CT can only > > > occur once all of the state has been gathered. The CT protocol > > > must allow for state to be transferred in phases, where the high > > > priority state (e.g. Header Compression, session keys) is sent > > > first, and low priority items are sent at a later time (e.g. > > > accounting information). > > > > > > This would reduce the size of the high priority CT packets, > > > lower the computational cost of processing the packet, > > > and decrease > > > the handoff latency. > > > > > > Requested change: > > > Change 4.9 to state something like: > > > > > > "4.9 Context information MAY be transferred in phases, > > > allowing for > > > higher priority state to be sent first, and lower priority > > > state to be sent at a later time. > > > > > > The total cost of processing a smaller packet with high priority > > > state is smaller, and would decrease any latency > > > introduced by CT. Each > > > CT profile would need to specify whether it is to be considered > > > as a high or low priority state." > > > > > > Proposal: > > > Adopt the text above in the -01 version of the > > > requirements spec. > > > From owner-seamoby@diameter.org Thu Jun 28 12:42: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 MAA15968 for ; Thu, 28 Jun 2001 12:42:04 -0400 (EDT) Received: (qmail 7787 invoked by alias); 28 Jun 2001 16:22:51 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7781 invoked by uid 200); 28 Jun 2001 16:22:51 -0000 Received: (qmail 7770 invoked from network); 28 Jun 2001 16:22:47 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 16:22:47 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA24011 for ; Thu, 28 Jun 2001 09:34:09 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA15064 for ; Thu, 28 Jun 2001 09:34:08 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:34:08 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E2E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , "'Charlie Perkins'" Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 11:34:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFF0.2695F690" 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_01C0FFF0.2695F690 Content-Type: text/plain; charset="iso-8859-1" Gary, Agreed. case 2 is reactive according to the draft and proactive according to Charlie's definition. I don't see too much difference in how that changes the concept, but Charlie's definition does make the definitions more clear. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, June 26, 2001 10:27 AM To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charlie Perkins' Cc: seamoby@cdma-2000.org Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Madjid, Charlie: Case two below that Madjid has outlined would be reactive, IMCO. Borrowing Madjid's numbers for a previous email, with an MN moving at 60 kph, being served by a 10Mpbs stream does not allow any time to be "proactive" between a possible event indicating the start of handover (there are many examples) and "link establishment) - the network must "react" quickly to transfer the context. This whole discussion seems to be focussed on pinning down reactive ct as a process triggered by a specific event. To me, the concepts border, if not lie directly in solution space. Certainly, I find the definition far too restrictive at this stage. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] > Sent: Monday, June 25, 2001 5:40 PM > To: 'Charlie Perkins'; Nakhjiri Madjid-MNAKHJI1 > Cc: seamoby@cdma-2000.org > Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and > re active CT definitions > > > Hello Charlie, > > > Seems like we have reached an agreement based on our common > interpretation of proactive case, please see below. I added > the 3 cases > again, just to make sure. I cut some of less important text. > > The previous email, that you asked about, is also attached, > the cases were > > , 1-CT trigger arrives before Handover trigger (what starts the > handover, it could be at oldAR, at newAR or at MN) and naturally > before link establishment. > > 2-CT trigger arrives after handover trigger, but before link layer > establishment with newAR. > > 3-CT trigger arrives after link layer establishment with newAR. > > If you agree that 1 and 2 are proactive and 3 is reactive, > then we are in agreement and you can change the definition > of proactive and reactive based on starting event (link establishment) > > I just don't want to have to wait for link establishment to > start CT. > > > > MN>> I agree, however, it is not very hard to change it, to say > > Packet arrival at newAR (since that is what matters for CT). > > Not having feature contexts might make the packet arrival defintion > > fuzzier if you don't know how to interprete packets. > > However, as I said you can replace packet arrival with an > > almost equivalent event (say another message that makes > packets arrive > > at newAR). > > Somehow, though, this seems to miss the point. For reactive, > the context transfer should be reacting to something -- say, the > arrival of a mobile node at the new access network. Whether > this arrival is determined by the transmission of a layer-3 > packet is important, yet necessarily comes after the arrival. > On the other hand, by protocol the only way we can detect > the arrival is by some packet being sent somewhere. > That's why I tried to make the definition in terms of the > _ability_ of the mobile node to send a packet. > > MN>>>> I agree with you. as I said if your proactive covers > the case where handover signaling has started but link is not > established but you still can start CT without waiting for > link establishment, then that is fine. > > I'm curious how a message could be delivered to enable packets, > when the message itself has to be the content of a packet. > This makes me think that we are using different definitions for > what a "packet" is supposed to be. For me it's a bag of bits, > and can be used at layer 2. > > > MN>>point was to define a deadline for CT to be complete, and > > basing everything on the starting event, does not provide any > > timing requirements for CT, unless you want to leave it open > > for now. > > I suggest that the starting event is the right way, and that > all of the > protocols involved have to be robust enough to work anyway if > something takes longer. We should just make it work as fast > as we can. > > MN>>>> Again see my comments above, I can see the benefit of > using the starting event for the definition over packet arrival > (that we had earlier), as long as you expand the proactive case. > > > > In Mobile IP, we defined 4 scenarios. They were very useful: > - Mobile initiated after departure > - Network initiated after departure > - Mobile initiated before departure > - Network initiated before departure > > MN>> Departure is a bit fuzzy here, does not tell you > what happens to the MN-oldAR or MN-newAR link. > Also whether Mobile initiates or network is not very > critical for CT. But I see that identifying scenarios > are important, and that is why I asked for event sequences > and some people took it the wrong way and interpreted > that I like to see CT and handover to happen in a sequential > manner. > > Context transfer can be sensible in all four of these cases. > > > > ****Unless you offer a clear event sequence and show > different Handover > > > stages and the need of packet delivery for various > feature context, > > > I don't think we can change our definition and base it on an start > > > event.***** > > > > I'm not sure if my example would be welcome, but here goes > > anyway: > > > > 1) Mobile node shows up at new access router (802.11, say) > > 2) Mobile node asks new access router to collect context > > from previous router. Mobile includes authentication data > > that can be checked by previous access router. > > 3) New access router sends request for context transfer to > > previous router. > > 4) Previous access router checks the authentication data, and > > upon approval delivers the requested context features > > 5) New access router installs the delivered context features, > > and (optionally) notifies the mobile node about the status. > > > > This is reactive, and it could be very valuable for certain > > kinds of context. > > > > MN>> what if the newAR receives notification about an iminent > > arrival before the MN actually arrives at the newAR. This is > > common in cellular! Which category does this fall into? > > Proactive? If your proactive includes this, then we are fine. > > By my understanding, this would be proactive; I am guessing that > the new access router receives context information as well as > the basic indication of the arrival of the mobile node. But that > amounts to an (important!) optimization. > > MN>> Then we are in agreement!!!! > > > MN>> Well, I said that since Rajeev was dismissing the > > possibility of having the context to handle packets in time. > > I agree not all systems/ scnearios could support proactive, but > > does that mean we exclude it? > > I definitely propose that we not exclude reactive context transfer. > > > MN>> My question was, don't you think CT should have timing > > requirements, so it introduces zero (proactive) or as little > > delay as possible. Don't take me wrong, I don't know enough > > about all the features to believe 100% in zero delay, but it > > is a scenario, that should be included. > > I think that context transfer should be optimized for the best > performance in time. I don't see how you can realistically put > absolute time bounds on the process, though. What would it > be? 30ms? 300ms? Shouldn't the same protocol work for > transferring video context as well as audio context (if there needed > to be such a thing)? > > MN>> I agree, absolute numbers don't make sense in a general > requirement document, I have always said that. > > Regards, > Madjid N. > > > ------_=_NextPart_001_01C0FFF0.2695F690 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions
Gary,
 
Agreed. case 2 is reactive according to the draft and proactive according
to Charlie's definition. I don't see too much difference in how that changes
the concept, but Charlie's definition does make the definitions more clear.
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, June 26, 2001 10:27 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charlie Perkins'
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

Madjid, Charlie:

Case two below that Madjid has outlined would be reactive, IMCO.
Borrowing Madjid's numbers for a previous email, with an MN moving at
60 kph, being served by a 10Mpbs stream does not allow any time to
be "proactive" between a possible event indicating the start of handover
(there are many examples) and "link establishment) - the network must "react" quickly to transfer the context.

This whole discussion seems to be focussed on pinning down reactive ct as a
process triggered by a specific event. To me, the concepts border, if not
lie directly in solution space. Certainly, I find the definition far
too restrictive at this stage.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Monday, June 25, 2001 5:40 PM
> To: 'Charlie Perkins'; Nakhjiri Madjid-MNAKHJI1
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and
> re active CT definitions
>
>
> Hello Charlie,
>
>
> Seems like we have reached an agreement based on our common
> interpretation of proactive case, please see below. I added
> the 3 cases
> again, just to make sure.  I cut some of less important text.
>
> The previous email, that you asked about, is also attached,
> the cases were
>
> , 1-CT trigger arrives before Handover trigger (what starts the
> handover, it could be at oldAR, at newAR or at MN) and naturally
> before link establishment.
>
> 2-CT trigger arrives after handover trigger, but before link layer
> establishment with newAR.
>
> 3-CT trigger arrives after link layer establishment with newAR.
>
> If you agree that 1 and 2 are proactive and 3 is reactive,
> then we are in agreement and you can change the definition
> of proactive and reactive based on starting event (link establishment)
>
> I just don't want to have to wait for link establishment to
> start CT.
>
>
> > MN>> I agree, however, it is not very hard to change it, to say
> > Packet arrival at newAR (since that is what matters for CT).
> > Not having feature contexts might make the packet arrival defintion
> > fuzzier if you don't know how to interprete packets.
> > However, as I said you can replace packet arrival with an
> > almost equivalent event (say another message that makes
> packets arrive
> > at newAR).
>
> Somehow, though, this seems to miss the point.  For reactive,
> the context transfer should be reacting to something -- say, the
> arrival of a mobile node at the new access network.  Whether
> this arrival is determined by the transmission of a layer-3
> packet is important, yet necessarily comes after the arrival.
> On the other hand, by protocol the only way we can detect
> the arrival is by some packet being sent somewhere.
> That's why I tried to make the definition in terms of the
> _ability_ of the mobile node to send a packet.
>
> MN>>>> I agree with you. as I said if your proactive covers
> the case where handover signaling has started but link is not
> established but you still can start CT without waiting for
> link establishment, then that is fine.
>
> I'm curious how a message could be delivered to enable packets,
> when the message itself has to be the content of a packet.
> This makes me think that we are using different definitions for
> what a "packet" is supposed to be.  For me it's a bag of bits,
> and can be used at layer 2.
>
> > MN>>point was to define a deadline for CT to be complete, and
> > basing everything on the starting event, does not provide any
> > timing requirements for CT, unless you want to leave it open
> > for now.
>
> I suggest that the starting event is the right way, and that
> all of the
> protocols involved have to be robust enough to work anyway if
> something takes longer.  We should just make it work as fast
> as we can.
>
> MN>>>> Again see my comments above, I can see the benefit of
> using the starting event for the definition over packet arrival
> (that we had earlier), as long as you expand the proactive case.
>
>
>
> In Mobile IP, we defined 4 scenarios.  They were very useful:
> - Mobile initiated after departure
> - Network initiated after departure
> - Mobile initiated before departure
> - Network initiated before departure
>
> MN>> Departure is a bit fuzzy here, does not tell you
> what happens to the MN-oldAR or MN-newAR link.
> Also whether Mobile initiates or network is not very
> critical for CT. But I see that identifying scenarios
> are important, and that is why I asked for event sequences
> and some people took it the wrong way and interpreted
> that I like to see CT and handover to happen in a sequential
> manner.
>
> Context transfer can be sensible in all four of these cases.
>
> > > ****Unless you offer a clear event sequence and show
> different Handover
> > > stages and the need of packet delivery for various
> feature context,
> > > I don't think we can change our definition and base it on an start
> > > event.*****
> >
> > I'm not sure if my example would be welcome, but here goes
> > anyway:
> >
> > 1) Mobile node shows up at new access router (802.11, say)
> > 2) Mobile node asks new access router to collect context
> >    from previous router.  Mobile includes authentication data
> >    that can be checked by previous access router.
> > 3) New access router sends request for context transfer to
> >    previous router.
> > 4) Previous access router checks the authentication data, and
> >    upon approval delivers the requested context features
> > 5) New access router installs the delivered context features,
> >    and (optionally) notifies the mobile node about the status.
> >
> > This is reactive, and it could be very valuable for certain
> > kinds of context.
> >
> > MN>> what if the newAR receives notification about an iminent
> > arrival before the MN actually arrives at the newAR. This is
> > common in cellular! Which category does this fall into?
> > Proactive? If your proactive includes this, then we are fine.
>
> By my understanding, this would be proactive; I am guessing that
> the new access router receives context information as well as
> the basic indication of the arrival of the mobile node.  But that
> amounts to an (important!) optimization.
>
> MN>> Then we are in agreement!!!!
>
> > MN>> Well, I said that since Rajeev was dismissing the
> > possibility of having the context to handle packets in time.
> > I agree not all systems/ scnearios could support proactive, but
> > does that mean we exclude it?
>
> I definitely propose that we not exclude reactive context transfer.
>
> > MN>> My question was, don't you think CT should have timing
> > requirements, so  it introduces zero (proactive) or as little
> > delay as possible. Don't take me wrong, I don't know enough
> > about all the features to believe 100% in zero delay, but it
> > is a scenario, that should be included.
>
> I think that context transfer should be optimized for the best
> performance in time.  I don't see how you can realistically put
> absolute time bounds on the process, though.  What would it
> be?  30ms?  300ms?  Shouldn't the same protocol work for
> transferring video context as well as audio context (if there needed
> to be such a thing)?
>
> MN>> I agree, absolute numbers don't make sense in a general
> requirement document, I have always said that.
>
> Regards,
> Madjid N.
>
>
>

------_=_NextPart_001_01C0FFF0.2695F690-- From owner-seamoby@diameter.org Thu Jun 28 13:18: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 NAA09599 for ; Thu, 28 Jun 2001 13:18:41 -0400 (EDT) Received: (qmail 8656 invoked by alias); 28 Jun 2001 17:05:32 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8650 invoked by uid 200); 28 Jun 2001 17:05:31 -0000 Received: (qmail 8645 invoked from network); 28 Jun 2001 17:05:29 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 17:05:29 -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 KAA12535; Thu, 28 Jun 2001 10:16:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SHGL703991; Thu, 28 Jun 2001 10:16:21 -0700 X-mProtect: Thu, 28 Jun 2001 10:16:21 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdSYqPC2; Thu, 28 Jun 2001 10:16:20 PDT Message-ID: <3B3B6665.57079E67@iprg.nokia.com> Date: Thu, 28 Jun 2001 10:16:21 -0700 From: Rajeev Koodli 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: Charlie Perkins CC: Kulwinder Atwal , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <6833D86F1B05CA4FBAB3C73DD98BD8B95F8088@NEPTUNE.zucotto.com> <3B3A77DC.FBAC9D92@iprg.nokia.com> <3B3AD915.B97629EC@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Charlie, Charlie Perkins wrote: > Hello folks, > > Rajeev Koodli wrote: > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is initiated after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to proceed > > next? > > >From this, I gather that the words "reactive" and "proactive" aren't going to be > used. > Although I didn't think of it, yes. > > Suppose a mobile node shows up, and detects a beacon from the > new access router (not at layer 3). Then it sends a signal to the router > to initiate handover and context transfer. System design dictates that > the new router becomes the default router as a consequence of installing > the context features. Is this a "pre-" or "post-" handover context transfer? > I would say that it happens _at the same time_ as handover, and > furthermore that it is reactive. > > This is a good example. What constitutes the new AR becoming the default AR for the MN is the key point. The above defintions assume IP router discovery mechanisms to determine whether new AR has become the MN's default AR. Can we conclude for all link types that you could discover the router via L2 beacons ? It is possible that you hear the new beacon but the AR has not really changed (e.g., when you change the AP but the AR is still the same). > Anyway, the definitions chosen should not preclude sensible understanding > of this scenario. > Agreed. Regards, -Rajeev > > Regards, > Charlie P. From owner-seamoby@diameter.org Thu Jun 28 13:25: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 NAA14943 for ; Thu, 28 Jun 2001 13:25:51 -0400 (EDT) Received: (qmail 9148 invoked by alias); 28 Jun 2001 17:11:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9142 invoked by uid 200); 28 Jun 2001 17:11:54 -0000 Received: (qmail 9137 invoked from network); 28 Jun 2001 17:11:53 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 17:11:53 -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 KAA13053; Thu, 28 Jun 2001 10:22:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SHMi314242; Thu, 28 Jun 2001 10:22:44 -0700 X-mProtect: Thu, 28 Jun 2001 10:22:44 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIfnI7d; Thu, 28 Jun 2001 10:22:43 PDT Message-ID: <3B3B67E3.15C1E057@iprg.nokia.com> Date: Thu, 28 Jun 2001 10:22:43 -0700 From: Rajeev Koodli 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: Phillip Neumiller CC: "'Pat Calhoun'" , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <0DF9FBC42474A24CA50F7A27FB08E04844555D@meshpdc.meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Phil, Phillip Neumiller wrote: > Only if in-handoff context transfer is allowed as well. :-) > Very much in sync. I guess the prefix "Pre" may not be complete in describing this case. However, the idea should be that any CT that takes place prior to the new AR becoming the MN's default AR would fall under this. Thus, the case you mention above also falls under this. Regards, -Rajeev > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 28, 2001 9:36 AM > > To: Rajeev Koodli > > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > > Madjid-MNAKHJI1'; 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > > and re active CT definitions > > > > > > > > How is this: > > > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > initiated prior to the > > > > newAR becomes the MN's default router. > > > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > initiated after the > > > > newAR becomes the MN's default router. > > > > > > > > -Kulwinder. > > > > > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > > on how to proceed > > > next? > > > > what do folks think about using this terminology? Is this > > preferred over the > > existing terminology in the draft? > > > > PatC > > From owner-seamoby@diameter.org Thu Jun 28 13:44: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 NAA28693 for ; Thu, 28 Jun 2001 13:44:36 -0400 (EDT) Received: (qmail 9710 invoked by alias); 28 Jun 2001 17:32:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9703 invoked by uid 200); 28 Jun 2001 17:32:22 -0000 Received: (qmail 9698 invoked from network); 28 Jun 2001 17:32:20 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 17:32:20 -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 KAA15979; Thu, 28 Jun 2001 10:43:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SHhDl18365; Thu, 28 Jun 2001 10:43:13 -0700 X-mProtect: Thu, 28 Jun 2001 10:43:13 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQUU2fw; Thu, 28 Jun 2001 10:43:11 PDT Message-ID: <3B3B6CAF.344CD1B9@iprg.nokia.com> Date: Thu, 28 Jun 2001 10:43:11 -0700 From: Rajeev Koodli 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: "'Pat Calhoun'" , Kulwinder Atwal , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9E28@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 madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > I don't like this one, I seem to be chasing a moving target (definition of > reactive, proactive). Last week we were talking about whether to use > link establishment or not, this week it is about default router. > > I started to like Charlie's definition based on link establishment, > (however, we accepted that by link we are talking about L2) > since L2 establishment is more crisp than completed handover. > and we explored different cases, so we don't miss all the cases. > The draft versus Charlie's definition of reactive/ proactive > definitions in the two turned out to cover different > set of scenarios without changing the outcome too much. > Rajeev: I have a question here. Is it possible that you can establish a new L2 and still not change your AR ? If yes, if you don't change AR, is there is still any CT ? Is this too naive ? It seems to me that the AR is the key entity (for our defintion) since that holds the feature contexts. > > I don't see how this new definition that pop up everyday are > making the CT better. > > I am the newAR, How long do I have to wait until I make sure > I am the default router, say in a FMIPv6 case: until I get > the NA and make sure MN has a valid newCoA? > What if the MN still has to use its oldCoA and a tunnel between > newAR and oldAR, how long do I have to wait to start CT, this > introduces unnecessary delay for CT. > Rajeev: There is IP router discovery that indicates to a node when some AR has become the default AR. Any CT that happens prior to this phase is "Pre"-something. This includes using L2 triggers etc. When none of this is possible, the MN realizes that it has changed its AR through router advertisements and does CT, which is "Post"-something. Sure there is delay here. It is a matter of classification, not debating performance. Anyway, let's see if we can resolve the previous question. Regards, -Rajeev > > Another confusing thing is folks on the list keep using their > own favorite words and definitions in the continuing conversations > without paying attention what the other ends understanding > of that word is, > > > Lets finish off the link establishment discussion and if it > is not good enough, see what is better, the way it is going > I am not sure we are making a lot of progress in wrapping > things up. > > Madjid > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 28, 2001 8:36 AM > To: Rajeev Koodli > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior to > the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is initiated after > the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on how to > proceed > > next? > > what do folks think about using this terminology? Is this preferred over the > existing terminology in the draft? > > PatC From owner-seamoby@diameter.org Thu Jun 28 14:02: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 OAA11570 for ; Thu, 28 Jun 2001 14:02:05 -0400 (EDT) Received: (qmail 10231 invoked by alias); 28 Jun 2001 17:49:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10223 invoked by uid 200); 28 Jun 2001 17:49:52 -0000 Received: (qmail 10218 invoked from network); 28 Jun 2001 17:49:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 17:49:50 -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 LAA17127; Thu, 28 Jun 2001 11:00:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SI0hr11874; Thu, 28 Jun 2001 11:00:43 -0700 X-mProtect: Thu, 28 Jun 2001 11:00:43 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdFQJMYv; Thu, 28 Jun 2001 11:00:41 PDT Message-ID: <3B3B70C8.B805C296@iprg.nokia.com> Date: Thu, 28 Jun 2001 11:00:41 -0700 From: Rajeev Koodli 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: Gary Kenward CC: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DA9@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Gary, Gary Kenward wrote: > > > To expand a bit on my previous question: what defines a "default > router" > in a mobile wireless access network? This is a similar issue to > defining > "what is a handoff or handover". > > Rajeev: There is standard IP router discovery that enables any node to determine its default router. See RFC 2461. > Before everyone starts talking MIP, be reminded that the charter (and > the > problem statement, and the requirements) state that ct should work > with > with different wireless networks and different mobility solutions and > not > just with MIP (if ct is to be an augmentation of MIP, fine, let Pat > rewrite > the charter and those of use who need to work on non-MIP ct can move > on). > Rajeev: router discovery is independent of MIP. > > Clearly, from the discussion that has transpired, if we all really > believe > that defining an "event" for reactive mode in the requirements draft > is key > to making ct work, then we should define what a handover is. As > everyone > knows by now, I do not believe it is required by for the requirement > document, > and even more important, I suspect that a general definition of > handover > will take a long time to work out. However, if the wg believes it is > needed, > then let's make the valiant attempt. > Rajeev: using "default AR" as the basis would not need such a defintion. Regards, -Rajeev > > Regards, > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 27, 2001 8:28 PM > > To: Pat Calhoun > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. > Perkins'; > > 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive > > and re active CT definitions > > > > > > Pat Calhoun wrote: > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > context transfer to be > > > > independent of handover is perhaps not sensible. Getting > > it to work with > > > > handovers is the challenge we are peddling. > > > > If we all agree on this, may be we should try to close the issue > ? > > > > > > The issue I have is that the current definitions use some > > random packet destined > > > for the mobile as the timing "event". This, im my mind, > > makes no sense whatsoever, > > > because one side (oAR) may not know when the packet shows > > up, and therefore it > > > has no idea whether a reactive or proactive CT is to be invoked. > > > > > > FWIW, some CTs will transfer L2 session keys used for > > authentication and > > > encryption, so this is where the first packet doesn't make sense. > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > today) does not say anything > > about the "first" packet. It is based on whether CT is > > initiated when the new AR is > > (not) the default router. > > > > -Rajeev > > > > > > > PatC > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 14:12: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 OAA18792 for ; Thu, 28 Jun 2001 14:12:15 -0400 (EDT) Received: (qmail 10746 invoked by alias); 28 Jun 2001 17:59:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10739 invoked by uid 200); 28 Jun 2001 17:59:40 -0000 Received: (qmail 10734 invoked from network); 28 Jun 2001 17:59:38 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 17:59:38 -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 LAA18136; Thu, 28 Jun 2001 11:10:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SIAVp26029; Thu, 28 Jun 2001 11:10:31 -0700 X-mProtect: Thu, 28 Jun 2001 11:10:31 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9zHwfk; Thu, 28 Jun 2001 11:10:29 PDT Message-ID: <3B3B7314.EE08E736@iprg.nokia.com> Date: Thu, 28 Jun 2001 11:10:28 -0700 From: Rajeev Koodli 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: Gary Kenward CC: Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DA8@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary, let me cut and paste some text from below. > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > 2. after the new AR becomes the MN's default router > > > > > When the MN determines that it has changed its default router, through router discovery, it has undergone IP handover. We need to focus on IP handover since changing the AR definitively constitutes performing CT. On the other hand, if you _only_ change the link, can you be sure that you will also change the AR ? -Rajeev Gary Kenward wrote: > > > Define "handoff". > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Wednesday, June 27, 2001 8:19 PM > > To: Kulwinder Atwal > > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'; > > > 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive > > and re active CT definitions > > > > > > Kulwinder Atwal wrote: > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining context > > > > transfer to be > > > > independent of handover is perhaps not sensible. Getting it > > > > to work with > > > > handovers is the challenge we are peddling. > > > > If we all agree on this, may be we should try to close the issue > ? > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > initiated prior to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > initiated after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on > > how to proceed > > next? > > > > Regards, > > > > -Rajeev > > > > > > > > > > > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > > > > start, exact > > > > > middle, or end of handover, or some special protocol event > > > > in the middle. > > > > > In a collision based wired, or a wireless network we can't > > > > be certain which > > > > > protocol packet will arrive first. > > > > > > > > > > Also, we all seem to agree that if pre-connection Context > > > > Transfer takes too > > > > > long due to the uncertain nature of wireless (End-user > > > > drives through a > > > > > tunnel), it is very likely that several post-connection > > > > events will pass > > > > > before the transfer is complete. > > > > > > > > > > So, we may start with the best of intentions with the > > > > intent of being early > > > > > enough to not affect the user experience, but events may > > > > overtake us such > > > > > that we find ourselves out of time. > > > > > > > > > > So, what do we do at that point in time? > > > > > > > > > > A particular technology may find it advantageous to do > > > > post-connection, if > > > > > the data is available, even after the user has experienced > > > > a distruption, > > > > > becuase the connection setup time will be longer than the > > > > post-connection > > > > > Context Transfer time. > > > > > > > > > > An other technology may find it advantageous to > > > > re-establish new context, > > > > > because the Context Transfer time (Round-Trip Times) are > > > > greater than new > > > > > connection setup. > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > It is up to the implementor to take into account > particular > > > > > > network and > > > > > > > inter-network characteristics and real-time flow > > > > > > requirements to determine > > > > > > > how early Pre-Connection Context Transfer needs to be done > > > > > > > to guarrantee > > > > > > > seamless. > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > In all cases that I > > > > > > > > know of, some > > > > > > > > signalling, either at L2 or L3, is used to register the > > > > > > > > mobile locally (or > > > > > > > > some signal strength measurements), but there is always > an > > > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > > > > > > > But, really why should we care where the request for > CT > > > > > > > > comes from if we are > > > > > > > > > going to process it just the same? > > > > > > > > > > > > > > > > > > The only thing that is important is that the > requesting > > > > > > > > entity recieve a > > > > > > > > > packet indicating the success or failure mode of the > CT > > > > > > operation. > > > > > > > > > > > > > > > > ditto. > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 14:32: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 OAA02909 for ; Thu, 28 Jun 2001 14:32:04 -0400 (EDT) Received: (qmail 11782 invoked by alias); 28 Jun 2001 18:19:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11776 invoked by uid 200); 28 Jun 2001 18:19:24 -0000 Received: (qmail 11771 invoked from network); 28 Jun 2001 18:19:22 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 18:19:22 -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 LAA19480; Thu, 28 Jun 2001 11:30:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SIUEE20202; Thu, 28 Jun 2001 11:30:14 -0700 X-mProtect: Thu, 28 Jun 2001 11:30:14 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdFjpB5S; Thu, 28 Jun 2001 11:30:12 PDT Message-ID: <3B3B77B5.EFC49A71@iprg.nokia.com> Date: Thu, 28 Jun 2001 11:30:13 -0700 From: Rajeev Koodli 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: Gary Kenward CC: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DAE@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > And that "standard router discovery" works for mobile access? I don't know what you mean, but, if it is in a standards track RFC, I "guess" it (router discovery) should work for whatever access. We know it does and provides a standard reference for us. Given the different pictures we all have, this is perhaps the best we have as a reference point. -Rajeev > > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Thursday, June 28, 2001 2:01 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive > > and re active CT definitions > > > > > > > > Hello Gary, > > > > Gary Kenward wrote: > > > > > > > > > > > To expand a bit on my previous question: what defines a "default > > > router" > > > in a mobile wireless access network? This is a similar issue to > > > defining > > > "what is a handoff or handover". > > > > > > > > > > Rajeev: There is standard IP router discovery that enables any node > to > > determine its default router. See RFC 2461. > > > > > > > Before everyone starts talking MIP, be reminded that the > > charter (and > > > the > > > problem statement, and the requirements) state that ct should work > > > > with > > > with different wireless networks and different mobility > > solutions and > > > not > > > just with MIP (if ct is to be an augmentation of MIP, fine, let > Pat > > > rewrite > > > the charter and those of use who need to work on non-MIP ct can > move > > > on). > > > > > > > Rajeev: router discovery is independent of MIP. > > > > > > > > Clearly, from the discussion that has transpired, if we all really > > > > believe > > > that defining an "event" for reactive mode in the requirements > draft > > > is key > > > to making ct work, then we should define what a handover is. As > > > everyone > > > knows by now, I do not believe it is required by for the > requirement > > > document, > > > and even more important, I suspect that a general definition of > > > handover > > > will take a long time to work out. However, if the wg believes it > is > > > needed, > > > then let's make the valiant attempt. > > > > > > > Rajeev: using "default AR" as the basis would not need such a > > defintion. > > > > Regards, > > > > -Rajeev > > > > > > > > > > Regards, > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 27, 2001 8:28 PM > > > > To: Pat Calhoun > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. > > > Perkins'; > > > > 'seamoby@cdma-2000.org' > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > proactive > > > > and re active CT definitions > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > > context transfer to be > > > > > > independent of handover is perhaps not sensible. Getting > > > > it to work with > > > > > > handovers is the challenge we are peddling. > > > > > > If we all agree on this, may be we should try to > > close the issue > > > ? > > > > > > > > > > The issue I have is that the current definitions use some > > > > random packet destined > > > > > for the mobile as the timing "event". This, im my mind, > > > > makes no sense whatsoever, > > > > > because one side (oAR) may not know when the packet shows > > > > up, and therefore it > > > > > has no idea whether a reactive or proactive CT is to be > invoked. > > > > > > > > > > FWIW, some CTs will transfer L2 session keys used for > > > > authentication and > > > > > encryption, so this is where the first packet doesn't > > make sense. > > > > > > > > > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > > > today) does not say anything > > > > about the "first" packet. It is based on whether CT is > > > > initiated when the new AR is > > > > (not) the default router. > > > > > > > > -Rajeev > > > > > > > > > > > > > PatC > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 14:38: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 OAA07566 for ; Thu, 28 Jun 2001 14:38:33 -0400 (EDT) Received: (qmail 10929 invoked by alias); 28 Jun 2001 18:00:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 10922 invoked by uid 200); 28 Jun 2001 18:00:54 -0000 Received: (qmail 10911 invoked from network); 28 Jun 2001 18:00:50 -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; 28 Jun 2001 18:00:50 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SIBO013334 for ; Thu, 28 Jun 2001 14:11:24 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 14:11:22 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 14:11:25 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DAE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 14:11:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFFD.BDCF1D90" 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_01C0FFFD.BDCF1D90 Content-Type: text/plain; charset="iso-8859-1" And that "standard router discovery" works for mobile access? Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Thursday, June 28, 2001 2:01 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > Hello Gary, > > Gary Kenward wrote: > > > > > > > To expand a bit on my previous question: what defines a "default > > router" > > in a mobile wireless access network? This is a similar issue to > > defining > > "what is a handoff or handover". > > > > > > Rajeev: There is standard IP router discovery that enables any node to > determine its default router. See RFC 2461. > > > > Before everyone starts talking MIP, be reminded that the > charter (and > > the > > problem statement, and the requirements) state that ct should work > > with > > with different wireless networks and different mobility > solutions and > > not > > just with MIP (if ct is to be an augmentation of MIP, fine, let Pat > > rewrite > > the charter and those of use who need to work on non-MIP ct can move > > on). > > > > Rajeev: router discovery is independent of MIP. > > > > > Clearly, from the discussion that has transpired, if we all really > > believe > > that defining an "event" for reactive mode in the requirements draft > > is key > > to making ct work, then we should define what a handover is. As > > everyone > > knows by now, I do not believe it is required by for the requirement > > document, > > and even more important, I suspect that a general definition of > > handover > > will take a long time to work out. However, if the wg believes it is > > needed, > > then let's make the valiant attempt. > > > > Rajeev: using "default AR" as the basis would not need such a > defintion. > > Regards, > > -Rajeev > > > > > > Regards, > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Wednesday, June 27, 2001 8:28 PM > > > To: Pat Calhoun > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. > > Perkins'; > > > 'seamoby@cdma-2000.org' > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > proactive > > > and re active CT definitions > > > > > > > > > Pat Calhoun wrote: > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote: > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > context transfer to be > > > > > independent of handover is perhaps not sensible. Getting > > > it to work with > > > > > handovers is the challenge we are peddling. > > > > > If we all agree on this, may be we should try to > close the issue > > ? > > > > > > > > The issue I have is that the current definitions use some > > > random packet destined > > > > for the mobile as the timing "event". This, im my mind, > > > makes no sense whatsoever, > > > > because one side (oAR) may not know when the packet shows > > > up, and therefore it > > > > has no idea whether a reactive or proactive CT is to be invoked. > > > > > > > > FWIW, some CTs will transfer L2 session keys used for > > > authentication and > > > > encryption, so this is where the first packet doesn't > make sense. > > > > > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > > today) does not say anything > > > about the "first" packet. It is based on whether CT is > > > initiated when the new AR is > > > (not) the default router. > > > > > > -Rajeev > > > > > > > > > > PatC > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C0FFFD.BDCF1D90 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

And that "standard router discovery" works for mobile access?

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Thursday, June 28, 2001 2:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
>
> Hello Gary,
>
> Gary Kenward wrote:
>
> >
> >
> > To expand a bit on my previous question: what defines a "default
> > router"
> > in a mobile wireless access network? This is a similar issue to
> > defining
> > "what is a handoff or handover".
> >
> >
>
> Rajeev: There is standard IP router discovery that enables any node to
> determine its default router. See RFC 2461.
>
>
> > Before everyone starts talking MIP, be reminded that the
> charter (and
> > the
> > problem statement, and the requirements) state that ct should work
> > with
> > with different wireless networks and different mobility
> solutions and
> > not
> > just with MIP (if ct is to be an augmentation of MIP, fine, let Pat
> > rewrite
> > the charter and those of use who need to work on non-MIP ct can move
> > on).
> >
>
> Rajeev: router discovery is independent of MIP.
>
> >
> > Clearly, from the discussion that has transpired, if we all really
> > believe
> > that defining an "event" for reactive mode in the requirements draft
> > is key
> > to making ct work, then we should define what a handover is. As
> > everyone
> > knows by now, I do not believe it is required by for the requirement
> > document,
> > and even more important, I suspect that a general definition of
> > handover
> > will take a long time to work out. However, if the wg believes it is
> > needed,
> > then let's make the valiant attempt.
> >
>
> Rajeev: using "default AR" as the basis would not need such a
> defintion.
>
> Regards,
>
> -Rajeev
>
>
> >
> > Regards,
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> > > Sent: Wednesday, June 27, 2001 8:28 PM
> > > To: Pat Calhoun
> > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E.
> > Perkins';
> > > 'seamoby@cdma-2000.org'
> > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > proactive
> > > and re active CT definitions
> > >
> > >
> > > Pat Calhoun wrote:
> > >
> > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev Koodli wrote:
> > > > > > >
> > > > > > > Rajeev: I guess the point is that you would do CT either
> > > > > > >
> > > > > > > 1. before the new AR becomes the MN's default router, or
> > > > > > > 2. after the new AR becomes the MN's default router
> > > > > > >
> > > > > > > Both 1) and 2) are related to handover.
> > > > > >
> > > > > >
> > > > >
> > > > > The point of above text was to indicate that defining
> > > context transfer to be
> > > > > independent of handover is perhaps not sensible. Getting
> > > it to work with
> > > > > handovers is the challenge we are peddling.
> > > > > If we all agree on this, may be we should try to
> close the issue
> > ?
> > > >
> > > > The issue I have is that the current definitions use some
> > > random packet destined
> > > > for the mobile as the timing "event". This, im my mind,
> > > makes no sense whatsoever,
> > > > because one side (oAR) may not know when the packet shows
> > > up, and therefore it
> > > > has no idea whether a reactive or proactive CT is to be invoked.
> > > >
> > > > FWIW, some CTs will transfer L2 session keys used for
> > > authentication and
> > > > encryption, so this is where the first packet doesn't
> make sense.
> > > >
> > > >
> > >
> > > Rajeev: But the above text (and the text Kulwinder sent
> > > today) does not say anything
> > > about the "first" packet. It is based on whether CT is
> > > initiated when the new AR is
> > > (not) the default router.
> > >
> > > -Rajeev
> > >
> > >
> > > > PatC
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C0FFFD.BDCF1D90-- From owner-seamoby@diameter.org Thu Jun 28 14:48: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 OAA13615 for ; Thu, 28 Jun 2001 14:48:03 -0400 (EDT) Received: (qmail 12343 invoked by alias); 28 Jun 2001 18:31:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12337 invoked by uid 200); 28 Jun 2001 18:31:40 -0000 Received: (qmail 12329 invoked from network); 28 Jun 2001 18:31:38 -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; 28 Jun 2001 18:31:38 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SIgH017391 for ; Thu, 28 Jun 2001 14:42:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 14:42:10 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 14:42:13 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DAF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 14:42:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10002.0C15E2A0" 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_01C10002.0C15E2A0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: I agree with the logic concerning changing links versus changing handovers. I am somewhat perplexed about the use of the router discovery protocol in a handover situations. Adding more over the air round trips to complete a handover doesn't sound very seamless to me. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Thursday, June 28, 2001 2:10 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > Gary, > > let me cut and paste some text from below. > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > When the MN determines that it has changed its default router, through > router discovery, it has undergone IP handover. We need to focus on > IP handover since changing the AR definitively constitutes performing > CT. On the other hand, if you _only_ change the link, can you be sure > that you will also change the AR ? > > -Rajeev > > Gary Kenward wrote: > > > > > > > Define "handoff". > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Wednesday, June 27, 2001 8:19 PM > > > To: Kulwinder Atwal > > > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; > > > > > 'seamoby@cdma-2000.org' > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > proactive > > > and re active CT definitions > > > > > > > > > Kulwinder Atwal wrote: > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining context > > > > > transfer to be > > > > > independent of handover is perhaps not sensible. Getting it > > > > > to work with > > > > > handovers is the challenge we are peddling. > > > > > If we all agree on this, may be we should try to > close the issue > > ? > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > How is this: > > > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > > initiated prior to the > > > > newAR becomes the MN's default router. > > > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > > initiated after the > > > > newAR becomes the MN's default router. > > > > > > > > -Kulwinder. > > > > > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on > > > how to proceed > > > next? > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > > > > > start, exact > > > > > > middle, or end of handover, or some special protocol event > > > > > in the middle. > > > > > > In a collision based wired, or a wireless network we can't > > > > > be certain which > > > > > > protocol packet will arrive first. > > > > > > > > > > > > Also, we all seem to agree that if pre-connection Context > > > > > Transfer takes too > > > > > > long due to the uncertain nature of wireless (End-user > > > > > drives through a > > > > > > tunnel), it is very likely that several post-connection > > > > > events will pass > > > > > > before the transfer is complete. > > > > > > > > > > > > So, we may start with the best of intentions with the > > > > > intent of being early > > > > > > enough to not affect the user experience, but events may > > > > > overtake us such > > > > > > that we find ourselves out of time. > > > > > > > > > > > > So, what do we do at that point in time? > > > > > > > > > > > > A particular technology may find it advantageous to do > > > > > post-connection, if > > > > > > the data is available, even after the user has experienced > > > > > a distruption, > > > > > > becuase the connection setup time will be longer than the > > > > > post-connection > > > > > > Context Transfer time. > > > > > > > > > > > > An other technology may find it advantageous to > > > > > re-establish new context, > > > > > > because the Context Transfer time (Round-Trip Times) are > > > > > greater than new > > > > > > connection setup. > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > It is up to the implementor to take into account > > particular > > > > > > > network and > > > > > > > > inter-network characteristics and real-time flow > > > > > > > requirements to determine > > > > > > > > how early Pre-Connection Context Transfer needs > to be done > > > > > > > > > to guarrantee > > > > > > > > seamless. > > > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > In all cases that I > > > > > > > > > know of, some > > > > > > > > > signalling, either at L2 or L3, is used to > register the > > > > > > > > > mobile locally (or > > > > > > > > > some signal strength measurements), but there > is always > > an > > > > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > But, really why should we care where the request for > > CT > > > > > > > > > comes from if we are > > > > > > > > > > going to process it just the same? > > > > > > > > > > > > > > > > > > > > The only thing that is important is that the > > requesting > > > > > > > > > entity recieve a > > > > > > > > > > packet indicating the success or failure mode of the > > CT > > > > > > > operation. > > > > > > > > > > > > > > > > > > ditto. > > > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C10002.0C15E2A0 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

Rajeev:
I agree with the logic concerning changing links versus changing handovers.
I am somewhat perplexed about the use of the router discovery protocol
in a handover situations. Adding more over the air round trips to complete
a handover doesn't sound very seamless to me.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Thursday, June 28, 2001 2:10 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri
> Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
>
> Gary,
>
> let me cut and paste some text from below.
>
> > > > > > Rajeev: I guess the point is that you would do CT either
> > > > > >
> > > > > > 1. before the new AR becomes the MN's default router, or
> > > > > > 2. after the new AR becomes the MN's default router
> > > > > >
>
> When the MN determines that it has changed its default router, through
> router discovery, it has undergone IP handover. We need to focus on
> IP handover since changing the AR definitively constitutes performing
> CT. On the other hand, if you _only_ change the link, can you be sure
> that you will also change the AR ?
>
> -Rajeev
>
> Gary Kenward wrote:
>
> >
> >
> > Define "handoff".
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> > > Sent: Wednesday, June 27, 2001 8:19 PM
> > > To: Kulwinder Atwal
> > > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> E. Perkins';
> >
> > > 'seamoby@cdma-2000.org'
> > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > proactive
> > > and re active CT definitions
> > >
> > >
> > > Kulwinder Atwal wrote:
> > >
> > > > > > >
> > > > > > > Rajeev: I guess the point is that you would do CT either
> > > > > > >
> > > > > > > 1. before the new AR becomes the MN's default router, or
> > > > > > > 2. after the new AR becomes the MN's default router
> > > > > > >
> > > > > > > Both 1) and 2) are related to handover.
> > > > > >
> > > > > >
> > > > >
> > > > > The point of above text was to indicate that defining context
> > > > > transfer to be
> > > > > independent of handover is perhaps not sensible. Getting it
> > > > > to work with
> > > > > handovers is the challenge we are peddling.
> > > > > If we all agree on this, may be we should try to
> close the issue
> > ?
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > >
> > > > How is this:
> > > >
> > > > Pre-Handoff Context Transfer: The Context Transfer is
> > > initiated prior to the
> > > > newAR becomes the MN's default router.
> > > >
> > > > Post-Handoff Context Transfer:  The Context Transfer is
> > > initiated after the
> > > > newAR becomes the MN's default router.
> > > >
> > > > -Kulwinder.
> > > >
> > > >
> > >
> > > Rajeev: This would work for me.  May be we should ask PatC on
> > > how to proceed
> > > next?
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > > >
> > > > >
> > > > > > Yes, but handover is pretty vague. Like Gary said, is the
> > > > > start, exact
> > > > > > middle, or end of handover, or some special protocol event
> > > > > in the middle.
> > > > > > In a collision based wired, or a wireless network we can't
> > > > > be certain which
> > > > > > protocol packet will arrive first.
> > > > > >
> > > > > > Also, we all seem to agree that if pre-connection Context
> > > > > Transfer takes too
> > > > > > long due to the uncertain nature of wireless (End-user
> > > > > drives through a
> > > > > > tunnel), it is very likely that several post-connection
> > > > > events will pass
> > > > > > before the transfer is complete.
> > > > > >
> > > > > > So, we may start with the best of intentions with the
> > > > > intent of being early
> > > > > > enough to not affect the user experience, but events may
> > > > > overtake us such
> > > > > > that we find ourselves out of time.
> > > > > >
> > > > > > So, what do we do at that point in time?
> > > > > >
> > > > > > A particular technology may find it advantageous to do
> > > > > post-connection, if
> > > > > > the data is available, even after the user has experienced
> > > > > a distruption,
> > > > > > becuase the connection setup time will be longer than the
> > > > > post-connection
> > > > > > Context Transfer time.
> > > > > >
> > > > > > An other technology may find it advantageous to
> > > > > re-establish new context,
> > > > > > because the Context Transfer time (Round-Trip Times) are
> > > > > greater than new
> > > > > > connection setup.
> > > > > >
> > > > > > - Kulwinder.
> > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > -Rajeev
> > > > > > >
> > > > > > >
> > > > > > > > It is up to the implementor to take into account
> > particular
> > > > > > > network and
> > > > > > > > inter-network characteristics and real-time flow
> > > > > > > requirements to determine
> > > > > > > > how early Pre-Connection Context Transfer needs
> to be done
> >
> > > > > > > to guarrantee
> > > > > > > > seamless.
> > > > > > > >
> > > > > > > > - Kulwinder.
> > > > > > > >
> > > > > > > > > In all cases that I
> > > > > > > > > know of, some
> > > > > > > > > signalling, either at L2 or L3, is used to
> register the
> > > > > > > > > mobile locally (or
> > > > > > > > > some signal strength measurements), but there
> is always
> > an
> > > > > > > > > indication of handoff.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > But, really why should we care where the request for
> > CT
> > > > > > > > > comes from if we are
> > > > > > > > > > going to process it just the same?
> > > > > > > > > >
> > > > > > > > > > The only thing that is important is that the
> > requesting
> > > > > > > > > entity recieve a
> > > > > > > > > > packet indicating the success or failure mode of the
> > CT
> > > > > > > operation.
> > > > > > > > >
> > > > > > > > > ditto.
> > > > > > > > >
> > > > > > > > > PatC
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C10002.0C15E2A0-- From owner-seamoby@diameter.org Thu Jun 28 15:01: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 PAA23160 for ; Thu, 28 Jun 2001 15:00:42 -0400 (EDT) Received: (qmail 12856 invoked by alias); 28 Jun 2001 18:44:07 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12850 invoked by uid 200); 28 Jun 2001 18:44:07 -0000 Received: (qmail 12845 invoked from network); 28 Jun 2001 18:44:05 -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; 28 Jun 2001 18:44:05 -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 f5SIsh019585 for ; Thu, 28 Jun 2001 14:54:43 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 28 Jun 2001 14:54:48 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 14:54:52 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DB0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 14:54:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10003.D114AEA0" 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_01C10003.D114AEA0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: See my previous posting. I agree that you and I have very different pictures. For me, providing seamless handovers means eliminating as much signalling overhead as possible, particularly over the air, and doing as much as possible as early as possible. The latter includes reacting as soon as possible to an on-going handover as much as it means being proactive about possible handovers. MN triggers, router discovery, etc. don't fit my goal of providing no degradation to the user service. This difference of viewpoints is all ok, for we all love diversity in the Internet. But this also means that the definition of CT should not be limited, at very least, not limited so early in the design process, to exclusive trigger events when the potential of alternative approaches has not been explored. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Thursday, June 28, 2001 2:30 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Gary Kenward wrote: > > > > > > > And that "standard router discovery" works for mobile access? > > I don't know what you mean, but, if it is in a standards track RFC, I > "guess" it (router discovery) should work for whatever access. We know > it does and provides a standard reference for us. Given the different > pictures we all have, this is perhaps the best we have as a reference > point. > > -Rajeev > > > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Thursday, June 28, 2001 2:01 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > > 'Charles > > > E. Perkins'; 'seamoby@cdma-2000.org' > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > proactive > > > and re active CT definitions > > > > > > > > > > > > Hello Gary, > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > To expand a bit on my previous question: what defines a "default > > > > router" > > > > in a mobile wireless access network? This is a similar issue to > > > > defining > > > > "what is a handoff or handover". > > > > > > > > > > > > > > Rajeev: There is standard IP router discovery that > enables any node > > to > > > determine its default router. See RFC 2461. > > > > > > > > > > Before everyone starts talking MIP, be reminded that the > > > charter (and > > > > the > > > > problem statement, and the requirements) state that ct > should work > > > > > > with > > > > with different wireless networks and different mobility > > > solutions and > > > > not > > > > just with MIP (if ct is to be an augmentation of MIP, fine, let > > Pat > > > > rewrite > > > > the charter and those of use who need to work on non-MIP ct can > > move > > > > on). > > > > > > > > > > Rajeev: router discovery is independent of MIP. > > > > > > > > > > > Clearly, from the discussion that has transpired, if we > all really > > > > > > believe > > > > that defining an "event" for reactive mode in the requirements > > draft > > > > is key > > > > to making ct work, then we should define what a handover is. As > > > > everyone > > > > knows by now, I do not believe it is required by for the > > requirement > > > > document, > > > > and even more important, I suspect that a general definition of > > > > handover > > > > will take a long time to work out. However, if the wg > believes it > > is > > > > needed, > > > > then let's make the valiant attempt. > > > > > > > > > > Rajeev: using "default AR" as the basis would not need such a > > > defintion. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > Regards, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > Sent: Wednesday, June 27, 2001 8:28 PM > > > > > To: Pat Calhoun > > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. > > > > Perkins'; > > > > > 'seamoby@cdma-2000.org' > > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > > proactive > > > > > and re active CT definitions > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev > Koodli wrote: > > > > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would > do CT either > > > > > > > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default > router, or > > > > > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > > > context transfer to be > > > > > > > independent of handover is perhaps not sensible. Getting > > > > > it to work with > > > > > > > handovers is the challenge we are peddling. > > > > > > > If we all agree on this, may be we should try to > > > close the issue > > > > ? > > > > > > > > > > > > The issue I have is that the current definitions use some > > > > > random packet destined > > > > > > for the mobile as the timing "event". This, im my mind, > > > > > makes no sense whatsoever, > > > > > > because one side (oAR) may not know when the packet shows > > > > > up, and therefore it > > > > > > has no idea whether a reactive or proactive CT is to be > > invoked. > > > > > > > > > > > > FWIW, some CTs will transfer L2 session keys used for > > > > > authentication and > > > > > > encryption, so this is where the first packet doesn't > > > make sense. > > > > > > > > > > > > > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > > > > today) does not say anything > > > > > about the "first" packet. It is based on whether CT is > > > > > initiated when the new AR is > > > > > (not) the default router. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C10003.D114AEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [seamoby] CT trigger or CT completion? was: proactive = and re active CT definitions

Rajeev:

See my previous posting. I agree that you and I have = very different
pictures. For me, providing seamless handovers means = eliminating as much signalling overhead as possible, particularly over = the air, and doing as

much as possible as early as possible. The latter = includes reacting as soon
as possible to an on-going handover as much as it = means being proactive about
possible handovers.


MN triggers, router discovery, etc. don't fit my goal = of providing no degradation to the user service.

This difference of viewpoints is all ok, for we all = love diversity in the Internet. But this also means that the definition = of CT should not be limited, at very least, not limited so early in the = design process, to exclusive trigger events when the potential of = alternative approaches has not been explored.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]<= /FONT>
> Sent: Thursday, June 28, 2001 2:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri = Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT = completion? was: proactive
> and re active CT definitions
>
>
> Gary Kenward wrote:
>
> >
> >
> > And that "standard router = discovery" works for mobile access?
>
> I don't know what you mean, but, if it is in a = standards track RFC, I
> "guess" it (router discovery) should = work for whatever access. We know
> it does and provides a standard reference for = us. Given the different
> pictures we all have, this is perhaps the best = we have as a reference
> point.
>
> -Rajeev
>
>
> >
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> > > Sent: Thursday, June 28, 2001 2:01 = PM
> > > To: Kenward, Gary = [WDLN2:AN10:EXCH]
> > > Cc: Pat Calhoun; Kulwinder Atwal; = 'Nakhjiri Madjid-MNAKHJI1';
> > 'Charles
> > > E. Perkins'; = 'seamoby@cdma-2000.org'
> > > Subject: Re: FW: [seamoby] CT trigger = or CT completion? was:
> > proactive
> > > and re active CT definitions
> > >
> > >
> > >
> > > Hello Gary,
> > >
> > > Gary Kenward wrote:
> > >
> > > >
> > > >
> > > > To expand a bit on my previous = question: what defines a "default
> > > > router"
> > > > in a mobile wireless access = network? This is a similar issue to
> > > > defining
> > > > "what is a handoff or = handover".
> > > >
> > > >
> > >
> > > Rajeev: There is standard IP router = discovery that
> enables any node
> > to
> > > determine its default router. See RFC = 2461.
> > >
> > >
> > > > Before everyone starts talking = MIP, be reminded that the
> > > charter (and
> > > > the
> > > > problem statement, and the = requirements) state that ct
> should work
> >
> > > > with
> > > > with different wireless networks = and different mobility
> > > solutions and
> > > > not
> > > > just with MIP (if ct is to be an = augmentation of MIP, fine, let
> > Pat
> > > > rewrite
> > > > the charter and those of use who = need to work on non-MIP ct can
> > move
> > > > on).
> > > >
> > >
> > > Rajeev: router discovery is = independent of MIP.
> > >
> > > >
> > > > Clearly, from the discussion = that has transpired, if we
> all really
> >
> > > > believe
> > > > that defining an = "event" for reactive mode in the requirements
> > draft
> > > > is key
> > > > to making ct work, then we = should define what a handover is. As
> > > > everyone
> > > > knows by now, I do not believe = it is required by for the
> > requirement
> > > > document,
> > > > and even more important, I = suspect that a general definition of
> > > > handover
> > > > will take a long time to work = out. However, if the wg
> believes it
> > is
> > > > needed,
> > > > then let's make the valiant = attempt.
> > > >
> > >
> > > Rajeev: using "default AR" = as the basis would not need such a
> > > defintion.
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > Regards,
> > > > Gary
> > > >
> > > > > -----Original = Message-----
> > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]<= /FONT>
> > > > > Sent: Wednesday, June 27, = 2001 8:28 PM
> > > > > To: Pat Calhoun
> > > > > Cc: Kulwinder Atwal; = 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E.
> > > > Perkins';
> > > > > = 'seamoby@cdma-2000.org'
> > > > > Subject: Re: FW: [seamoby] = CT trigger or CT completion? was:
> > > > proactive
> > > > > and re active CT = definitions
> > > > >
> > > > >
> > > > > Pat Calhoun wrote:
> > > > >
> > > > > > On Tue, Jun 26, 2001 = at 04:16:37PM -0700, Rajeev
> Koodli wrote:
> >
> > > > > > > > >
> > > > > > > > > Rajeev: = I guess the point is that you would
> do CT either
> >
> > > > > > > > >
> > > > > > > > > 1. = before the new AR becomes the MN's default
> router, or
> >
> > > > > > > > > 2. = after the new AR becomes the MN's default router
> > > > > > > > >
> > > > > > > > > Both 1) = and 2) are related to handover.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > The point of = above text was to indicate that defining
> > > > > context transfer to = be
> > > > > > > independent of = handover is perhaps not sensible. Getting
> > > > > it to work with
> > > > > > > handovers is the = challenge we are peddling.
> > > > > > > If we all agree = on this, may be we should try to
> > > close the issue
> > > > ?
> > > > > >
> > > > > > The issue I have is = that the current definitions use some
> > > > > random packet = destined
> > > > > > for the mobile as the = timing "event". This, im my mind,
> > > > > makes no sense = whatsoever,
> > > > > > because one side (oAR) = may not know when the packet shows
> > > > > up, and therefore it
> > > > > > has no idea whether a = reactive or proactive CT is to be
> > invoked.
> > > > > >
> > > > > > FWIW, some CTs will = transfer L2 session keys used for
> > > > > authentication and
> > > > > > encryption, so this is = where the first packet doesn't
> > > make sense.
> > > > > >
> > > > > >
> > > > >
> > > > > Rajeev: But the above text = (and the text Kulwinder sent
> > > > > today) does not say = anything
> > > > > about the "first" = packet. It is based on whether CT is
> > > > > initiated when the new AR = is
> > > > > (not) the default = router.
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > > PatC
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > -Rajeev
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C10003.D114AEA0-- From owner-seamoby@diameter.org Thu Jun 28 15:41: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 PAA22002 for ; Thu, 28 Jun 2001 15:41:38 -0400 (EDT) Received: (qmail 13561 invoked by alias); 28 Jun 2001 19:28:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13555 invoked by uid 200); 28 Jun 2001 19:28:37 -0000 Received: (qmail 13550 invoked from network); 28 Jun 2001 19:28:35 -0000 Received: from hume.neobright.net (root@209.143.19.251) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 19:28:35 -0000 Received: from WRQ1-NorthCoast.bright.net (wrq1-northcoast.bright.net [209.143.22.124]) by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id PAA01402 for ; Thu, 28 Jun 2001 15:39:53 -0400 Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for ; Thu, 28 Jun 2001 15:38:17 -0400 From: "Emil Sturniolo" To: "Charlie Perkins" , "Youngjune Lee Gwon" Cc: Subject: RE: [seamoby] Question on 4.2 Date: Thu, 28 Jun 2001 15:38:14 -0400 Message-ID: <00e001c10009$df52b650$7c168fd1@wrq-nc1.wrq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <3B3B44D3.4A185472@iprg.nokia.com> X-MDaemon-Deliver-To: seamoby@diameter.org Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Charlie, My major concern when I posted the original note was in reaction to proposed motion across different L2 technologies but to the same AR without signaling. I was also concerned that no signaling was defined for the detached state. In either instance, having L3 be somewhat cognizant of these motion events can have dramatic positive effects even across the same technology. From my own experience, I have found that signaling as Youngjune suggests is helpful at L3. Suffice to say, traffic flow can be minimized by using this information intelligently and can be politely ignored when not. If we are going to go down the path of defining L2 triggers, I would like to see the definition meaningful to CT, but broad enough that it can be used by other L3 entities as well (hopefully not biting off more the I/we can chew). Cordially, Emil Sturniolo EmilS@NetMotionWireless.Com www.NetMotionWireless.com 330-723-9099 330-461-0326 - Mobile/Voice Mail ===================== -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Thursday, June 28, 2001 10:53 AM To: Youngjune Lee Gwon Cc: Emil Sturniolo; seamoby@diameter.org Subject: Re: [seamoby] Question on 4.2 Hello, I do not understand why this scenario makes sense. In order for the layer-3 protocol to operate, there would need to be a previous access router and a new access router. Here there is none. Instead, we have a layer-2 trigger that should initiate a layer-2 context transfer. If that layer-2 context transfer is carried out by the access router, then that's fine, but I don't see why it needs to be the concern of the [seamoby] layer-3 context transfer protocol. Regards, Charlie P. Youngjune Lee Gwon wrote: > I sort of agree with Emil and let me give you an example I have thought > about. Consider the picture below to illustrate my point. > > | <--> +----+ ========= > [] # |AP 1|---------| AR 1 |-----+ > MN | +----+ / ========= | > | / | > | / | | > | / | ------- | > | / +--|ANG 1|---+ > | +----+ / | ------- | > V |AP 2|/ | | > +----+ | | > | | > > If a MN moves from AP1 to AP2, where both APs are connected to the same L3 > entity, AR1, there is no MIP process should be involved since the MN does > not change in terms of MIP. > > This puts the MN's mobility support, pretty much, relying completely on > the L2 technology of AP1 & AP2. My question is that what if AP1 and AP2 > does not support fast/smooth handoff at L2. Does this mean automatically > that the L3 communication during this move is disrupted, blacked out, or > discontinuous for a short time? In other words, the choice of the L2 > technology may be crucial for the outcomes at L3? > > In any cases, independently from the L2 capability, L3 can still be > seamless without interruptions. This can be possible if L3 is aware of > what events are occurred at L2. To certain degree, I agree L3 should also > be involved in movement matters by interacting with the lower layer. > > Maybe, this is not really the scope of SeaMoby or IETF since this case is > within a single L3 entity while switching only between L2 entities. > > Secondly, if AP1 and AP2 are running different access technolgoies, it > gets even more interesting because there is no clear definition of L2 > handoff. It may get to a problem where L3 is choosing one link from two > simultaneously available connections. User preference may also come in to > play in this case. > > I just recall that L2 trigger is a special case of this L2-L3 interaction. > At the same time, L2 trigger is a kind of L3-awaring mechanism about the > mobility of a MN itself. > > Any thoughts? Arguments? Objections? Let me know... > > Youngjune > > On Wed, 27 Jun 2001, Emil Sturniolo wrote: > > > Kulwinder. > > > > > James, > > > > > > ... snip... > > > >1. Fast movement detection/prediction > > > > > > Well, actually, I do disagree here. > > > > > > I believe the following view more accurately reflects > > > what is going on between L2 and L3 around handover. Basically, L3 > > > is not concerned with movement, it is concerned with routability > > > changes, L2 is concerned with movement. To be more specific, L3 is > > > only concerned with movement to the extent that a movement at L2 > > > causes > > > a change in routability that requires (for MIP) a change in CoA. If > > > movement > > > causes no change in routability, then L3 should not be involved. > > > ........ > > > > > > [Emil]. James, I'd like to add one scenario that might slightly > > change > > > the semantics, if it's within the scope of the conversation. Most of > > > this thread has been concern with the situation where connectivity > > at > > > L2 is constant and possibly predictive. However, it has been my > > > experience that this is not truly reflective of reality. IMHO L3 > > > should be involved if a mobile node becomes detached and then > > > reattached to the same network, even though no changes in > > routability > > > may have occurred. > > > > > L3 needs to be knowledgeable of this event to at > > > least verify routability and possibly facilitate faster recovery at > > > even higher levels in the protocol stack (slings and arrows > > welcome). > > > > I would say that L3 mobility is concerned about routability and not > > concerned with movement. > > If a router has mulitiple L2 interfaces then a change from one L2 > > interface > > to another will not affect L3. In this case, L2 can verify > > routability > > because it is still the same AR. > > > > If it is a different AR, then there is a change in routability, and a > > need > > to inform L3 mobility. > > > > Unless, there is another case that comes to mind. > > > > - Kulwinder. > > > > [Emil] Kulwinder, what I was trying to point out is that even though > > it is still the same AR it is still useful to signal L3 that > > connectivity has been re-established. Off the top of my head, > > depending on when and the length of time that the MN was disconnected, > > after L2 connectivity is reaffirmed, it may need to determine if its > > own addressibility is still valid Furthermore, as I said in my > > original note, this indication may also help facilitate recovery > > further up the stack. Maybe this is a different trigger that I am > > describing here, but it does seem to be consistent with > > acquisition/continuation of L2 connectivity. > > > > Cordially, > > Emil Sturniolo > > EmilS@NetMotionWireless.Com > > www.NetMotionWireless.com > > 330-723-9099 > > 330-461-0326 - Mobile/Voice Mail > > ===================== > > > > > > From owner-seamoby@diameter.org Thu Jun 28 16:19: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 QAA18032 for ; Thu, 28 Jun 2001 16:18:59 -0400 (EDT) Received: (qmail 14225 invoked by alias); 28 Jun 2001 20:07:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14219 invoked by uid 200); 28 Jun 2001 20:07:02 -0000 Received: (qmail 14214 invoked from network); 28 Jun 2001 20:06:59 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 20:06:59 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA16137 for ; Thu, 28 Jun 2001 13:18:22 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA15813 for ; Thu, 28 Jun 2001 13:18:22 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 15:18:21 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E30@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'Pat Calhoun'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Thu, 28 Jun 2001 15:18:19 -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 Hi Rajeev, -Rajeev: I have a question here. Is it possible that you can establish a new L2 and still not change your AR ? If yes, if you don't change AR, is there is still any CT ? Is this too naive ? It seems to me that the AR is the key entity (for our defintion) since that holds the feature contexts. MN>>> But without broadening the scope of CT, lets assume that CT is AR1-AR2 (change of AR is part of the scenario) *So the discussion is what is difference between new-L2 establishment and change of default router. I say difference is the timing.* The case that comes to my mind, when you change L2 but newAR is still not your default router, is say: MN is at new L2, but did not have time to sent binding update to the oldAR before moving, so its using new L2 to start the L3 routing change procedure, it does not have newAR as default router but has L2 with newAR. The other case is, if it has obtained its new IP address through stateless autoconfiguration, but the new address is rejected by newAR, although MN has L2 with newAR. So you can base your proactive CT on *predictions* based on L2 information Do the proactive CT and manage to get your context over to newAR > > I don't see how this new definition that pop up everyday are > making the CT better. > > I am the newAR, How long do I have to wait until I make sure > I am the default router, say in a FMIPv6 case: until I get > the NA and make sure MN has a valid newCoA? > What if the MN still has to use its oldCoA and a tunnel between > newAR and oldAR, how long do I have to wait to start CT, this > introduces unnecessary delay for CT. > Rajeev: There is IP router discovery that indicates to a node when some AR has become the default AR. Any CT that happens prior to this phase is "Pre"-something. This includes using L2 triggers etc. When none of this is possible, the MN realizes that it has changed its AR through router advertisements and does CT, which is "Post"-something. Sure there is delay here. It is a matter of classification, not debating performance. Anyway, let's see if we can resolve the previous question. MN>> as I said earlier, the important point is to cover all the scenarios. whether proactive is pre-A or Pre-B is not important, but I think using default router which is probably one of the absolute last things that happens in handover might not be very suitable and is at least as ambiguous as other definitions, so we should not be creating new ambiguous definitions everyday. Madjid From owner-seamoby@diameter.org Thu Jun 28 16:23: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 QAA21288 for ; Thu, 28 Jun 2001 16:23:44 -0400 (EDT) Received: (qmail 14717 invoked by alias); 28 Jun 2001 20:11:20 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 14711 invoked by uid 200); 28 Jun 2001 20:11:20 -0000 Received: (qmail 14703 invoked from network); 28 Jun 2001 20:11:18 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 20:11:18 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA27124; Thu, 28 Jun 2001 13:15:49 -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 NAA21051; Thu, 28 Jun 2001 13:22:40 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 15:22:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E31@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , "'Pat Calhoun'" Cc: "'seamoby'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 15:22:34 -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 Hey, I must have missed the point all along, we are here to write purposely ambiguous requirements that everybody interprets differently :) The writer of the most ambiguous definition gets a free T-shirt in London :D -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, June 28, 2001 9:00 AM To: 'Pat Calhoun' Cc: 'seamoby' Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions No, it is not preferred. Not because it is better/worse, but simply because it is based upon concepts that are at least just as ambiguous as the previous definitions (which are ambiguous on purpose, btw). Gary > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, June 28, 2001 9:36 AM > To: Rajeev Koodli > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > > How is this: > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > initiated prior to the > > > newAR becomes the MN's default router. > > > > > > Post-Handoff Context Transfer: The Context Transfer is > initiated after the > > > newAR becomes the MN's default router. > > > > > > -Kulwinder. > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > on how to proceed > > next? > > what do folks think about using this terminology? Is this > preferred over the > existing terminology in the draft? > > PatC > From owner-seamoby@diameter.org Thu Jun 28 16:32: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 QAA26872 for ; Thu, 28 Jun 2001 16:31:48 -0400 (EDT) Received: (qmail 15198 invoked by alias); 28 Jun 2001 20:18:34 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15192 invoked by uid 200); 28 Jun 2001 20:18:34 -0000 Received: (qmail 15184 invoked from network); 28 Jun 2001 20:18:32 -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; 28 Jun 2001 20:18:32 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5SKTA001338; Thu, 28 Jun 2001 16:29:10 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 28 Jun 2001 16:29:17 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 16:29:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DB1@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Pat Calhoun'" Cc: "'seamoby'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Thu, 28 Jun 2001 16:29:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10010.FF2DC170" 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_01C10010.FF2DC170 Content-Type: text/plain; charset="iso-8859-1" No, we can instead defer this subject a write a draft on "the phases of ct". Specific requirements are terrific, as long as they do not exclude solutions that ct is chartered to address. E.g. CT MUST be performed across wireline links. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, June 28, 2001 4:23 PM > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun' > Cc: 'seamoby' > Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > Hey, I must have missed the point all along, we are > here to write purposely ambiguous requirements that > everybody interprets differently :) The writer of the > most ambiguous definition gets a free T-shirt in London :D > > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Thursday, June 28, 2001 9:00 AM > To: 'Pat Calhoun' > Cc: 'seamoby' > Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > No, it is not preferred. Not because it is better/worse, but simply > because it is based upon concepts that are at least just as ambiguous > as the previous definitions (which are ambiguous on purpose, btw). > > Gary > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Thursday, June 28, 2001 9:36 AM > > To: Rajeev Koodli > > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > > Madjid-MNAKHJI1'; 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? > was: proactive > > and re active CT definitions > > > > > > > > How is this: > > > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > initiated prior to the > > > > newAR becomes the MN's default router. > > > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > initiated after the > > > > newAR becomes the MN's default router. > > > > > > > > -Kulwinder. > > > > > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC > > on how to proceed > > > next? > > > > what do folks think about using this terminology? Is this > > preferred over the > > existing terminology in the draft? > > > > PatC > > > ------_=_NextPart_001_01C10010.FF2DC170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: [seamoby] CT trigger or CT completion? was: proactive = and re active CT definitions

No, we can instead defer this subject a write a draft = on
"the phases of ct".

Specific requirements are terrific, as long as they = do not
exclude solutions that ct is chartered to address. = E.g. CT
MUST be performed across wireline links.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: Thursday, June 28, 2001 4:23 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat = Calhoun'
> Cc: 'seamoby'
> Subject: RE: FW: [seamoby] CT trigger or CT = completion? was: proactive
> and re active CT definitions
>
>
> Hey, I must have missed the point all along, we = are
> here to write purposely ambiguous requirements = that
> everybody interprets differently :) The writer = of the
> most ambiguous definition gets a free T-shirt = in London :D
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Thursday, June 28, 2001 9:00 AM
> To: 'Pat Calhoun'
> Cc: 'seamoby'
> Subject: RE: FW: [seamoby] CT trigger or CT = completion? was: proactive
> and re active CT definitions
>
>
> No, it is not preferred. Not because it is = better/worse, but simply
> because it is based upon concepts that are at = least just as ambiguous
> as the previous definitions (which are = ambiguous on purpose, btw).
>
> Gary
>
> > -----Original Message-----
> > From: Pat Calhoun [mailto:pcalhoun@diameter.org]<= /FONT>
> > Sent: Thursday, June 28, 2001 9:36 = AM
> > To: Rajeev Koodli
> > Cc: Kulwinder Atwal; 'Pat Calhoun'; = 'Nakhjiri
> > Madjid-MNAKHJI1'; 'Charles
> > E. Perkins'; = 'seamoby@cdma-2000.org'
> > Subject: Re: FW: [seamoby] CT trigger or = CT completion?
> was: proactive
> > and re active CT definitions
> >
> >
> > > > How is this:
> > > >
> > > > Pre-Handoff Context Transfer: = The Context Transfer is
> > initiated prior to the
> > > > newAR becomes the MN's default = router.
> > > >
> > > > Post-Handoff Context = Transfer:  The Context Transfer is
> > initiated after the
> > > > newAR becomes the MN's default = router.
> > > >
> > > > -Kulwinder.
> > > >
> > > >
> > >
> > > Rajeev: This would work for me.  = May be we should ask PatC
> > on how to proceed
> > > next?
> >
> > what do folks think about using this = terminology? Is this
> > preferred over the
> > existing terminology in the draft?
> >
> > PatC
> >
>

------_=_NextPart_001_01C10010.FF2DC170-- From owner-seamoby@diameter.org Thu Jun 28 16:36: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 QAA00453 for ; Thu, 28 Jun 2001 16:36:55 -0400 (EDT) Received: (qmail 15270 invoked by alias); 28 Jun 2001 20:19:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 15263 invoked by uid 200); 28 Jun 2001 20:19:04 -0000 Received: (qmail 15254 invoked from network); 28 Jun 2001 20:19:00 -0000 Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 20:19:00 -0000 Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f5SKd1l28629; Thu, 28 Jun 2001 13:39:01 -0700 (PDT) Date: Thu, 28 Jun 2001 13:39:01 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com Reply-To: Youngjune Lee Gwon To: Emil Sturniolo cc: Charlie Perkins , seamoby@diameter.org Subject: RE: [seamoby] Question on 4.2 In-Reply-To: <00e001c10009$df52b650$7c168fd1@wrq-nc1.wrq.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, 28 Jun 2001, Emil Sturniolo wrote: > Hello Charlie, > My major concern when I posted the original note was in reaction to > proposed motion across different L2 technologies but to the same AR > without signaling. I was also concerned that no signaling was defined > for the detached state. In either instance, having L3 be somewhat > cognizant of these motion events can have dramatic positive effects > even across the same technology. From my own experience, I have found > that signaling as Youngjune suggests is helpful at L3. Suffice to say, > traffic flow can be minimized by using this information intelligently > and can be politely ignored when not. If we are going to go down the > path of defining L2 triggers, I would like to see the definition > meaningful to CT, but broad enough that it can be used by other L3 > entities as well (hopefully not biting off more the I/we can chew). ===> Yes, exactly Emilio. :) Again, all I'm trying to say is to illustrate the scope of L2 trigger that can be generally applicable to low-latency or CT. The case I described may be out of scope of CT in the sense that CT of one AR to another is obviously out of the picture, but rather emphasizes the importance of the L3 awareness toward the events at L2. In this intra-AR (intra-L3) movement, as Charlie has pointed out correctly, I should admit no involvement in L3 CT processes, except being aware of the L2 changes. Thanks, Youngjune > > > Cordially, > Emil Sturniolo > EmilS@NetMotionWireless.Com > www.NetMotionWireless.com > 330-723-9099 > 330-461-0326 - Mobile/Voice Mail > ===================== > > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 28, 2001 10:53 AM > To: Youngjune Lee Gwon > Cc: Emil Sturniolo; seamoby@diameter.org > Subject: Re: [seamoby] Question on 4.2 > > > Hello, > > I do not understand why this scenario makes sense. > In order for the layer-3 protocol to operate, there would > need to be a previous access router and a new access > router. Here there is none. Instead, we have a layer-2 > trigger that should initiate a layer-2 context transfer. > If that layer-2 context transfer is carried out by the > access router, then that's fine, but I don't see why it > needs to be the concern of the [seamoby] layer-3 > context transfer protocol. > > Regards, > Charlie P. > > > Youngjune Lee Gwon wrote: > > > I sort of agree with Emil and let me give you an example I have > thought > > about. Consider the picture below to illustrate my point. > > > > | <--> +----+ ========= > > [] # |AP 1|---------| AR 1 |-----+ > > MN | +----+ / ========= | > > | / | > > | / | | > > | / | ------- | > > | / +--|ANG 1|---+ > > | +----+ / | ------- | > > V |AP 2|/ | | > > +----+ | | > > | | > > > > If a MN moves from AP1 to AP2, where both APs are connected to the > same L3 > > entity, AR1, there is no MIP process should be involved since the MN > does > > not change in terms of MIP. > > > > This puts the MN's mobility support, pretty much, relying completely > on > > the L2 technology of AP1 & AP2. My question is that what if AP1 and > AP2 > > does not support fast/smooth handoff at L2. Does this mean > automatically > > that the L3 communication during this move is disrupted, blacked > out, or > > discontinuous for a short time? In other words, the choice of the L2 > > technology may be crucial for the outcomes at L3? > > > > In any cases, independently from the L2 capability, L3 can still be > > seamless without interruptions. This can be possible if L3 is aware > of > > what events are occurred at L2. To certain degree, I agree L3 should > also > > be involved in movement matters by interacting with the lower layer. > > > > Maybe, this is not really the scope of SeaMoby or IETF since this > case is > > within a single L3 entity while switching only between L2 entities. > > > > Secondly, if AP1 and AP2 are running different access technolgoies, > it > > gets even more interesting because there is no clear definition of > L2 > > handoff. It may get to a problem where L3 is choosing one link from > two > > simultaneously available connections. User preference may also come > in to > > play in this case. > > > > I just recall that L2 trigger is a special case of this L2-L3 > interaction. > > At the same time, L2 trigger is a kind of L3-awaring mechanism about > the > > mobility of a MN itself. > > > > Any thoughts? Arguments? Objections? Let me know... > > > > Youngjune > > > > On Wed, 27 Jun 2001, Emil Sturniolo wrote: > > > > > Kulwinder. > > > > > > > James, > > > > > > > > ... snip... > > > > >1. Fast movement detection/prediction > > > > > > > > Well, actually, I do disagree here. > > > > > > > > I believe the following view more accurately reflects > > > > what is going on between L2 and L3 around handover. Basically, > L3 > > > > is not concerned with movement, it is concerned with routability > > > > changes, L2 is concerned with movement. To be more specific, L3 > is > > > > only concerned with movement to the extent that a movement at L2 > > > > causes > > > > a change in routability that requires (for MIP) a change in CoA. > If > > > > movement > > > > causes no change in routability, then L3 should not be involved. > > > > ........ > > > > > > > > [Emil]. James, I'd like to add one scenario that might slightly > > > change > > > > the semantics, if it's within the scope of the conversation. > Most of > > > > this thread has been concern with the situation where > connectivity > > > at > > > > L2 is constant and possibly predictive. However, it has been my > > > > experience that this is not truly reflective of reality. IMHO L3 > > > > should be involved if a mobile node becomes detached and then > > > > reattached to the same network, even though no changes in > > > routability > > > > may have occurred. > > > > > > > L3 needs to be knowledgeable of this event to at > > > > least verify routability and possibly facilitate faster recovery > at > > > > even higher levels in the protocol stack (slings and arrows > > > welcome). > > > > > > I would say that L3 mobility is concerned about routability and > not > > > concerned with movement. > > > If a router has mulitiple L2 interfaces then a change from one L2 > > > interface > > > to another will not affect L3. In this case, L2 can verify > > > routability > > > because it is still the same AR. > > > > > > If it is a different AR, then there is a change in routability, > and a > > > need > > > to inform L3 mobility. > > > > > > Unless, there is another case that comes to mind. > > > > > > - Kulwinder. > > > > > > [Emil] Kulwinder, what I was trying to point out is that even > though > > > it is still the same AR it is still useful to signal L3 that > > > connectivity has been re-established. Off the top of my head, > > > depending on when and the length of time that the MN was > disconnected, > > > after L2 connectivity is reaffirmed, it may need to determine if > its > > > own addressibility is still valid Furthermore, as I said in my > > > original note, this indication may also help facilitate recovery > > > further up the stack. Maybe this is a different trigger that I am > > > describing here, but it does seem to be consistent with > > > acquisition/continuation of L2 connectivity. > > > > > > Cordially, > > > Emil Sturniolo > > > EmilS@NetMotionWireless.Com > > > www.NetMotionWireless.com > > > 330-723-9099 > > > 330-461-0326 - Mobile/Voice Mail > > > ===================== > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 17:09:53 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23472 for ; Thu, 28 Jun 2001 17:09:46 -0400 (EDT) Received: (qmail 16351 invoked by alias); 28 Jun 2001 20:56:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16345 invoked by uid 200); 28 Jun 2001 20:56:38 -0000 Received: (qmail 16340 invoked from network); 28 Jun 2001 20:56:36 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 20:56:36 -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 OAA00963; Thu, 28 Jun 2001 14:07:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SL7T927739; Thu, 28 Jun 2001 14:07:29 -0700 X-mProtect: Thu, 28 Jun 2001 14:07:29 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd4qcxTo; Thu, 28 Jun 2001 14:07:28 PDT Message-ID: <3B3B9C90.4D20E947@iprg.nokia.com> Date: Thu, 28 Jun 2001 14:07:28 -0700 From: Rajeev Koodli 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: Gary Kenward CC: Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DAF@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > Rajeev: > I agree with the logic concerning changing links versus changing > handovers. > I am somewhat perplexed about the use of the router discovery protocol > > in a handover situations. Adding more over the air round trips to > complete > a handover doesn't sound very seamless to me. > It is puzzling to me that you would agree with the logic and yet do not understand what constitutes IP router discovery! It is a procedure that all IP nodes do as part of bootstrapping their interfaces, including when they change networks. Simply put, if you changed AR, you would be doing router discovery. Who is proposing to add more messages over the air interface? -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Thursday, June 28, 2001 2:10 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri > > Madjid-MNAKHJI1'; 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive > > and re active CT definitions > > > > > > > > Gary, > > > > let me cut and paste some text from below. > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > When the MN determines that it has changed its default router, > through > > router discovery, it has undergone IP handover. We need to focus on > > IP handover since changing the AR definitively constitutes > performing > > CT. On the other hand, if you _only_ change the link, can you be > sure > > that you will also change the AR ? > > > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > > > > > Define "handoff". > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > Sent: Wednesday, June 27, 2001 8:19 PM > > > > To: Kulwinder Atwal > > > > Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > > E. Perkins'; > > > > > > > 'seamoby@cdma-2000.org' > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > proactive > > > > and re active CT definitions > > > > > > > > > > > > Kulwinder Atwal wrote: > > > > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would do CT either > > > > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default router, or > > > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > context > > > > > > transfer to be > > > > > > independent of handover is perhaps not sensible. Getting it > > > > > > to work with > > > > > > handovers is the challenge we are peddling. > > > > > > If we all agree on this, may be we should try to > > close the issue > > > ? > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > How is this: > > > > > > > > > > Pre-Handoff Context Transfer: The Context Transfer is > > > > initiated prior to the > > > > > newAR becomes the MN's default router. > > > > > > > > > > Post-Handoff Context Transfer: The Context Transfer is > > > > initiated after the > > > > > newAR becomes the MN's default router. > > > > > > > > > > -Kulwinder. > > > > > > > > > > > > > > > > > > Rajeev: This would work for me. May be we should ask PatC on > > > > how to proceed > > > > next? > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but handover is pretty vague. Like Gary said, is the > > > > > > start, exact > > > > > > > middle, or end of handover, or some special protocol event > > > > > > > in the middle. > > > > > > > In a collision based wired, or a wireless network we can't > > > > > > > be certain which > > > > > > > protocol packet will arrive first. > > > > > > > > > > > > > > Also, we all seem to agree that if pre-connection Context > > > > > > Transfer takes too > > > > > > > long due to the uncertain nature of wireless (End-user > > > > > > drives through a > > > > > > > tunnel), it is very likely that several post-connection > > > > > > events will pass > > > > > > > before the transfer is complete. > > > > > > > > > > > > > > So, we may start with the best of intentions with the > > > > > > intent of being early > > > > > > > enough to not affect the user experience, but events may > > > > > > overtake us such > > > > > > > that we find ourselves out of time. > > > > > > > > > > > > > > So, what do we do at that point in time? > > > > > > > > > > > > > > A particular technology may find it advantageous to do > > > > > > post-connection, if > > > > > > > the data is available, even after the user has experienced > > > > > > > a distruption, > > > > > > > becuase the connection setup time will be longer than the > > > > > > post-connection > > > > > > > Context Transfer time. > > > > > > > > > > > > > > An other technology may find it advantageous to > > > > > > re-establish new context, > > > > > > > because the Context Transfer time (Round-Trip Times) are > > > > > > greater than new > > > > > > > connection setup. > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > It is up to the implementor to take into account > > > particular > > > > > > > > network and > > > > > > > > > inter-network characteristics and real-time flow > > > > > > > > requirements to determine > > > > > > > > > how early Pre-Connection Context Transfer needs > > to be done > > > > > > > > > > > to guarrantee > > > > > > > > > seamless. > > > > > > > > > > > > > > > > > > - Kulwinder. > > > > > > > > > > > > > > > > > > > In all cases that I > > > > > > > > > > know of, some > > > > > > > > > > signalling, either at L2 or L3, is used to > > register the > > > > > > > > > > mobile locally (or > > > > > > > > > > some signal strength measurements), but there > > is always > > > an > > > > > > > > > > indication of handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But, really why should we care where the request > for > > > CT > > > > > > > > > > comes from if we are > > > > > > > > > > > going to process it just the same? > > > > > > > > > > > > > > > > > > > > > > The only thing that is important is that the > > > requesting > > > > > > > > > > entity recieve a > > > > > > > > > > > packet indicating the success or failure mode of > the > > > CT > > > > > > > > operation. > > > > > > > > > > > > > > > > > > > > ditto. > > > > > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 18:32: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 SAA08504 for ; Thu, 28 Jun 2001 18:32:46 -0400 (EDT) Received: (qmail 17281 invoked by alias); 28 Jun 2001 22:19:28 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17275 invoked by uid 200); 28 Jun 2001 22:19:27 -0000 Received: (qmail 17270 invoked from network); 28 Jun 2001 22:19:25 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 22:19:25 -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 PAA06915; Thu, 28 Jun 2001 15:30:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SMUIF23321; Thu, 28 Jun 2001 15:30:18 -0700 X-mProtect: Thu, 28 Jun 2001 15:30:18 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdg8Gurr; Thu, 28 Jun 2001 15:30:16 PDT Message-ID: <3B3BAFF8.58E88588@iprg.nokia.com> Date: Thu, 28 Jun 2001 15:30:16 -0700 From: Rajeev Koodli 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: Gary Kenward CC: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DB0@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Gary, Gary Kenward wrote: > > > Rajeev: > > See my previous posting. I agree that you and I have very different > pictures. For me, providing seamless handovers means eliminating as > much signalling overhead as possible, particularly over the air, and > doing as > I replied to that e-mail. Actually, I am glad that you share these views regarding air-interface friendly. > > much as possible as early as possible. The latter includes reacting as > soon > as possible to an on-going handover as much as it means being > proactive about > possible handovers. > > MN triggers, router discovery, etc. don't fit my goal of providing no > degradation to the user service. > Yet, I don't think you understand what constitutes router discovery. This is not something I am proposing new. I guess your definition of seamlessness includes not doing router discovery, which is quite puzzling.. How does a MN identify its default router and that it is on its default router then ? There is an IETF RFC which is implemented in numerous nodes. I would have to guess that you would not comply with it. In any case, the summary is that - I am not proposing new messages over the air interface. I would appreciate it if you could understand that and stop saying it. - router discovery provides a good reference point for us for the purpose of this discussion. I hope you could focus on that. > > This difference of viewpoints is all ok, for we all love diversity in > the Internet. But this also means that the definition of CT should not > be limited, at very least, not limited so early in the design process, > to exclusive trigger events when the potential of alternative > approaches has not been explored. > Well, my argument is that the current defintion is ambiguous and insufficient. -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > Sent: Thursday, June 28, 2001 2:30 PM > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > 'Charles > > E. Perkins'; 'seamoby@cdma-2000.org' > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > proactive > > and re active CT definitions > > > > > > Gary Kenward wrote: > > > > > > > > > > > And that "standard router discovery" works for mobile access? > > > > I don't know what you mean, but, if it is in a standards track RFC, > I > > "guess" it (router discovery) should work for whatever access. We > know > > it does and provides a standard reference for us. Given the > different > > pictures we all have, this is perhaps the best we have as a > reference > > point. > > > > -Rajeev > > > > > > > > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Thursday, June 28, 2001 2:01 PM > > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > > > 'Charles > > > > E. Perkins'; 'seamoby@cdma-2000.org' > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > proactive > > > > and re active CT definitions > > > > > > > > > > > > > > > > Hello Gary, > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > To expand a bit on my previous question: what defines a > "default > > > > > router" > > > > > in a mobile wireless access network? This is a similar issue > to > > > > > defining > > > > > "what is a handoff or handover". > > > > > > > > > > > > > > > > > > Rajeev: There is standard IP router discovery that > > enables any node > > > to > > > > determine its default router. See RFC 2461. > > > > > > > > > > > > > Before everyone starts talking MIP, be reminded that the > > > > charter (and > > > > > the > > > > > problem statement, and the requirements) state that ct > > should work > > > > > > > > with > > > > > with different wireless networks and different mobility > > > > solutions and > > > > > not > > > > > just with MIP (if ct is to be an augmentation of MIP, fine, > let > > > Pat > > > > > rewrite > > > > > the charter and those of use who need to work on non-MIP ct > can > > > move > > > > > on). > > > > > > > > > > > > > Rajeev: router discovery is independent of MIP. > > > > > > > > > > > > > > Clearly, from the discussion that has transpired, if we > > all really > > > > > > > > believe > > > > > that defining an "event" for reactive mode in the requirements > > > > draft > > > > > is key > > > > > to making ct work, then we should define what a handover is. > As > > > > > everyone > > > > > knows by now, I do not believe it is required by for the > > > requirement > > > > > document, > > > > > and even more important, I suspect that a general definition > of > > > > > handover > > > > > will take a long time to work out. However, if the wg > > believes it > > > is > > > > > needed, > > > > > then let's make the valiant attempt. > > > > > > > > > > > > > Rajeev: using "default AR" as the basis would not need such a > > > > defintion. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Regards, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > > Sent: Wednesday, June 27, 2001 8:28 PM > > > > > > To: Pat Calhoun > > > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. > > > > > > Perkins'; > > > > > > 'seamoby@cdma-2000.org' > > > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > > > > proactive > > > > > > and re active CT definitions > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev > > Koodli wrote: > > > > > > > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would > > do CT either > > > > > > > > > > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default > > router, or > > > > > > > > > > > > > 2. after the new AR becomes the MN's default router > > > > > > > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > > > > context transfer to be > > > > > > > > independent of handover is perhaps not sensible. Getting > > > > > > > it to work with > > > > > > > > handovers is the challenge we are peddling. > > > > > > > > If we all agree on this, may be we should try to > > > > close the issue > > > > > ? > > > > > > > > > > > > > > The issue I have is that the current definitions use some > > > > > > random packet destined > > > > > > > for the mobile as the timing "event". This, im my mind, > > > > > > makes no sense whatsoever, > > > > > > > because one side (oAR) may not know when the packet shows > > > > > > up, and therefore it > > > > > > > has no idea whether a reactive or proactive CT is to be > > > invoked. > > > > > > > > > > > > > > FWIW, some CTs will transfer L2 session keys used for > > > > > > authentication and > > > > > > > encryption, so this is where the first packet doesn't > > > > make sense. > > > > > > > > > > > > > > > > > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > > > > > today) does not say anything > > > > > > about the "first" packet. It is based on whether CT is > > > > > > initiated when the new AR is > > > > > > (not) the default router. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-seamoby@diameter.org Thu Jun 28 18:52: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 SAA22382 for ; Thu, 28 Jun 2001 18:52:03 -0400 (EDT) Received: (qmail 17805 invoked by alias); 28 Jun 2001 22:39:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17799 invoked by uid 200); 28 Jun 2001 22:39:56 -0000 Received: (qmail 17793 invoked from network); 28 Jun 2001 22:39:54 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 22: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 PAA07697; Thu, 28 Jun 2001 15:50:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SMokK04496; Thu, 28 Jun 2001 15:50:46 -0700 X-mProtect: Thu, 28 Jun 2001 15:50:46 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQZFRhe; Thu, 28 Jun 2001 15:50:45 PDT Message-ID: <3B3BB4C6.296ADD0@iprg.nokia.com> Date: Thu, 28 Jun 2001 15:50:46 -0700 From: Rajeev Koodli 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: "'Pat Calhoun'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <35DBB8B7AC89D4118E98009027B1009B017A9E30@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 madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > Hi Rajeev, > > -Rajeev: I have a question here. Is it possible that you can establish a new > L2 > and still not change your AR ? If yes, if you don't change AR, is there is > still any CT ? Is this too naive ? > It seems to me that the AR is the key entity (for our defintion) since that > holds the feature contexts. > > MN>>> But without broadening the scope of CT, lets assume that CT is AR1-AR2 > > (change of AR is part of the scenario) > > *So the discussion is what is difference between new-L2 establishment and > change > of default router. I say difference is the timing.* > > Rajeev: Actually, I am not sure if this is all..If you only change APs and are still with the same AR, you don't change your default router. So, the point is that changing L2 does not necessarily constitute changing AR, independent of time. > The case that comes to my mind, when you change L2 but newAR is still not > your default router, is say: > MN is at new L2, but did not have time to sent binding update to > the oldAR before moving, so its using new L2 to start the L3 routing > change procedure, it does not have newAR as default router but > has L2 with newAR. > Rajeev: The new AR needs an entry in its neighbor cache before it could forward packets, including Binding Updates. > The other case is, if it has obtained its new IP address through > stateless autoconfiguration, but the new address is rejected by > newAR, although MN has L2 with newAR. > Rajeev: In this case, it (the MN) has not completed acquiring an IP address yet. In both the two cases you mentioned, you are assuming that new L2 implies new AR. This need not be the case. So, the only definitive point of reference is if the MN changes its default AR. > > So you can base your proactive CT on *predictions* based on L2 information > Do the proactive CT and manage to get your context over to newAR > > [snip]. > > Rajeev: There is IP router discovery that indicates to a node when some AR > has > become the default AR. > > Any CT that happens prior to this phase is "Pre"-something. This includes > using > L2 triggers etc. When none of this is possible, the MN realizes that it has > changed its AR through router advertisements and does CT, which is > "Post"-something. Sure there is delay here. It is a matter of > classification, > not debating performance. > Anyway, let's see if we can resolve the previous question. > > MN>> as I said earlier, the important point is to cover all the scenarios. > whether proactive is pre-A or Pre-B is not important, but I think using > default router which is probably one of the absolute last things that > happens in handover might not be very suitable and is at least as ambiguous > as other definitions, so we should not be creating new ambiguous definitions > everyday. > Rajeev: could you say why it is ambiguous and why is it not very suitable ? Regards, -Rajeev > > Madjid From owner-seamoby@diameter.org Thu Jun 28 18:59: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 SAA27722 for ; Thu, 28 Jun 2001 18:59:30 -0400 (EDT) Received: (qmail 18303 invoked by alias); 28 Jun 2001 22:47:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18297 invoked by uid 200); 28 Jun 2001 22:47:43 -0000 Received: (qmail 18291 invoked from network); 28 Jun 2001 22:47:41 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 28 Jun 2001 22:47:41 -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 PAA08111; Thu, 28 Jun 2001 15:58:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SMwYa12808; Thu, 28 Jun 2001 15:58:34 -0700 X-mProtect: Thu, 28 Jun 2001 15:58:34 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHL7tCX; Thu, 28 Jun 2001 15:58:32 PDT Message-ID: <3B3BB699.45A99938@iprg.nokia.com> Date: Thu, 28 Jun 2001 15:58:33 -0700 From: Rajeev Koodli 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: Kulwinder Atwal , "'Pat Calhoun'" , seamoby@cdma-2000.org Subject: Re: [seamoby] Issue 2: Make IP messages uniform References: <35DBB8B7AC89D4118E98009027B1009B017A9E2B@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 Nakhjiri Madjid-MNAKHJI1 wrote: > Exactly. As soon as the MN detects that it has undergone handover, it sends > a > message which includes BU as an encapsulation. The new AR sends the CT > message > towards the old AR and the BU towards the mobility agent. > We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in > Pittsburgh IETF). > > MN>> Rajeev, sorry I have not read the draft, so I am trying > to see if I understand this. > Could you define: "MN detects it has undergone handover", > is it L2 signals from oldAR, PrRtAdv, L2 establishment at newAR? > Rajeev: This is through router advertisements on the new link. Recall that we are focussing on the scenario where a MN lost its existing link and regained another without time for anything such as fast handovers. Through router advertisement, the MN recognizes that it is on a new AR. It *could* detect that it has changed L2, but may not be able to ascertain that it has changed its AR. Using router advertisements is definitive. > > MN sends the BU to oldAR, right? How would newAR know about BU > right then? Rajeev: The BU I was talking about is the BU to the LMM agent/Home Agent, which goes through the new AR. > > Would It not make more sense if oldAR starts the CT messaging? Rajeev: It would, whenever possible. Regards, -Rajeev > > > Madjid From owner-seamoby@diameter.org Fri Jun 29 08:03:47 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08450 for ; Fri, 29 Jun 2001 08:03:45 -0400 (EDT) Received: (qmail 21998 invoked by alias); 29 Jun 2001 11:29:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21992 invoked by uid 200); 29 Jun 2001 11:29:29 -0000 Received: (qmail 21986 invoked from network); 29 Jun 2001 11:29:27 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Jun 2001 11:29:27 -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 EAA08273; Fri, 29 Jun 2001 04:40:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5TBeMA02568; Fri, 29 Jun 2001 04:40:22 -0700 X-mProtect: Fri, 29 Jun 2001 04:40:22 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdJ1gghL; Fri, 29 Jun 2001 04:40:20 PDT Message-ID: <3B3C6920.39574AA6@iprg.nokia.com> Date: Fri, 29 Jun 2001 04:40:16 -0700 From: Cedric Westphal Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: Pat Calhoun , seamoby@cdma-2000.org Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT References: <35DBB8B7AC89D4118E98009027B1009B017A9E2D@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 Nakhjiri Madjid-MNAKHJI1 wrote: > Hi cedric, > > -----Original Message----- > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com] > Sent: Tuesday, June 26, 2001 9:35 AM > To: Pat Calhoun > Cc: Gary Kenward; seamoby@cdma-2000.org > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT > > I agree with this (the support for multi-phase ct proposal) > and would actually go one step further: > > requirement: a proactive transfer MUST be multiphasic (so that accounting > transfer can be transfered after the handoff and config transfer before the > handoff) > a reactive transfer SHOULD be monophasic. > > MN>> I don't agree, I think it is actually more important to have > a multiphasic CT for reactive than it is for proactive. > If you had to wait for packet delivery until the end of CT > (which I am not proposing) then > You would loose more packets in reactive. Hence you should break > CT into pieces. After sending the more urgent context, you could > resume packet delivery and at the same time, take your time with > less urgent context. [cedric] I agree with the fact that reactive CT could be pluriphasic, that's why it is a SHOULD, not a MUST. Or are you saying that _all_ CT should be in several phases? Are you proposing that 'CT, even reactive, MUST be in several phase'? I hope not. > and the distinction between proactive and reactive becomes one of a number > of phases. > > MN>> yet another proactive/ reactive definition, please give us a > break :) [cedric] not a definition, a distinction ;). Take care, Cedric. > > > Madjid > > Cedric. > > Pat Calhoun wrote: > > > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote: > > > I with you up until that last two paragraphs of the proposed new texts. > > > The second to last paragraph is editorial, and presumes much about the > > > context, > > > the ctp design and the implementation. > > > > ok, I am certainly open to suggestions. > > > > > As for the last paragraph, I do not see the need to add priority to CTP. > > > It is already required that the receiving AR process the context in the > > > order received, and this yields the same result (priority can always be > > > translated to a measurable performance criteria, such as "processed sooner" > > > or "given more resources"). I do not see the utility of a "priority" bit. > > > Perhaps you could > > > elaborate? > > > > This isn't a question of a bit. It has to do with sending critical CT > > information that is REQUIRED in order to deliver a single packet to the > > mobile. This could include HC state, session keys, etc. This state info > > is sent first when a handoff is occuring. > > > > Later (say, 1+ seconds later) additional state is sent. Although this > > info is important, it may only be necessary when doing things such as > > generating accounting messages, which are infrequent, and not required > > during the handoff process. > > > > > Otherwise I have no problem with the additional requirement (although I > > > wonder what an operator would say about "accounting" being "low priority" > > > ;^}). > > > > :) > > > > PatC > > > > > > > > Gary > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > Sent: Thursday, June 21, 2001 6:37 PM > > > > To: seamoby@cdma-2000.org > > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT > > > > > > > > > > > > Issue 5: Support for multi-phase CT > > > > > > > > Submitter name: Pat Calhoun > > > > Submitter email address: pcalhoun@eng.sun.com > > > > Date first submitted: June 21,2001 > > > > Reference: > > > > Comment type: T > > > > Priority: 1 > > > > Section: 4.9 > > > > > > > > Rationale/Explanation of issue: > > > > The current requirement in section 4.9 states that a CT can only > > > > occur once all of the state has been gathered. The CT protocol > > > > must allow for state to be transferred in phases, where the high > > > > priority state (e.g. Header Compression, session keys) is sent > > > > first, and low priority items are sent at a later time (e.g. > > > > accounting information). > > > > > > > > This would reduce the size of the high priority CT packets, > > > > lower the computational cost of processing the packet, > > > > and decrease > > > > the handoff latency. > > > > > > > > Requested change: > > > > Change 4.9 to state something like: > > > > > > > > "4.9 Context information MAY be transferred in phases, > > > > allowing for > > > > higher priority state to be sent first, and lower priority > > > > state to be sent at a later time. > > > > > > > > The total cost of processing a smaller packet with high priority > > > > state is smaller, and would decrease any latency > > > > introduced by CT. Each > > > > CT profile would need to specify whether it is to be considered > > > > as a high or low priority state." > > > > > > > > Proposal: > > > > Adopt the text above in the -01 version of the > > > > requirements spec. > > > > From owner-seamoby@diameter.org Fri Jun 29 10:43: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 KAA20573 for ; Fri, 29 Jun 2001 10:42:34 -0400 (EDT) Received: (qmail 24300 invoked by alias); 29 Jun 2001 14:22:15 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24294 invoked by uid 200); 29 Jun 2001 14:22:15 -0000 Received: (qmail 24286 invoked from network); 29 Jun 2001 14:22:12 -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; 29 Jun 2001 14:22:12 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5TEWr021887 for ; Fri, 29 Jun 2001 10:32:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 29 Jun 2001 10:32:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 10:32:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DB4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Date: Fri, 29 Jun 2001 10:32:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100A8.5D24E7D0" 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_01C100A8.5D24E7D0 Content-Type: text/plain; charset="iso-8859-1" Rajeev: > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > Sent: Thursday, June 28, 2001 6:30 PM > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles > E. Perkins'; 'seamoby@cdma-2000.org' > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive > and re active CT definitions > > > > Gary, > > > Gary Kenward wrote: > > > > > > > Rajeev: > > > > See my previous posting. I agree that you and I have very different > > pictures. For me, providing seamless handovers means eliminating as > > much signalling overhead as possible, particularly over the air, and > > doing as > > > > I replied to that e-mail. Actually, I am glad that you share > these views > regarding air-interface friendly. > > > > > much as possible as early as possible. The latter includes > reacting as > > soon > > as possible to an on-going handover as much as it means being > > proactive about > > possible handovers. > > > > MN triggers, router discovery, etc. don't fit my goal of > providing no > > degradation to the user service. > > > > Yet, I don't think you understand what constitutes router discovery. > This is not something I am proposing new. I guess your definition of > seamlessness includes not doing router discovery, which is quite > puzzling.. How does a MN identify its default router and that it is on > its default router then ? There is an IETF RFC which is implemented in > numerous nodes. I would have to guess that you would not > comply with it. I guess I don't understand the context of what you speak of. A discovery algorithm, particularly those described in IETF RFC are designed largely to identify static routes through a network (quasi-static, as they also consider fail-over). To me this has nothing to do with micromobility. Simply a matter of semantics I would suspect, as certainly one could interpret the action of determining the new forwarding path through the access network to support a mobile node as "router discovery". But when you quoted IETF RFCs, I was at a loss - and part of that discovery process are ICMP messages generated from the host. > > In any case, the summary is that > > - I am not proposing new messages over the air interface. I would > appreciate it if you could understand that and stop saying it. Ok. No new messages (but I am confused about MN generated L3 CT triggers at this point. ) > > - router discovery provides a good reference point for us for the > purpose of this discussion. I hope you could focus on that. No, I don't agree. Other then at a conceptual level, the process of router discovery has little relationship with mobility. I hope you can focus on that. > > > > > > This difference of viewpoints is all ok, for we all love > diversity in > > the Internet. But this also means that the definition of CT > should not > > be limited, at very least, not limited so early in the > design process, > > to exclusive trigger events when the potential of alternative > > approaches has not been explored. > > > > Well, my argument is that the current defintion is ambiguous and > insufficient. Yes, we are all well aware of this. And everyone is focussed on the debate over this one possible approach to ct. You don't do the design in a requirements document, but that is what's going on. CT is not about triggering off of one possible event, it is about a protocol that can be initiated by many different possible events to support mobility. You want to get on to detail? Then let's close off the requirements, and move onto the design. Then we can compare the relative merits of different approaches, and see if it really makes a difference to CT. Gary > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > Sent: Thursday, June 28, 2001 2:30 PM > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > > 'Charles > > > E. Perkins'; 'seamoby@cdma-2000.org' > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > proactive > > > and re active CT definitions > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > And that "standard router discovery" works for mobile access? > > > > > > I don't know what you mean, but, if it is in a standards > track RFC, > > I > > > "guess" it (router discovery) should work for whatever access. We > > know > > > it does and provides a standard reference for us. Given the > > different > > > pictures we all have, this is perhaps the best we have as a > > reference > > > point. > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Thursday, June 28, 2001 2:01 PM > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > > > > 'Charles > > > > > E. Perkins'; 'seamoby@cdma-2000.org' > > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: > > > > proactive > > > > > and re active CT definitions > > > > > > > > > > > > > > > > > > > > Hello Gary, > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > To expand a bit on my previous question: what defines a > > "default > > > > > > router" > > > > > > in a mobile wireless access network? This is a similar issue > > to > > > > > > defining > > > > > > "what is a handoff or handover". > > > > > > > > > > > > > > > > > > > > > > Rajeev: There is standard IP router discovery that > > > enables any node > > > > to > > > > > determine its default router. See RFC 2461. > > > > > > > > > > > > > > > > Before everyone starts talking MIP, be reminded that the > > > > > charter (and > > > > > > the > > > > > > problem statement, and the requirements) state that ct > > > should work > > > > > > > > > > with > > > > > > with different wireless networks and different mobility > > > > > solutions and > > > > > > not > > > > > > just with MIP (if ct is to be an augmentation of MIP, fine, > > let > > > > Pat > > > > > > rewrite > > > > > > the charter and those of use who need to work on non-MIP ct > > can > > > > move > > > > > > on). > > > > > > > > > > > > > > > > Rajeev: router discovery is independent of MIP. > > > > > > > > > > > > > > > > > Clearly, from the discussion that has transpired, if we > > > all really > > > > > > > > > > believe > > > > > > that defining an "event" for reactive mode in the > requirements > > > > > > draft > > > > > > is key > > > > > > to making ct work, then we should define what a handover is. > > As > > > > > > everyone > > > > > > knows by now, I do not believe it is required by for the > > > > requirement > > > > > > document, > > > > > > and even more important, I suspect that a general definition > > of > > > > > > handover > > > > > > will take a long time to work out. However, if the wg > > > believes it > > > > is > > > > > > needed, > > > > > > then let's make the valiant attempt. > > > > > > > > > > > > > > > > Rajeev: using "default AR" as the basis would not need such a > > > > > defintion. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com] > > > > > > > Sent: Wednesday, June 27, 2001 8:28 PM > > > > > > > To: Pat Calhoun > > > > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; > 'Charles E. > > > > > > > > Perkins'; > > > > > > > 'seamoby@cdma-2000.org' > > > > > > > Subject: Re: FW: [seamoby] CT trigger or CT > completion? was: > > > > > > > > proactive > > > > > > > and re active CT definitions > > > > > > > > > > > > > > > > > > > > > Pat Calhoun wrote: > > > > > > > > > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev > > > Koodli wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Rajeev: I guess the point is that you would > > > do CT either > > > > > > > > > > > > > > > > > > > > > > > > > > 1. before the new AR becomes the MN's default > > > router, or > > > > > > > > > > > > > > > 2. after the new AR becomes the MN's > default router > > > > > > > > > > > > > > > > > > > > > > Both 1) and 2) are related to handover. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The point of above text was to indicate that defining > > > > > > > context transfer to be > > > > > > > > > independent of handover is perhaps not > sensible. Getting > > > > > > > > > it to work with > > > > > > > > > handovers is the challenge we are peddling. > > > > > > > > > If we all agree on this, may be we should try to > > > > > close the issue > > > > > > ? > > > > > > > > > > > > > > > > The issue I have is that the current > definitions use some > > > > > > > random packet destined > > > > > > > > for the mobile as the timing "event". This, im my mind, > > > > > > > makes no sense whatsoever, > > > > > > > > because one side (oAR) may not know when the > packet shows > > > > > > > up, and therefore it > > > > > > > > has no idea whether a reactive or proactive CT is to be > > > > invoked. > > > > > > > > > > > > > > > > FWIW, some CTs will transfer L2 session keys used for > > > > > > > authentication and > > > > > > > > encryption, so this is where the first packet doesn't > > > > > make sense. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rajeev: But the above text (and the text Kulwinder sent > > > > > > > today) does not say anything > > > > > > > about the "first" packet. It is based on whether CT is > > > > > > > initiated when the new AR is > > > > > > > (not) the default router. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C100A8.5D24E7D0 Content-Type: text/html; charset="iso-8859-1" RE: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

Rajeev:

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Thursday, June 28, 2001 6:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
>
>
>
> Gary,
>
>
> Gary Kenward wrote:
>
> >
> >
> > Rajeev:
> >
> > See my previous posting. I agree that you and I have very different
> > pictures. For me, providing seamless handovers means eliminating as
> > much signalling overhead as possible, particularly over the air, and
> > doing as
> >
>
> I replied to that e-mail. Actually, I am glad that you share
> these views
> regarding air-interface friendly.
>
> >
> > much as possible as early as possible. The latter includes
> reacting as
> > soon
> > as possible to an on-going handover as much as it means being
> > proactive about
> > possible handovers.
> >
> > MN triggers, router discovery, etc. don't fit my goal of
> providing no
> > degradation to the user service.
> >
>
> Yet, I don't think you understand what constitutes router discovery.
> This is not something I am proposing new. I guess your definition of
> seamlessness includes not doing router discovery, which is quite
> puzzling.. How does a MN identify its default router and that it is on
> its default router then ? There is an IETF RFC which is implemented in
> numerous nodes. I would have to guess that you would not
> comply with it.

I guess I don't understand the context of what you speak of. A discovery
algorithm, particularly those described in IETF RFC are designed largely
to identify static routes through a network (quasi-static, as they also
consider fail-over). To me this has nothing to do with micromobility.

Simply a matter of semantics I would suspect, as certainly one could interpret
the action of determining the new forwarding path through the access network to
support a mobile node as "router discovery". But when you quoted IETF RFCs,
I was at a loss - and part of that discovery process are ICMP messages generated
from the host.

>
> In any case, the summary is that
>
> - I am not proposing new messages over the air interface. I would
> appreciate it if you could understand that and stop saying it.

Ok. No new messages (but I am confused about MN generated L3 CT triggers
at this point.
)
>
> - router discovery provides a good reference point for us for the
> purpose of this discussion. I hope you could focus on that.

No, I don't agree. Other then at a conceptual level, the process of
router discovery has little relationship with mobility. I hope you can
focus on that.

>
>
> >
> > This difference of viewpoints is all ok, for we all love
> diversity in
> > the Internet. But this also means that the definition of CT
> should not
> > be limited, at very least, not limited so early in the
> design process,
> > to exclusive trigger events when the potential of alternative
> > approaches has not been explored.
> >
>
> Well, my argument is that the current defintion is ambiguous and
> insufficient.

Yes, we are all well aware of this. And everyone is focussed on the
debate over this one possible approach to ct. You don't do the design
in a requirements document, but that is what's going on.

CT is not about triggering off of one possible event, it is about a
protocol that can be initiated by many different possible events to
support mobility.

You want to get on to detail? Then let's close off the requirements,
and move onto the design. Then we can compare the relative merits of
different approaches, and see if it really makes a difference to CT.

Gary

>
> -Rajeev
>
>
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> > > Sent: Thursday, June 28, 2001 2:30 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> > 'Charles
> > > E. Perkins'; 'seamoby@cdma-2000.org'
> > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > proactive
> > > and re active CT definitions
> > >
> > >
> > > Gary Kenward wrote:
> > >
> > > >
> > > >
> > > > And that "standard router discovery" works for mobile access?
> > >
> > > I don't know what you mean, but, if it is in a standards
> track RFC,
> > I
> > > "guess" it (router discovery) should work for whatever access. We
> > know
> > > it does and provides a standard reference for us. Given the
> > different
> > > pictures we all have, this is perhaps the best we have as a
> > reference
> > > point.
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > >
> > > > Gary
> > > >
> > > > > -----Original Message-----
> > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > > Sent: Thursday, June 28, 2001 2:01 PM
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> > > > 'Charles
> > > > > E. Perkins'; 'seamoby@cdma-2000.org'
> > > > > Subject: Re: FW: [seamoby] CT trigger or CT completion? was:
> > > > proactive
> > > > > and re active CT definitions
> > > > >
> > > > >
> > > > >
> > > > > Hello Gary,
> > > > >
> > > > > Gary Kenward wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > To expand a bit on my previous question: what defines a
> > "default
> > > > > > router"
> > > > > > in a mobile wireless access network? This is a similar issue
> > to
> > > > > > defining
> > > > > > "what is a handoff or handover".
> > > > > >
> > > > > >
> > > > >
> > > > > Rajeev: There is standard IP router discovery that
> > > enables any node
> > > > to
> > > > > determine its default router. See RFC 2461.
> > > > >
> > > > >
> > > > > > Before everyone starts talking MIP, be reminded that the
> > > > > charter (and
> > > > > > the
> > > > > > problem statement, and the requirements) state that ct
> > > should work
> > > >
> > > > > > with
> > > > > > with different wireless networks and different mobility
> > > > > solutions and
> > > > > > not
> > > > > > just with MIP (if ct is to be an augmentation of MIP, fine,
> > let
> > > > Pat
> > > > > > rewrite
> > > > > > the charter and those of use who need to work on non-MIP ct
> > can
> > > > move
> > > > > > on).
> > > > > >
> > > > >
> > > > > Rajeev: router discovery is independent of MIP.
> > > > >
> > > > > >
> > > > > > Clearly, from the discussion that has transpired, if we
> > > all really
> > > >
> > > > > > believe
> > > > > > that defining an "event" for reactive mode in the
> requirements
> >
> > > > draft
> > > > > > is key
> > > > > > to making ct work, then we should define what a handover is.
> > As
> > > > > > everyone
> > > > > > knows by now, I do not believe it is required by for the
> > > > requirement
> > > > > > document,
> > > > > > and even more important, I suspect that a general definition
> > of
> > > > > > handover
> > > > > > will take a long time to work out. However, if the wg
> > > believes it
> > > > is
> > > > > > needed,
> > > > > > then let's make the valiant attempt.
> > > > > >
> > > > >
> > > > > Rajeev: using "default AR" as the basis would not need such a
> > > > > defintion.
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gary
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> > > > > > > Sent: Wednesday, June 27, 2001 8:28 PM
> > > > > > > To: Pat Calhoun
> > > > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> 'Charles E.
> >
> > > > > > Perkins';
> > > > > > > 'seamoby@cdma-2000.org'
> > > > > > > Subject: Re: FW: [seamoby] CT trigger or CT
> completion? was:
> >
> > > > > > proactive
> > > > > > > and re active CT definitions
> > > > > > >
> > > > > > >
> > > > > > > Pat Calhoun wrote:
> > > > > > >
> > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev
> > > Koodli wrote:
> > > >
> > > > > > > > > > >
> > > > > > > > > > > Rajeev: I guess the point is that you would
> > > do CT either
> > > >
> > > > > > > > > > >
> > > > > > > > > > > 1. before the new AR becomes the MN's default
> > > router, or
> > > >
> > > > > > > > > > > 2. after the new AR becomes the MN's
> default router
> > > > > > > > > > >
> > > > > > > > > > > Both 1) and 2) are related to handover.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The point of above text was to indicate that defining
> > > > > > > context transfer to be
> > > > > > > > > independent of handover is perhaps not
> sensible. Getting
> >
> > > > > > > it to work with
> > > > > > > > > handovers is the challenge we are peddling.
> > > > > > > > > If we all agree on this, may be we should try to
> > > > > close the issue
> > > > > > ?
> > > > > > > >
> > > > > > > > The issue I have is that the current
> definitions use some
> > > > > > > random packet destined
> > > > > > > > for the mobile as the timing "event". This, im my mind,
> > > > > > > makes no sense whatsoever,
> > > > > > > > because one side (oAR) may not know when the
> packet shows
> > > > > > > up, and therefore it
> > > > > > > > has no idea whether a reactive or proactive CT is to be
> > > > invoked.
> > > > > > > >
> > > > > > > > FWIW, some CTs will transfer L2 session keys used for
> > > > > > > authentication and
> > > > > > > > encryption, so this is where the first packet doesn't
> > > > > make sense.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Rajeev: But the above text (and the text Kulwinder sent
> > > > > > > today) does not say anything
> > > > > > > about the "first" packet. It is based on whether CT is
> > > > > > > initiated when the new AR is
> > > > > > > (not) the default router.
> > > > > > >
> > > > > > > -Rajeev
> > > > > > >
> > > > > > >
> > > > > > > > PatC
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > -Rajeev
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C100A8.5D24E7D0-- From owner-seamoby@diameter.org Fri Jun 29 11:29: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 LAA15061 for ; Fri, 29 Jun 2001 11:29:34 -0400 (EDT) Received: (qmail 24918 invoked by alias); 29 Jun 2001 15:17:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 24912 invoked by uid 200); 29 Jun 2001 15:17:42 -0000 Received: (qmail 24907 invoked from network); 29 Jun 2001 15:17:41 -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; 29 Jun 2001 15:17:41 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5TFSM001542 for ; Fri, 29 Jun 2001 11:28:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 29 Jun 2001 11:28:21 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 11:28:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DB7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby'" Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing Date: Fri, 29 Jun 2001 11:28:19 -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 In the interest of moving the requirements forward, I support the change in the definitions of "reactive" and "proactive' proposed by Pat: Reactive CT: The context transfer process which takes place subsequent to arrival of a MN's packet at the target AR Proactive CT: The context transfer process in which the required contexts are in place at the target AR prior to the arrival of MN's packet at target AR. Since these are "definitions" and not requirements, I assume that there is room for change as we delve into the design process. For what it's worth . . . Gary From owner-seamoby@diameter.org Fri Jun 29 12: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 MAA16403 for ; Fri, 29 Jun 2001 12:04:13 -0400 (EDT) Received: (qmail 25530 invoked by alias); 29 Jun 2001 15:51:29 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25524 invoked by uid 200); 29 Jun 2001 15:51:29 -0000 Received: (qmail 25515 invoked from network); 29 Jun 2001 15:51:27 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Jun 2001 15:51:27 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 14:57:48 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F809B@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Youngjune Lee Gwon'" , Emil Sturniolo Cc: Kulwinder Atwal , James Kempf , seamoby@diameter.org, PNeumiller@meshnetworks.com Subject: RE: [seamoby] Question on 4.2 Date: Thu, 28 Jun 2001 14:57:42 -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 I suppose if AP 1 and AP 2 are assigned different IP addresses then it becomes a L3 routability problem. - Kulwinder. > -----Original Message----- > From: Youngjune Lee Gwon [mailto:gyj@dcl.docomo-usa.com] > Sent: Wednesday, June 27, 2001 7:27 PM > To: Emil Sturniolo > Cc: Kulwinder Atwal; James Kempf; seamoby@diameter.org; > PNeumiller@meshnetworks.com > Subject: RE: [seamoby] Question on 4.2 > > > I sort of agree with Emil and let me give you an example I > have thought > about. Consider the picture below to illustrate my point. > > > | <--> +----+ ========= > [] # |AP 1|---------| AR 1 |-----+ > MN | +----+ / ========= | > | / | > | / | | > | / | ------- | > | / +--|ANG 1|---+ > | +----+ / | ------- | > V |AP 2|/ | | > +----+ | | > | | > > If a MN moves from AP1 to AP2, where both APs are connected > to the same L3 > entity, AR1, there is no MIP process should be involved since > the MN does > not change in terms of MIP. > > This puts the MN's mobility support, pretty much, relying > completely on > the L2 technology of AP1 & AP2. My question is that what if > AP1 and AP2 > does not support fast/smooth handoff at L2. Does this mean > automatically > that the L3 communication during this move is disrupted, > blacked out, or > discontinuous for a short time? In other words, the choice of the L2 > technology may be crucial for the outcomes at L3? > > In any cases, independently from the L2 capability, L3 can still be > seamless without interruptions. This can be possible if L3 is aware of > what events are occurred at L2. To certain degree, I agree L3 > should also > be involved in movement matters by interacting with the lower layer. > > Maybe, this is not really the scope of SeaMoby or IETF since > this case is > within a single L3 entity while switching only between L2 entities. > > Secondly, if AP1 and AP2 are running different access technolgoies, it > gets even more interesting because there is no clear definition of L2 > handoff. It may get to a problem where L3 is choosing one > link from two > simultaneously available connections. User preference may > also come in to > play in this case. > > I just recall that L2 trigger is a special case of this L2-L3 > interaction. > At the same time, L2 trigger is a kind of L3-awaring > mechanism about the > mobility of a MN itself. > > Any thoughts? Arguments? Objections? Let me know... > > Youngjune > > On Wed, 27 Jun 2001, Emil Sturniolo wrote: > > > Kulwinder. > > > > > James, > > > > > > ... snip... > > > >1. Fast movement detection/prediction > > > > > > Well, actually, I do disagree here. > > > > > > I believe the following view more accurately reflects > > > what is going on between L2 and L3 around handover. Basically, L3 > > > is not concerned with movement, it is concerned with routability > > > changes, L2 is concerned with movement. To be more specific, L3 is > > > only concerned with movement to the extent that a movement at L2 > > > causes > > > a change in routability that requires (for MIP) a change > in CoA. If > > > movement > > > causes no change in routability, then L3 should not be involved. > > > ........ > > > > > > [Emil]. James, I'd like to add one scenario that might slightly > > change > > > the semantics, if it's within the scope of the > conversation. Most of > > > this thread has been concern with the situation where connectivity > > at > > > L2 is constant and possibly predictive. However, it has been my > > > experience that this is not truly reflective of reality. IMHO L3 > > > should be involved if a mobile node becomes detached and then > > > reattached to the same network, even though no changes in > > routability > > > may have occurred. > > > > > L3 needs to be knowledgeable of this event to at > > > least verify routability and possibly facilitate faster > recovery at > > > even higher levels in the protocol stack (slings and arrows > > welcome). > > > > I would say that L3 mobility is concerned about routability and not > > concerned with movement. > > If a router has mulitiple L2 interfaces then a change from one L2 > > interface > > to another will not affect L3. In this case, L2 can verify > > routability > > because it is still the same AR. > > > > If it is a different AR, then there is a change in > routability, and a > > need > > to inform L3 mobility. > > > > Unless, there is another case that comes to mind. > > > > - Kulwinder. > > > > [Emil] Kulwinder, what I was trying to point out is that even though > > it is still the same AR it is still useful to signal L3 that > > connectivity has been re-established. Off the top of my head, > > depending on when and the length of time that the MN was > disconnected, > > after L2 connectivity is reaffirmed, it may need to determine if its > > own addressibility is still valid Furthermore, as I said in my > > original note, this indication may also help facilitate recovery > > further up the stack. Maybe this is a different trigger that I am > > describing here, but it does seem to be consistent with > > acquisition/continuation of L2 connectivity. > > > > Cordially, > > Emil Sturniolo > > EmilS@NetMotionWireless.Com > > www.NetMotionWireless.com > > 330-723-9099 > > 330-461-0326 - Mobile/Voice Mail > > ===================== > > > > > > > > From owner-seamoby@diameter.org Fri Jun 29 12:07: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 MAA16583 for ; Fri, 29 Jun 2001 12:07:37 -0400 (EDT) Received: (qmail 25581 invoked by alias); 29 Jun 2001 15:51:40 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 25575 invoked by uid 200); 29 Jun 2001 15:51:39 -0000 Received: (qmail 25562 invoked from network); 29 Jun 2001 15:51:36 -0000 Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Jun 2001 15:51:36 -0000 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 20:43:10 -0400 Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F80A1@NEPTUNE.zucotto.com> From: Kulwinder Atwal To: "'Rajeev Koodli'" Cc: "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions Date: Thu, 28 Jun 2001 20:43:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk How is this: Pre-Discovery Context Transfer: The Context Transfer is initiated prior to the newAR discovering the MN. Post-Discovery Transfer: The Context Transfer is initiated after the newAR discovers the MN. Note that I am not saying anything about how, or at what layer the newAR discovers the MN. -Kulwinder. From owner-seamoby@diameter.org Fri Jun 29 14:16: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 OAA21769 for ; Fri, 29 Jun 2001 14:16:29 -0400 (EDT) Received: (qmail 27248 invoked by alias); 29 Jun 2001 18:04:22 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27242 invoked by uid 200); 29 Jun 2001 18:04:21 -0000 Received: (qmail 27229 invoked by uid 500); 29 Jun 2001 18:04:18 -0000 Date: Fri, 29 Jun 2001 11:04:18 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Gary Kenward , Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010629110418.J25503@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Gary Kenward , Pat Calhoun , Kulwinder Atwal , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <9FBD322B7824D511B36900508BF93C9C9F5DAE@zcard031.ca.nortel.com> <3B3B77B5.EFC49A71@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3B77B5.EFC49A71@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Thu, Jun 28, 2001 at 11:30:13AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 28, 2001 at 11:30:13AM -0700, Rajeev Koodli wrote: > > And that "standard router discovery" works for mobile access? > > I don't know what you mean, but, if it is in a standards track RFC, I > "guess" it (router discovery) should work for whatever access. We know > it does and provides a standard reference for us. Given the different > pictures we all have, this is perhaps the best we have as a reference > point. If you are talking about router discovery, then I will have to respectfully disagree. This is far from what I call "fast". In fact, there are many optimizations that can be done at the link layer that eliminate the need for over the air messages that would otherwise occur prior to a CT. PatC From owner-seamoby@diameter.org Fri Jun 29 14:20:40 2001 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21929 for ; Fri, 29 Jun 2001 14:20:40 -0400 (EDT) Received: (qmail 27557 invoked by alias); 29 Jun 2001 18:06:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27550 invoked by uid 200); 29 Jun 2001 18:06:08 -0000 Received: (qmail 27534 invoked by uid 500); 29 Jun 2001 18:06:04 -0000 Date: Fri, 29 Jun 2001 11:06:04 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Gary Kenward , Kulwinder Atwal , "'Pat Calhoun'" , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010629110604.K25503@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Gary Kenward , Kulwinder Atwal , 'Pat Calhoun' , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <9FBD322B7824D511B36900508BF93C9C9F5DAF@zcard031.ca.nortel.com> <3B3B9C90.4D20E947@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3B9C90.4D20E947@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Thu, Jun 28, 2001 at 02:07:28PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk On Thu, Jun 28, 2001 at 02:07:28PM -0700, Rajeev Koodli wrote: > It is puzzling to me that you would agree with the logic and yet do not > understand what constitutes IP router discovery! It is a procedure that > all IP nodes do as part of bootstrapping their interfaces, including > when they change networks. Simply put, if you changed AR, you would be > doing router discovery. Who is proposing to add more messages over the > air interface? I believe what folks are talking about is that CT can occur before neighbor discovery is even performed. This is true in the fast MIPv4 draft, and in the newly advertised BETH draft for MIPv6. We cannot rule these scenarios out. PatC From owner-seamoby@diameter.org Fri Jun 29 14:23: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 OAA22058 for ; Fri, 29 Jun 2001 14:23:40 -0400 (EDT) Received: (qmail 27920 invoked by alias); 29 Jun 2001 18:09:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 27915 invoked by uid 200); 29 Jun 2001 18:09:13 -0000 Received: (qmail 27902 invoked by uid 500); 29 Jun 2001 18:09:09 -0000 Date: Fri, 29 Jun 2001 11:09:09 -0700 From: Pat Calhoun To: Rajeev Koodli Cc: Gary Kenward , Pat Calhoun , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions Message-ID: <20010629110909.L25503@charizard.diameter.org> Mail-Followup-To: Rajeev Koodli , Gary Kenward , Pat Calhoun , Kulwinder Atwal , 'Nakhjiri Madjid-MNAKHJI1' , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" References: <9FBD322B7824D511B36900508BF93C9C9F5DB0@zcard031.ca.nortel.com> <3B3BAFF8.58E88588@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3BAFF8.58E88588@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Thu, Jun 28, 2001 at 03:30:16PM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk > > much as possible as early as possible. The latter includes reacting as > > soon > > as possible to an on-going handover as much as it means being > > proactive about > > possible handovers. > > > > MN triggers, router discovery, etc. don't fit my goal of providing no > > degradation to the user service. > > > > Yet, I don't think you understand what constitutes router discovery. > This is not something I am proposing new. I guess your definition of > seamlessness includes not doing router discovery, which is quite > puzzling.. How does a MN identify its default router and that it is on > its default router then ? There is an IETF RFC which is implemented in > numerous nodes. I would have to guess that you would not comply with it. I honestly do not see why a mobile needs to do neighbor discovery in order for two ARs to initiate a CT. If CT is mobile initiated, then I would agree, but this is just one method of trigerring CT, not the general rule. > - I am not proposing new messages over the air interface. I would > appreciate it if you could understand that and stop saying it. Gary isn't. He is just stating that there are altenative methods of triggering CT. router discovery is one, and using L2 signalling is another. PatC From owner-seamoby@diameter.org Fri Jun 29 14:27: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 OAA22114 for ; Fri, 29 Jun 2001 14:27:28 -0400 (EDT) Received: (qmail 28765 invoked by alias); 29 Jun 2001 18:15:21 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28759 invoked by uid 200); 29 Jun 2001 18:15:21 -0000 Received: (qmail 28754 invoked by uid 500); 29 Jun 2001 18:15:19 -0000 Date: Fri, 29 Jun 2001 11:15:19 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] my availability Message-ID: <20010629111518.M25503@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, I feel like we are converging on all points, with the exception of the proactive/reactive terminology. I suspect that we will need to put aside some time at the IETF for some face to face time to get this ironed out. In any case, next week I will not be available, and will attempt to catch up to discussions on the 7/9. Thanks, PatC From owner-seamoby@diameter.org Fri Jun 29 21:04: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 VAA29273 for ; Fri, 29 Jun 2001 21:03:58 -0400 (EDT) Received: (qmail 31213 invoked by alias); 30 Jun 2001 00:51:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31207 invoked by uid 200); 30 Jun 2001 00:51:53 -0000 Received: (qmail 31202 invoked from network); 30 Jun 2001 00:51:51 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Jun 2001 00:51:51 -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 SAA00655; Fri, 29 Jun 2001 18:02:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5U12lR21885; Fri, 29 Jun 2001 18:02:47 -0700 X-mProtect: Fri, 29 Jun 2001 18:02:47 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdUdNTmL; Fri, 29 Jun 2001 18:02:46 PDT Message-ID: <3B3D2537.E6B0C68@iprg.nokia.com> Date: Fri, 29 Jun 2001 18:02:47 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: Gary Kenward , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DAE@zcard031.ca.nortel.com> <3B3B77B5.EFC49A71@iprg.nokia.com> <20010629110418.J25503@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > On Thu, Jun 28, 2001 at 11:30:13AM -0700, Rajeev Koodli wrote: > > > And that "standard router discovery" works for mobile access? > > > > I don't know what you mean, but, if it is in a standards track RFC, I > > "guess" it (router discovery) should work for whatever access. We know > > it does and provides a standard reference for us. Given the different > > pictures we all have, this is perhaps the best we have as a reference > > point. > > If you are talking about router discovery, then I will have to respectfully > disagree. This is far from what I call "fast". In fact, there are many > optimizations that can be done at the link layer that eliminate the need > for over the air messages that would otherwise occur prior to a CT. Pat, the point is _when_ the MN determines that it has changed its default router. A standard mechanism exists to determine this. If you wish to rely on your own, it is up to you. In any case, the marker is when the MN determines that it has changed its default router. Any CT that happens subsequent to that event is post-something CT. Granted that this is not fast compared to the "other" CT. However, this is a taxonomy issue, not a performance aspect. [note: why is this post-X CT useful ? Well, in some scenarios, it is the only way the MN determines that it has changed its AR. Present day MIP, inter-technology handovers come to mind] Regards, -Rajeev > > > PatC From owner-seamoby@diameter.org Fri Jun 29 21:16: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 VAA29408 for ; Fri, 29 Jun 2001 21:16:49 -0400 (EDT) Received: (qmail 31797 invoked by alias); 30 Jun 2001 01:04:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31791 invoked by uid 200); 30 Jun 2001 01:04:45 -0000 Received: (qmail 31786 invoked from network); 30 Jun 2001 01:04:43 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Jun 2001 01:04:43 -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 SAA01347; Fri, 29 Jun 2001 18:15:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5U1FeG27499; Fri, 29 Jun 2001 18:15:40 -0700 X-mProtect: Fri, 29 Jun 2001 18:15:40 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdFQs28V; Fri, 29 Jun 2001 18:15:39 PDT Message-ID: <3B3D283B.ACB773A9@iprg.nokia.com> Date: Fri, 29 Jun 2001 18:15:39 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: Gary Kenward , Kulwinder Atwal , "'Nakhjiri Madjid-MNAKHJI1'" , "'Charles E. Perkins'" , "'seamoby@cdma-2000.org'" Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions References: <9FBD322B7824D511B36900508BF93C9C9F5DB0@zcard031.ca.nortel.com> <3B3BAFF8.58E88588@iprg.nokia.com> <20010629110909.L25503@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > > much as possible as early as possible. The latter includes reacting as > > > soon > > > as possible to an on-going handover as much as it means being > > > proactive about > > > possible handovers. > > > > > > MN triggers, router discovery, etc. don't fit my goal of providing no > > > degradation to the user service. > > > > > > > Yet, I don't think you understand what constitutes router discovery. > > This is not something I am proposing new. I guess your definition of > > seamlessness includes not doing router discovery, which is quite > > puzzling.. How does a MN identify its default router and that it is on > > its default router then ? There is an IETF RFC which is implemented in > > numerous nodes. I would have to guess that you would not comply with it. > > I honestly do not see why a mobile needs to do neighbor discovery in order > for two ARs to initiate a CT. If CT is mobile initiated, then I would agree, > but this is just one method of trigerring CT, not the general rule. > CT is done when a MN changes its ARs right ? We all agree that we can figure out who the target AR is for a lot of cases. When it is not possible to figure out the target AR before the MN goes there, what do you rely on ? One argument is that establishing a new L2 is sufficient to start CT. However, my question is how do you, for sure, determine that you have changed the AR when a new L2 is established ? One definitive marker is when the MN determines that it has changed its default AR. This marker can be spotted using standard router discovery. If you have other means, you could try (and err). The general value of the above proposal is that all that "good" CT can be put under the case when the MN has not changed its default AR. The remaining cases are under the "Post"-something case. > > > - I am not proposing new messages over the air interface. I would > > appreciate it if you could understand that and stop saying it. > > Gary isn't. He is just stating that there are altenative methods of > triggering CT. router discovery is one, and using L2 signalling is another. > Well, I am saying that we use router discovery as the marker to classify CT. Could you explain how changing into a new link(and hence a L2 trigger) necesssarily guarantees that the MN has changed its default router (which is when CT is done) ? -Rajeev > > PatC From owner-seamoby@diameter.org Fri Jun 29 21:21: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 VAA29460 for ; Fri, 29 Jun 2001 21:21:36 -0400 (EDT) Received: (qmail 32271 invoked by alias); 30 Jun 2001 01:09:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32266 invoked by uid 200); 30 Jun 2001 01:09:52 -0000 Received: (qmail 32260 invoked from network); 30 Jun 2001 01:09:50 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Jun 2001 01:09:50 -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 SAA01656; Fri, 29 Jun 2001 18:20:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5U1Klm30716; Fri, 29 Jun 2001 18:20:47 -0700 X-mProtect: Fri, 29 Jun 2001 18:20:47 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdwPhHqF; Fri, 29 Jun 2001 18:20:46 PDT Message-ID: <3B3D296D.E7E442C5@iprg.nokia.com> Date: Fri, 29 Jun 2001 18:20:45 -0700 From: Rajeev Koodli 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: Pat Calhoun CC: seamoby@cdma-2000.org Subject: Re: [seamoby] my availability References: <20010629111518.M25503@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit This meeting is probably a good idea.. Anyway, I am off next week as well, so be kind by keeping the traffic low on the list :-) Regards, -Rajeev Pat Calhoun wrote: > All, > > I feel like we are converging on all points, with the exception of the > proactive/reactive terminology. I suspect that we will need to put aside > some time at the IETF for some face to face time to get this ironed out. > > In any case, next week I will not be available, and will attempt to > catch up to discussions on the 7/9. > > Thanks, > > PatC