From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 03:49:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25845
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 03:49:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D123F80@standards.nortelnetworks.com>; Wed, 1 Mar 2000 3:44:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64876 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 03:42:47 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.359EC650@standards.nortelnetworks.com>; Wed, 1 Mar 2000 3:42:47
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA29291; Wed, 1 Mar
          2000 10:46:15 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com
          [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP
          id KAA29113; Wed, 1 Mar 2000 10:46:10 +0200 (EET)
Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id <GCKLPBNY>;
          Wed, 1 Mar 2000 10:46:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F99688F120B6D211B0D70008C7D9B3CB033375A6@eseis07nok>
Date:         Wed, 1 Mar 2000 10:46:05 +0200
Reply-To: patrik.flykt@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrik Flykt <patrik.flykt@NOKIA.COM>
Subject:      Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt
X-To:         kleung@CISCO.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        Hello,

The same will apply to the NVSE, I suppose ?

Regards,

        Patrik

> -----Original Message-----
> From: EXT Kent K. Leung [mailto:kleung@CISCO.COM]
> Sent: 26. January 2000 8:24
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt
>
>
> Sure, no problem.  Will update draft.  Thanks.
>
> -- Kent --
>
> >
> > yes, but we (many of us) repetedly requested that the MIER
> length be aligned,
> > and you can bet that the MIER draft will be stopped during
> WG last call
> > because this was never addressed. Perhaps this requires a
> separate thread
> > on the subject, but I am just tired to stating the same
> thing over and
> > over and over .... (get the picture :).
> >
> > So, while I agree that CVSE is not an authentication extension,
> > alignment is good. alignment is my friend, and I would really like
> > people to take that into account, when possible, during protocol
> > design.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 04:14:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26278
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 04:14:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.22847F70@standards.nortelnetworks.com>; Wed, 1 Mar 2000 4:10:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64958 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 04:08:54 -0500
Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.DB9DB5E0@standards.nortelnetworks.com>;
          Wed, 1 Mar 2000 4:08:54 -0500
Received: from akaatti.hut.fi (tweckstr@akaatti.hut.fi [130.233.249.61]) by
          tiku.hut.fi (8.9.3/8.9.3) with ESMTP id LAA01834; Wed, 1 Mar 2000
          11:12:20 +0200 (EET)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Message-ID:  <Pine.OSF.4.10.10003011111420.13643-100000@akaatti.hut.fi>
Date:         Wed, 1 Mar 2000 11:12:20 +0200
Reply-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= <tweckstr@CC.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= <tweckstr@CC.HUT.FI>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000229185333.G27822@bell-labs.com>
Content-Transfer-Encoding: 8BIT

Hello folks.


On Tue, 29 Feb 2000, Luca Salgarelli wrote:

lsalga >Hi Emad.
lsalga >
lsalga >>            So why is the current charter not sufficient for addressing
lsalga >>    the interest by the cellular interest?
lsalga >
lsalga >Personally, I think that one of the work items that are missing from the
lsalga >charter (wrt cellular/wireless) is support for fast handover: this should
lsalga >be a must for the use of MIP not only in cellular networks, but in any
lsalga >wireless network where QoS counts.

I totally agree.

Regards,
        Tom


lsalga >
lsalga >Regards
lsalga >Luca
lsalga >
lsalga >>
lsalga >>            I understand that the MIP WG is interested in getting MIP
lsalga >>    deployed over cellular or other technologies. However, my personal
lsalga >>    view is: if we mandate the Cellular support as a requirement in the
lsalga >>    charter, it may become more of a "MIP for Cellular WG" than general
lsalga >>    MIP solution.
lsalga >

--
        Tom Weckström           tweckstr@cc.hut.fi
        Otakaari 20 B 39        Helsinki University of Technology
        02150 Espoo             Department of Computer Science
        09-4683249/040-5642709  http://www.niksula.cs.hut.fi/~tweckstr


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 06:25:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27872
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 06:25:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55F174A0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 6:21:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65148 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 06:19:51 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.C0F771C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 6:09:50
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA27609; Wed, 1 Mar 2000 06:13:15
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003011113.GAA27609@ietf.org>
Date:         Wed, 1 Mar 2000 06:13:15 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-rfc2344-bis-01.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Reverse Tunneling for Mobile IP, revised
        Author(s)       : G. Montenegro
        Filename        : draft-ietf-mobileip-rfc2344-bis-01.txt
        Pages           : 27
        Date            : 29-Feb-00

Mobile IP uses tunneling from the home agent to the mobile
node's care-of address, but rarely in the reverse direction.
Usually, a mobile node sends its packets through a router on the
foreign network, and assumes that routing is independent of
source address.  When this assumption is not true, it is
convenient to establish a topologically correct reverse tunnel
from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile
IP to support topologically correct reverse tunnels.  This
document does not attempt to solve the problems posed by
firewalls located between the home agent and the mobile node's
care-of address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-rfc2344-bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000229105719.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-rfc2344-bis-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000229105719.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 08:27:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00336
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 08:27:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.438B9DC0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 8:22:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65287 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 08:20:49 -0500
Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0CCFC680@standards.nortelnetworks.com>; Wed, 1 Mar 2000 8:20:49
          -0500
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com
          [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with
          ESMTP id HAA15992 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed,
          1 Mar 2000 07:24:18 -0600 (CST)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service
          (5.5.2650.21) id <F7X4DDFA>; Wed, 1 Mar 2000 07:24:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <2D11BCC7FFD8D3118FD70000D1ECDC883A11F4@pkcexv018.sprintspectrum.com>
Date:         Wed, 1 Mar 2000 07:24:17 -0600
Reply-To: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think the charter should be updated to support cellular specific
extensions.

Mark A. Lipford
Manager, Wireless Industry Standards - Data
Sprint PCS
8001 College Blvd.; Suite 210
Overland Park, KS  66210
(913) 664-8335 (office)
(913) 664-8440 (fax)
(913) 226-9060 (PCS)


-----Original Message-----
From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
Sent: Tuesday, February 29, 2000 5:14 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] charter update?


Greetings gentlepeople,

    We've got 4 presentations lined up at the Adelaide meeting on various
proposals for handoff.  This together with the fact that several of our
current drafts are motivated by 3G data support indicates to Raj and me that
there continues to be some interest in the group in supporting cellular
specific extensions to mobile-ip.  The charter doesn't specify a strong
support of these activities.  The current wording is "The WG moving forward
will focus on deployment issues in Mobile IP and provide appropriate
protocol solutions to address known deficiencies and shortcomings. For
example, the wireless/cellular industry is considering using Mobile IP as
one technique for IP mobility for wireless data. The working group will
endeavor to gain an understanding of data service in cellular systems such
as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
trying to adopt and deploy Mobile IP WG protocols in these contexts."
So I'd like to find out whether there is interest in the group to extending
the charter for specific support of cellular systems.  If there is general
support I'll propose some wording.  One obvious work item would be to submit
a draft to the IESG for support of fast handover.

Comments?
Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 08:53:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01348
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 08:53:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CBC41B0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 8:49:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65357 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 08:48:26 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.82FB52A0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 8:38:26
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF21@monza.broadswitch.com>
Date:         Wed, 1 Mar 2000 14:41:50 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I would like it to be more generic and introduce more clear interfaces that
today...

For instance a micro mobility message type and then it should be very easy
to introduce new mobility managemnt scheme that is optimized over (new)
access networks..

So it should be a IP based mobility management protocol with mobile IP as a
base and have clear interfaces between:
-pico mobility (mostly done in MANET today)
-micromobility (cellular IP, Hawaii etc...)
-macromobility (hierahcical mobile IP..)
-roaming       (AAA)

The micromobility SHOULD be optimized for different access network where the
cellular radio access network is one category that have several types (tdma,
cdma, w-cdma, etc..), another is high capacity LAN radio like 802.11,
HiperLAN etc and these different access networks requires different mobility
management protocol...

If you had clear interfaces and defined message types that is extendable you
could have a very nice flexible protocol that could easy adapt to new
networks when they come...

I think that people agree since they are working on new mobility solutions
and if you had a good mobility mamagement framework that is flexible, but
then people have to agree on the framework...

Best Regards Thomas

> -----Original Message-----
> From: Lipford, Mark [mailto:MLipfo01@SPRINTSPECTRUM.COM]
> Sent: Wednesday, March 01, 2000 2:24 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
>
> I think the charter should be updated to support cellular specific
> extensions.
>
> Mark A. Lipford
> Manager, Wireless Industry Standards - Data
> Sprint PCS
> 8001 College Blvd.; Suite 210
> Overland Park, KS  66210
> (913) 664-8335 (office)
> (913) 664-8440 (fax)
> (913) 226-9060 (PCS)
>
>
> -----Original Message-----
> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> Sent: Tuesday, February 29, 2000 5:14 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] charter update?
>
>
> Greetings gentlepeople,
>
>     We've got 4 presentations lined up at the Adelaide
> meeting on various
> proposals for handoff.  This together with the fact that
> several of our
> current drafts are motivated by 3G data support indicates to
> Raj and me that
> there continues to be some interest in the group in
> supporting cellular
> specific extensions to mobile-ip.  The charter doesn't
> specify a strong
> support of these activities.  The current wording is "The WG
> moving forward
> will focus on deployment issues in Mobile IP and provide appropriate
> protocol solutions to address known deficiencies and shortcomings. For
> example, the wireless/cellular industry is considering using
> Mobile IP as
> one technique for IP mobility for wireless data. The working
> group will
> endeavor to gain an understanding of data service in cellular
> systems such
> as GPRS, UMTS, CDMA2000, and interact with other standards
> bodies that are
> trying to adopt and deploy Mobile IP WG protocols in these contexts."
> So I'd like to find out whether there is interest in the
> group to extending
> the charter for specific support of cellular systems.  If
> there is general
> support I'll propose some wording.  One obvious work item
> would be to submit
> a draft to the IESG for support of fast handover.
>
> Comments?
> Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:09:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01962
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:09:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BC0B1A0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:05:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65416 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:03:35 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.A0B1C250@standards.nortelnetworks.com>;
          Wed, 1 Mar 2000 8:53:35 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id GAA28488; Wed, 1 Mar 2000 06:56:34
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.105.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id FAA24715; Wed, 1 Mar
          2000 05:55:33 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          FAA04998; Wed, 1 Mar 2000 05:55:32 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.951918932.11782.pcalhoun@ha1mpk-mail>
Date:         Wed, 1 Mar 2000 05:55:32 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <2D11BCC7FFD8D3118FD70000D1ECDC883A11F4@pkcexv018.sprintspectrum.com>

All,

I find it difficult to justify NOT updating the draft to include cellular
specific extensions. As many of you know, Mobile IP has been in RFC form for
quite some time now, and until the cellular folks decided to adopt it, we
really didn't have much deployment. If cellular is the killer Mobile IP
service, then we should do what we can to help make Mobile IP successful.

PatC

> I think the charter should be updated to support cellular specific
> extensions.
>
> Mark A. Lipford
> Manager, Wireless Industry Standards - Data
> Sprint PCS
> 8001 College Blvd.; Suite 210
> Overland Park, KS  66210
> (913) 664-8335 (office)
> (913) 664-8440 (fax)
> (913) 226-9060 (PCS)
>
>
> -----Original Message-----
> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> Sent: Tuesday, February 29, 2000 5:14 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] charter update?
>
>
> Greetings gentlepeople,
>
>     We've got 4 presentations lined up at the Adelaide meeting on various
> proposals for handoff.  This together with the fact that several of our
> current drafts are motivated by 3G data support indicates to Raj and me that
> there continues to be some interest in the group in supporting cellular
> specific extensions to mobile-ip.  The charter doesn't specify a strong
> support of these activities.  The current wording is "The WG moving forward
> will focus on deployment issues in Mobile IP and provide appropriate
> protocol solutions to address known deficiencies and shortcomings. For
> example, the wireless/cellular industry is considering using Mobile IP as
> one technique for IP mobility for wireless data. The working group will
> endeavor to gain an understanding of data service in cellular systems such
> as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
> trying to adopt and deploy Mobile IP WG protocols in these contexts."
> So I'd like to find out whether there is interest in the group to extending
> the charter for specific support of cellular systems.  If there is general
> support I'll propose some wording.  One obvious work item would be to submit
> a draft to the IESG for support of fast handover.
>
> Comments?
> Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:13:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02111
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:13:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD02D210@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:09:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65475 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:08:05 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.36897B00@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:04:55
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA06545; Wed, 1 Mar
          2000 20:06:46 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.004D088E ; Wed, 1 Mar 2000 19:31:24 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.004D06C9.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 19:33:50 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-cc:         MLipfo01@SPRINTSPECTRUM.COM,
              "basavaraj.patil.nokia.com>"@hss.hns.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi
       The grand Success of our Mobile-IP  will be there if we Support
GPRS,UMTS,CDMA2000 also,
 I would like to work in this context  with the permission or Mr.RAJ any one
interested Pl  update me .

Best Regards
Sirish














I think the charter should be updated to support cellular specific
extensions.

Mark A. Lipford
Manager, Wireless Industry Standards - Data
Sprint PCS
8001 College Blvd.; Suite 210
Overland Park, KS  66210
(913) 664-8335 (office)
(913) 664-8440 (fax)
(913) 226-9060 (PCS)


-----Original Message-----
From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
Sent: Tuesday, February 29, 2000 5:14 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] charter update?


Greetings gentlepeople,

    We've got 4 presentations lined up at the Adelaide meeting on various
proposals for handoff.  This together with the fact that several of our
current drafts are motivated by 3G data support indicates to Raj and me that
there continues to be some interest in the group in supporting cellular
specific extensions to mobile-ip.  The charter doesn't specify a strong
support of these activities.  The current wording is "The WG moving forward
will focus on deployment issues in Mobile IP and provide appropriate
protocol solutions to address known deficiencies and shortcomings. For
example, the wireless/cellular industry is considering using Mobile IP as
one technique for IP mobility for wireless data. The working group will
endeavor to gain an understanding of data service in cellular systems such
as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
trying to adopt and deploy Mobile IP WG protocols in these contexts."
So I'd like to find out whether there is interest in the group to extending
the charter for specific support of cellular systems.  If there is general
support I'll propose some wording.  One obvious work item would be to submit
a draft to the IESG for support of fast handover.

Comments?
Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:19:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02281
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:19:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5FB1A00@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:15:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65430 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:13:57 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.13AFD1B0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:03:57
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id GAA06558; Wed, 1 Mar 2000 06:07:24
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.91.34]) by engmail2.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA29712; Wed, 1 Mar
          2000 06:07:23 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA12842; Wed, 1 Mar 2000 06:07:23 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.951919643.19090.pcalhoun@ha1mpk-mail>
Date:         Wed, 1 Mar 2000 06:07:23 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <45AFD48D077ED211BB4700A0C9DCE8FD15AF21@monza.broadswitch.com>

All,

I had a conversation yesterday with Charlie and we both agreed that we need to
define the different layers of mobility. Today we use micro and macro
mobility, and these terms mean completely different things, depending upon the
proposal that you happen to be backing. Therefore, having agreement on the
list as to what micro vs. macro means will be a long, drawn out battle, and I
think that we have better things to do with out time (well, at least I do).

btw, in case you still aren't convinced, it isn't clear to me that what we
today call micro-mobility cannot be achieved via hierarchical Mobile IP, while
others believe that Hawaii or Cellular IP provides micro-mobility.

So, I would like to propose that we agree on some new terminology. I believe
that we have: - Link Layer Mobility (Inter-BTS hand-off)
- pick a name Mobility (inter-BSC hand-off)
- Intra-Domain Mobility (Inter-MSC hand-off)
- Inter-Domain Mobility (when the hand-off crosses a domain boundary)

I still don't have a preference for the second name, and I am not married to
ANY of the names above. These are merely suggestions. The goal here is to ALL
agree on basic terminology so that when we compare protocols, we can match the
protocol against a set of common terminology.

Comments? Is this a worthwhile exercise?

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:28:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02543
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:28:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D899C0B0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:23:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65523 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:22:36 -0500
Received: from mailgw2.netvision.net.il (194.90.1.9) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.47B65780@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:12:34
          -0500
Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il
          [199.203.174.65]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with
          ESMTP id QAA19303 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed,
          1 Mar 2000 16:15:57 +0200 (IST)
Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2]) by
          sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id QAA20881 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar 2000 16:16:30
          +0200
Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id
          <1RMLNZYD>; Wed, 1 Mar 2000 16:15:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <CE835E918749D21191B10060084C377E01B5DEB7@ismail1.icomverse.com>
Date:         Wed, 1 Mar 2000 16:15:46 +0200
Reply-To: "Klein, Eric" <Eric_Klein@STARHOME.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Klein, Eric" <Eric_Klein@STARHOME.COM>
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,

I would have to agree with Pat and Mark, today the biggest push for
mobile-IP will be the cellular market. What we need to take into account is
both cellular data and WAP applications. This is a real hot topic right now
with Microsoft, AOL, and Yahoo trying to take the dominate position for
configuration and portals. These areas are now in the same stage that BBS'
were 10 years ago with different rules and speeds. As these all will be
using some form of IP we should look at a way to integrate all of them into
both the charter and the final recommendations and standards.

  Eric Klein
  Network Specialist
  star*home, a Comverse Company

  Phone:  +972 (3) 765-5793
  Cell:    +972 (51) 232-375
  Fax:    +972 (3) 765-5688
  Email:   eric_klein@starhome.com
  Web:    http:/www.starhome.com

-----Original Message-----
From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
Sent: Wednesday, March 01, 2000 3:56 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] charter update?


All,

I find it difficult to justify NOT updating the draft to include cellular
specific extensions. As many of you know, Mobile IP has been in RFC form for
quite some time now, and until the cellular folks decided to adopt it, we
really didn't have much deployment. If cellular is the killer Mobile IP
service, then we should do what we can to help make Mobile IP successful.

PatC

> I think the charter should be updated to support cellular specific
> extensions.
>
> Mark A. Lipford
> Manager, Wireless Industry Standards - Data
> Sprint PCS
> 8001 College Blvd.; Suite 210
> Overland Park, KS  66210
> (913) 664-8335 (office)
> (913) 664-8440 (fax)
> (913) 226-9060 (PCS)
>
>
> -----Original Message-----
> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> Sent: Tuesday, February 29, 2000 5:14 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] charter update?
>
>
> Greetings gentlepeople,
>
>     We've got 4 presentations lined up at the Adelaide meeting on various
> proposals for handoff.  This together with the fact that several of our
> current drafts are motivated by 3G data support indicates to Raj and me
that
> there continues to be some interest in the group in supporting cellular
> specific extensions to mobile-ip.  The charter doesn't specify a strong
> support of these activities.  The current wording is "The WG moving
forward
> will focus on deployment issues in Mobile IP and provide appropriate
> protocol solutions to address known deficiencies and shortcomings. For
> example, the wireless/cellular industry is considering using Mobile IP as
> one technique for IP mobility for wireless data. The working group will
> endeavor to gain an understanding of data service in cellular systems such
> as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
> trying to adopt and deploy Mobile IP WG protocols in these contexts."
> So I'd like to find out whether there is interest in the group to
extending
> the charter for specific support of cellular systems.  If there is general
> support I'll propose some wording.  One obvious work item would be to
submit
> a draft to the IESG for support of fast handover.
>
> Comments?
> Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:40:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02969
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:40:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ACDE9D40@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:36:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65644 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:35:15 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0CF33DF0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:25:14
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF28@monza.broadswitch.com>
Date:         Wed, 1 Mar 2000 15:28:43 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I glad we speak the same languague...
I totally agree with you.

I have tried to raise this question 1,5 year ago but with very little
reponse...

But I dont like you grouping with names very specific to cellular sytems
like BTS BSC and MSC
But I agree on the "levels"
But I would also like the level of personal network or pico mobility where
the typical scenario is the wireless router with a lot of bluetooth links...

> Link Layer Mobility (Inter-BTS hand-off)
> - pick a name Mobility (inter-BSC hand-off)
These two I would grouped together like micro mobility because they have the
same access network!!

In other word the could have the same L2 segment...

And the BTS is just a "wireless bridge" and could be an access point for a
wireless LAN for instance...

And in cellular sytems for instance it is very difficult to break up this
that why I think it should go under a common micro-mobility
And if it is a wirelles LAN access ponit you probably have a ethernet switch
connecting all your access points and 802.1Q ethernet gives you local
mobility...

But clear interfaces is a must.

/Thomas


> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> Sent: Wednesday, March 01, 2000 3:07 PM
> To: Thomas Eklund
> Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Terminology (was: [MOBILE-IP] charter update?)
>
>
> All,
>
> I had a conversation yesterday with Charlie and we both
> agreed that we need to
> define the different layers of mobility. Today we use micro and macro
> mobility, and these terms mean completely different things,
> depending upon the
> proposal that you happen to be backing. Therefore, having
> agreement on the
> list as to what micro vs. macro means will be a long, drawn
> out battle, and I
> think that we have better things to do with out time (well,
> at least I do).
>
> btw, in case you still aren't convinced, it isn't clear to me
> that what we
> today call micro-mobility cannot be achieved via hierarchical
> Mobile IP, while
> others believe that Hawaii or Cellular IP provides micro-mobility.
>
> So, I would like to propose that we agree on some new
> terminology. I believe
> that we have: - Link Layer Mobility (Inter-BTS hand-off)
> - pick a name Mobility (inter-BSC hand-off)
> - Intra-Domain Mobility (Inter-MSC hand-off)
> - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>
> I still don't have a preference for the second name, and I am
> not married to
> ANY of the names above. These are merely suggestions. The
> goal here is to ALL
> agree on basic terminology so that when we compare protocols,
> we can match the
> protocol against a set of common terminology.
>
> Comments? Is this a worthwhile exercise?
>
> PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:44:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03130
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:44:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F52FCC40@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:38:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65670 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:37:27 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5C003600@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:27:27
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF29@monza.broadswitch.com>
Date:         Wed, 1 Mar 2000 15:30:55 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

And dont forget to also be more IPv6 centric since the cellular sytems would
never be able to grow to their estimated billions of users if its not IPv6
based...

/Thomas
> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@HA1MPK-MAIL.ENG.SUN.COM]
> Sent: Wednesday, March 01, 2000 2:56 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
>
> All,
>
> I find it difficult to justify NOT updating the draft to
> include cellular
> specific extensions. As many of you know, Mobile IP has been
> in RFC form for
> quite some time now, and until the cellular folks decided to
> adopt it, we
> really didn't have much deployment. If cellular is the killer
> Mobile IP
> service, then we should do what we can to help make Mobile IP
> successful.
>
> PatC
>
> > I think the charter should be updated to support cellular specific
> > extensions.
> >
> > Mark A. Lipford
> > Manager, Wireless Industry Standards - Data
> > Sprint PCS
> > 8001 College Blvd.; Suite 210
> > Overland Park, KS  66210
> > (913) 664-8335 (office)
> > (913) 664-8440 (fax)
> > (913) 226-9060 (PCS)
> >
> >
> > -----Original Message-----
> > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > Sent: Tuesday, February 29, 2000 5:14 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: [MOBILE-IP] charter update?
> >
> >
> > Greetings gentlepeople,
> >
> >     We've got 4 presentations lined up at the Adelaide
> meeting on various
> > proposals for handoff.  This together with the fact that
> several of our
> > current drafts are motivated by 3G data support indicates
> to Raj and me that
> > there continues to be some interest in the group in
> supporting cellular
> > specific extensions to mobile-ip.  The charter doesn't
> specify a strong
> > support of these activities.  The current wording is "The
> WG moving forward
> > will focus on deployment issues in Mobile IP and provide appropriate
> > protocol solutions to address known deficiencies and
> shortcomings. For
> > example, the wireless/cellular industry is considering
> using Mobile IP as
> > one technique for IP mobility for wireless data. The
> working group will
> > endeavor to gain an understanding of data service in
> cellular systems such
> > as GPRS, UMTS, CDMA2000, and interact with other standards
> bodies that are
> > trying to adopt and deploy Mobile IP WG protocols in these
> contexts."
> > So I'd like to find out whether there is interest in the
> group to extending
> > the charter for specific support of cellular systems.  If
> there is general
> > support I'll propose some wording.  One obvious work item
> would be to submit
> > a draft to the IESG for support of fast handover.
> >
> > Comments?
> > Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:47:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03242
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:47:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.880006C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:43:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65789 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:42:19 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.604791C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:41:53
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA08730; Wed, 1 Mar
          2000 20:43:20 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.0050633B ; Wed, 1 Mar 2000 20:08:02 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.005062E8.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 20:11:45 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,
        I Would certainly agree with Pat, But we can give  support for 3G Mobile
Networks, If not now  in future, cos all the world is switching towards wireless
telephony than  wired telephony.
Users cant use two devices for access for telephony and data , I will have a
word with 3G guys regarding this accept.

Best Regards
Sirish








"pcalhoun@eng.sun.com" <pcalhoun on 03/01/2000 07:25:32 PM

Please respond to "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>

To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sirish K Challagulla/HSS)

Subject:  Re: [MOBILE-IP] charter update?




All,

I find it difficult to justify NOT updating the draft to include cellular
specific extensions. As many of you know, Mobile IP has been in RFC form for
quite some time now, and until the cellular folks decided to adopt it, we
really didn't have much deployment. If cellular is the killer Mobile IP
service, then we should do what we can to help make Mobile IP successful.

PatC

> I think the charter should be updated to support cellular specific
> extensions.
>
> Mark A. Lipford
> Manager, Wireless Industry Standards - Data
> Sprint PCS
> 8001 College Blvd.; Suite 210
> Overland Park, KS  66210
> (913) 664-8335 (office)
> (913) 664-8440 (fax)
> (913) 226-9060 (PCS)
>
>
> -----Original Message-----
> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> Sent: Tuesday, February 29, 2000 5:14 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] charter update?
>
>
> Greetings gentlepeople,
>
>     We've got 4 presentations lined up at the Adelaide meeting on various
> proposals for handoff.  This together with the fact that several of our
> current drafts are motivated by 3G data support indicates to Raj and me that
> there continues to be some interest in the group in supporting cellular
> specific extensions to mobile-ip.  The charter doesn't specify a strong
> support of these activities.  The current wording is "The WG moving forward
> will focus on deployment issues in Mobile IP and provide appropriate
> protocol solutions to address known deficiencies and shortcomings. For
> example, the wireless/cellular industry is considering using Mobile IP as
> one technique for IP mobility for wireless data. The working group will
> endeavor to gain an understanding of data service in cellular systems such
> as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
> trying to adopt and deploy Mobile IP WG protocols in these contexts."
> So I'd like to find out whether there is interest in the group to extending
> the charter for specific support of cellular systems.  If there is general
> support I'll propose some wording.  One obvious work item would be to submit
> a draft to the IESG for support of fast handover.
>
> Comments?
> Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:51:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03375
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:51:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18FABDF0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:47:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65834 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:45:43 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E9579CD0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:45:43
          -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 08:48:55 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 1
          Mar 2000 09:48:28 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5XQPSZ>; Wed, 1 Mar 2000 08:48:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF838D.32E854DC"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93A6@crchy271.us.nortel.com>
Date:         Wed, 1 Mar 2000 08:48:26 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Luca Salgarelli <lsalgarelli@bell-labs.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF838D.32E854DC
Content-Type: text/plain;
        charset="iso-8859-1"

Luca,

        I don't agree that MIP should support fast handover, but is it only
directed for cellular? May be a general objective should be "support of fast
handover".

thx.

> -----Original Message-----
> From: Luca Salgarelli [mailto:lsalgarelli@bell-labs.com]
> Sent: Tuesday, February 29, 2000 5:54 PM
> To: Qaddoura, Emad [RICH2:IP10-M:EXCH]
> Cc: MOBILE-IP@standards.nortelnetworks.com
> Subject: Re: [MOBILE-IP] charter update?
>
>
> Hi Emad.
>
> >            So why is the current charter not sufficient for
> addressing
> >    the interest by the cellular interest?
>
> Personally, I think that one of the work items that are
> missing from the
> charter (wrt cellular/wireless) is support for fast handover:
> this should
> be a must for the use of MIP not only in cellular networks, but in any
> wireless network where QoS counts.
>
> Regards
> Luca
>
> >
> >            I understand that the MIP WG is interested in getting MIP
> >    deployed over cellular or other technologies. However,
> my personal
> >    view is: if we mandate the Cellular support as a
> requirement in the
> >    charter, it may become more of a "MIP for Cellular WG"
> than general
> >    MIP solution.
>

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

<!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.2651.65">
<TITLE>RE: [MOBILE-IP] charter update?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Luca,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I don't =
agree that MIP should support fast handover, but is it only directed =
for cellular? May be a general objective should be &quot;support of =
fast handover&quot;.</FONT></P>

<P><FONT SIZE=3D2>thx.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Luca Salgarelli [<A =
HREF=3D"mailto:lsalgarelli@bell-labs.com">mailto:lsalgarelli@bell-labs.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, February 29, 2000 5:54 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Qaddoura, Emad [RICH2:IP10-M:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: =
MOBILE-IP@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [MOBILE-IP] charter update?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Emad.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
So why is the current charter not sufficient for </FONT>
<BR><FONT SIZE=3D2>&gt; addressing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; the interest by the =
cellular interest?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Personally, I think that one of the work items =
that are </FONT>
<BR><FONT SIZE=3D2>&gt; missing from the</FONT>
<BR><FONT SIZE=3D2>&gt; charter (wrt cellular/wireless) is support for =
fast handover: </FONT>
<BR><FONT SIZE=3D2>&gt; this should</FONT>
<BR><FONT SIZE=3D2>&gt; be a must for the use of MIP not only in =
cellular networks, but in any</FONT>
<BR><FONT SIZE=3D2>&gt; wireless network where QoS counts.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; Luca</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I understand that the MIP WG is interested in getting MIP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; deployed over cellular =
or other technologies. However, </FONT>
<BR><FONT SIZE=3D2>&gt; my personal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; view is: if we mandate =
the Cellular support as a </FONT>
<BR><FONT SIZE=3D2>&gt; requirement in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; charter, it may become =
more of a &quot;MIP for Cellular WG&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; than general</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; MIP solution.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF838D.32E854DC--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:57:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03561
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:57:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6230CEB0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:49:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65712 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:47:51 -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D00B96B0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:37:51
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA21579 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 07:41:21
          -0700 (MST)]
Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by
          pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA04288 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 07:41:21
          -0700 (MST)]
Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id
          <F7B33C27>; Wed, 1 Mar 2000 08:41:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <51F347B016ADD011963200805FC1456204BCC063@email1.wes.mot.com>
Date:         Wed, 1 Mar 2000 08:41:17 -0600
Reply-To: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@HA1MPK-MAIL.ENG.SUN.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,

I had a conversation yesterday with Charlie and we both agreed that we need
to
define the different layers of mobility. Today we use micro and macro
mobility, and these terms mean completely different things, depending upon
the
proposal that you happen to be backing. Therefore, having agreement on the
list as to what micro vs. macro means will be a long, drawn out battle, and
I
think that we have better things to do with out time (well, at least I do).
Agreed.  In addition this will vary depending on the cellular technology one
is describing, not to mention other non-cellular mobility apps.


btw, in case you still aren't convinced, it isn't clear to me that what we
today call micro-mobility cannot be achieved via hierarchical Mobile IP,
while
others believe that Hawaii or Cellular IP provides micro-mobility.
Don't forget the 3g wireless draft as yet another means of doing this.

So, I would like to propose that we agree on some new terminology. I believe
that we have: - Link Layer Mobility (Inter-BTS hand-off)
- pick a name Mobility (inter-BSC hand-off)
- Intra-Domain Mobility (Inter-MSC hand-off)
- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
Thanks for making the proposal, and we can let the discussion on this begin.

If we can come to some reasonable consensus on some terminology which seems
to me to be a worthwhile goal, how would you like to propagate this
agreement once we've got it?  Via the charter or some informational rfc?

I still don't have a preference for the second name, and I am not married to
ANY of the names above. These are merely suggestions. The goal here is to
ALL
agree on basic terminology so that when we compare protocols, we can match
the
protocol against a set of common terminology.

Comments? Is this a worthwhile exercise?

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:57:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03566
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:57:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62B89C50@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:49:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65878 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:48:21 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.47A5C370@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:48:21
          -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 08:51:34 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 1
          Mar 2000 09:51:10 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5XQPY0>; Wed, 1 Mar 2000 08:51:09 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF838D.934CA788"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93A7@crchy271.us.nortel.com>
Date:         Wed, 1 Mar 2000 08:51:08 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF838D.934CA788
Content-Type: text/plain;
        charset="iso-8859-1"

Pat,

....

> So, I would like to propose that we agree on some new
> terminology. I believe
> that we have: - Link Layer Mobility (Inter-BTS hand-off)
> - pick a name Mobility (inter-BSC hand-off)
> - Intra-Domain Mobility (Inter-MSC hand-off)
> - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>

So are these the only mobility related technology that MIP should be
applied/used for?

> I still don't have a preference for the second name, and I am
> not married to
> ANY of the names above. These are merely suggestions. The
> goal here is to ALL
> agree on basic terminology so that when we compare protocols,
> we can match the
> protocol against a set of common terminology.
>
> Comments? Is this a worthwhile exercise?

The objective of agreeing on terminology is great. However, if we go this
specific to cellular, I may be the only one suggesting renaming the MIP WG
to "MIP For Cellular".

>
> PatC
>

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

<!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.2651.65">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter =
update?)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Pat,</FONT>
</P>

<P><FONT SIZE=3D2>....</FONT>
</P>

<P><FONT SIZE=3D2>&gt; So, I would like to propose that we agree on =
some new </FONT>
<BR><FONT SIZE=3D2>&gt; terminology. I believe</FONT>
<BR><FONT SIZE=3D2>&gt; that we have: - Link Layer Mobility (Inter-BTS =
hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; - pick a name Mobility (inter-BSC =
hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; - Intra-Domain Mobility (Inter-MSC =
hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; - Inter-Domain Mobility (when the hand-off =
crosses a domain boundary)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>So are these the only mobility related technology =
that MIP should be applied/used for?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I still don't have a preference for the second =
name, and I am </FONT>
<BR><FONT SIZE=3D2>&gt; not married to</FONT>
<BR><FONT SIZE=3D2>&gt; ANY of the names above. These are merely =
suggestions. The </FONT>
<BR><FONT SIZE=3D2>&gt; goal here is to ALL</FONT>
<BR><FONT SIZE=3D2>&gt; agree on basic terminology so that when we =
compare protocols, </FONT>
<BR><FONT SIZE=3D2>&gt; we can match the</FONT>
<BR><FONT SIZE=3D2>&gt; protocol against a set of common =
terminology.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comments? Is this a worthwhile exercise?</FONT>
</P>

<P><FONT SIZE=3D2>The objective of agreeing on terminology is great. =
However, if we go this specific to cellular, I may be the only one =
suggesting renaming the MIP WG to &quot;MIP For =
Cellular&quot;.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF838D.934CA788--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 09:57:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03578
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 09:57:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB8A9410@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:51:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 65752 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:50:09 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.221D1C30@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:40:09
          -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id GAA20396; Wed, 1 Mar 2000 06:43:36
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.61.34]) by engmail1.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA03155; Wed, 1 Mar
          2000 06:43:35 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA06331; Wed, 1 Mar 2000 06:43:34 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.951921814.2823.pcalhoun@ha1mpk-mail>
Date:         Wed, 1 Mar 2000 06:43:34 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Thomas Eklund <thomas.eklund@switchcore.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <45AFD48D077ED211BB4700A0C9DCE8FD15AF28@monza.broadswitch.com>

> I glad we speak the same languague...
> I totally agree with you.

good.
>
> I have tried to raise this question 1,5 year ago but with very little
> reponse...

Perhaps you were just a little ahead of your time :)

>
> But I dont like you grouping with names very specific to cellular sytems
> like BTS BSC and MSC
> But I agree on the "levels"
> But I would also like the level of personal network or pico mobility where
> the typical scenario is the wireless router with a lot of bluetooth links...

Agreed. I used the cellular names in hopes that most readers would have a
basic understanding of cellular systems, and to provide some context.

>
> > Link Layer Mobility (Inter-BTS hand-off)
> > - pick a name Mobility (inter-BSC hand-off)
> These two I would grouped together like micro mobility because they have the
> same access network!!

Here we disagree. Certainly, today's BSCs operate this way, but the work being
done in the All-IP standards will radically change the BSC. I see no reason
why an IP-level mobility cannot be used at the BSC (well, for CDMA anyways).

>
> In other word the could have the same L2 segment...
>
> And the BTS is just a "wireless bridge" and could be an access point for a
> wireless LAN for instance...

hence link-layer Mobility. Yes, I thought of using 802.11 as one example, but
it became harder to provider the other levels using 802.11 :(

>
> And in cellular sytems for instance it is very difficult to break up this
> that why I think it should go under a common micro-mobility
> And if it is a wirelles LAN access ponit you probably have a ethernet switch
> connecting all your access points and 802.1Q ethernet gives you local
> mobility...

Again, I respectfully disagree. We only think this way because of the current
systems, but some engineering effort is under way to change these systems, so
I would still prefer to see it the way I proposed. Otherwise, we will end up
with terminology problems when/if they do change.

>
> But clear interfaces is a must.
Well, I would agree on terminology. Proposals are plentiful, and picking one
from the list will be a rather difficult task. It must/will occur, but my
proposal is to simply come up with some common terminology.

PatC

PatC
>
> /Thomas
>
>
> > -----Original Message-----
> > From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> > Sent: Wednesday, March 01, 2000 3:07 PM
> > To: Thomas Eklund
> > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Terminology (was: [MOBILE-IP] charter update?)
> >
> >
> > All,
> >
> > I had a conversation yesterday with Charlie and we both
> > agreed that we need to
> > define the different layers of mobility. Today we use micro and macro
> > mobility, and these terms mean completely different things,
> > depending upon the
> > proposal that you happen to be backing. Therefore, having
> > agreement on the
> > list as to what micro vs. macro means will be a long, drawn
> > out battle, and I
> > think that we have better things to do with out time (well,
> > at least I do).
> >
> > btw, in case you still aren't convinced, it isn't clear to me
> > that what we
> > today call micro-mobility cannot be achieved via hierarchical
> > Mobile IP, while
> > others believe that Hawaii or Cellular IP provides micro-mobility.
> >
> > So, I would like to propose that we agree on some new
> > terminology. I believe
> > that we have: - Link Layer Mobility (Inter-BTS hand-off)
> > - pick a name Mobility (inter-BSC hand-off)
> > - Intra-Domain Mobility (Inter-MSC hand-off)
> > - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> >
> > I still don't have a preference for the second name, and I am
> > not married to
> > ANY of the names above. These are merely suggestions. The
> > goal here is to ALL
> > agree on basic terminology so that when we compare protocols,
> > we can match the
> > protocol against a set of common terminology.
> >
> > Comments? Is this a worthwhile exercise?
> >
> > PatC
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:01:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03724
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:01:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.63F62FF0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:56:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66021 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:55:51 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5032FBB0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:55:45
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA09427; Wed, 1 Mar
          2000 20:56:14 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.0051923F ; Wed, 1 Mar 2000 20:20:58 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.00519083.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 20:24:39 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,
         I am not satisfied with Thomas cos cellular systems until now were
having different standards all over the world but now there is a new standard
coming up which talks
"One Mobile All Over the world "   i.e. 3G Mobile Network, and you can find
Billions of users coming up in the next Decade for Cellular telephony, Let us
even support IPv6 also.

Best Regards
Sirish










Thomas Eklund <thomas.eklund@SWITCHCORE.COM> on 03/01/2000 08:00:55 PM

Please respond to Thomas Eklund <thomas.eklund@SWITCHCORE.COM>

To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sirish K Challagulla/HSS)

Subject:  Re: [MOBILE-IP] charter update?




And dont forget to also be more IPv6 centric since the cellular sytems would
never be able to grow to their estimated billions of users if its not IPv6
based...

/Thomas
> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@HA1MPK-MAIL.ENG.SUN.COM]
> Sent: Wednesday, March 01, 2000 2:56 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
>
> All,
>
> I find it difficult to justify NOT updating the draft to
> include cellular
> specific extensions. As many of you know, Mobile IP has been
> in RFC form for
> quite some time now, and until the cellular folks decided to
> adopt it, we
> really didn't have much deployment. If cellular is the killer
> Mobile IP
> service, then we should do what we can to help make Mobile IP
> successful.
>
> PatC
>
> > I think the charter should be updated to support cellular specific
> > extensions.
> >
> > Mark A. Lipford
> > Manager, Wireless Industry Standards - Data
> > Sprint PCS
> > 8001 College Blvd.; Suite 210
> > Overland Park, KS  66210
> > (913) 664-8335 (office)
> > (913) 664-8440 (fax)
> > (913) 226-9060 (PCS)
> >
> >
> > -----Original Message-----
> > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > Sent: Tuesday, February 29, 2000 5:14 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: [MOBILE-IP] charter update?
> >
> >
> > Greetings gentlepeople,
> >
> >     We've got 4 presentations lined up at the Adelaide
> meeting on various
> > proposals for handoff.  This together with the fact that
> several of our
> > current drafts are motivated by 3G data support indicates
> to Raj and me that
> > there continues to be some interest in the group in
> supporting cellular
> > specific extensions to mobile-ip.  The charter doesn't
> specify a strong
> > support of these activities.  The current wording is "The
> WG moving forward
> > will focus on deployment issues in Mobile IP and provide appropriate
> > protocol solutions to address known deficiencies and
> shortcomings. For
> > example, the wireless/cellular industry is considering
> using Mobile IP as
> > one technique for IP mobility for wireless data. The
> working group will
> > endeavor to gain an understanding of data service in
> cellular systems such
> > as GPRS, UMTS, CDMA2000, and interact with other standards
> bodies that are
> > trying to adopt and deploy Mobile IP WG protocols in these
> contexts."
> > So I'd like to find out whether there is interest in the
> group to extending
> > the charter for specific support of cellular systems.  If
> there is general
> > support I'll propose some wording.  One obvious work item
> would be to submit
> > a draft to the IESG for support of fast handover.
> >
> > Comments?
> > Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:09:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04087
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:09:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAB509B0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:05:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66008 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:04:52 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.302BD350@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:54:51
          -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id GAA26476; Wed, 1 Mar 2000 06:58:19
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.101.34]) by engmail1.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA04676; Wed, 1 Mar
          2000 06:58:18 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA16501; Wed, 1 Mar 2000 06:58:17 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.951922697.17324.pcalhoun@ha1mpk-mail>
Date:         Wed, 1 Mar 2000 06:58:17 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Emad Qaddoura <emadq@nortelnetworks.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <F908F961B7CDD111BC720000F8073E4302DD93A7@crchy271.us.nortel.com>

Emad,

I used the cellular terminology loosely to provide an example of what each of
the terms would mean. Certainly these could be applied to other networks. As
an example, say using Hierarchical Mobile-IP, one could design a 802.11-based
service that provides all of the examples below (of course, that would
requires lots of bridges :) If the network was flat (no Hierarchical Mobile
IP), the second bullet wouldn't be used.

PatC

> Pat,
>
> ....
>
> > So, I would like to propose that we agree on some new
> > terminology. I believe
> > that we have: - Link Layer Mobility (Inter-BTS hand-off)
> > - pick a name Mobility (inter-BSC hand-off)
> > - Intra-Domain Mobility (Inter-MSC hand-off)
> > - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> >
>
> So are these the only mobility related technology that MIP should be
> applied/used for?
>
> > I still don't have a preference for the second name, and I am
> > not married to
> > ANY of the names above. These are merely suggestions. The
> > goal here is to ALL
> > agree on basic terminology so that when we compare protocols,
> > we can match the
> > protocol against a set of common terminology.
> >
> > Comments? Is this a worthwhile exercise?
>
> The objective of agreeing on terminology is great. However, if we go this
> specific to cellular, I may be the only one suggesting renaming the MIP WG
> to "MIP For Cellular".
>
> >
> > PatC
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:13:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04285
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:12:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3870170@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:07:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66159 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:06:49 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CD176020@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:06:24
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id VAA10039; Wed, 1 Mar
          2000 21:07:54 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.0052A2EB ; Wed, 1 Mar 2000 20:32:36 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.0052A1E0.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 20:34:27 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,
      Let us give a new terminology 3GMobile-IP, which do not confuse 3G stands
for 3rd Generation Mobile Networks. Support for 3G Networks  will be a grand
Success for us.

Best Regards
Sirish









"pcalhoun@eng.sun.com" <pcalhoun on 03/01/2000 08:13:34 PM

Please respond to "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>

To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sirish K Challagulla/HSS)

Subject:  Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)




> I glad we speak the same languague...
> I totally agree with you.

good.
>
> I have tried to raise this question 1,5 year ago but with very little
> reponse...

Perhaps you were just a little ahead of your time :)

>
> But I dont like you grouping with names very specific to cellular sytems
> like BTS BSC and MSC
> But I agree on the "levels"
> But I would also like the level of personal network or pico mobility where
> the typical scenario is the wireless router with a lot of bluetooth links...

Agreed. I used the cellular names in hopes that most readers would have a
basic understanding of cellular systems, and to provide some context.

>
> > Link Layer Mobility (Inter-BTS hand-off)
> > - pick a name Mobility (inter-BSC hand-off)
> These two I would grouped together like micro mobility because they have the
> same access network!!

Here we disagree. Certainly, today's BSCs operate this way, but the work being
done in the All-IP standards will radically change the BSC. I see no reason
why an IP-level mobility cannot be used at the BSC (well, for CDMA anyways).

>
> In other word the could have the same L2 segment...
>
> And the BTS is just a "wireless bridge" and could be an access point for a
> wireless LAN for instance...

hence link-layer Mobility. Yes, I thought of using 802.11 as one example, but
it became harder to provider the other levels using 802.11 :(

>
> And in cellular sytems for instance it is very difficult to break up this
> that why I think it should go under a common micro-mobility
> And if it is a wirelles LAN access ponit you probably have a ethernet switch
> connecting all your access points and 802.1Q ethernet gives you local
> mobility...

Again, I respectfully disagree. We only think this way because of the current
systems, but some engineering effort is under way to change these systems, so
I would still prefer to see it the way I proposed. Otherwise, we will end up
with terminology problems when/if they do change.

>
> But clear interfaces is a must.
Well, I would agree on terminology. Proposals are plentiful, and picking one
from the list will be a rather difficult task. It must/will occur, but my
proposal is to simply come up with some common terminology.

PatC

PatC
>
> /Thomas
>
>
> > -----Original Message-----
> > From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> > Sent: Wednesday, March 01, 2000 3:07 PM
> > To: Thomas Eklund
> > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Terminology (was: [MOBILE-IP] charter update?)
> >
> >
> > All,
> >
> > I had a conversation yesterday with Charlie and we both
> > agreed that we need to
> > define the different layers of mobility. Today we use micro and macro
> > mobility, and these terms mean completely different things,
> > depending upon the
> > proposal that you happen to be backing. Therefore, having
> > agreement on the
> > list as to what micro vs. macro means will be a long, drawn
> > out battle, and I
> > think that we have better things to do with out time (well,
> > at least I do).
> >
> > btw, in case you still aren't convinced, it isn't clear to me
> > that what we
> > today call micro-mobility cannot be achieved via hierarchical
> > Mobile IP, while
> > others believe that Hawaii or Cellular IP provides micro-mobility.
> >
> > So, I would like to propose that we agree on some new
> > terminology. I believe
> > that we have: - Link Layer Mobility (Inter-BTS hand-off)
> > - pick a name Mobility (inter-BSC hand-off)
> > - Intra-Domain Mobility (Inter-MSC hand-off)
> > - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> >
> > I still don't have a preference for the second name, and I am
> > not married to
> > ANY of the names above. These are merely suggestions. The
> > goal here is to ALL
> > agree on basic terminology so that when we compare protocols,
> > we can match the
> > protocol against a set of common terminology.
> >
> > Comments? Is this a worthwhile exercise?
> >
> > PatC
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:18:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04488
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:18:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEA3B000@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:13:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66254 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:12:29 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A3AFE620@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:12:24
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id VAA10383 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar 2000 21:14:16
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.00533A2A ; Wed, 1 Mar 2000 20:39:03 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.00533912.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 20:42:46 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      [MOBILE-IP] Some latest and Interesting Info from Ericsson
              Regarding Mobile
              Internet and the support of 3G
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Ericsson adds advertising options to mobile networks
- Internet Advertiser goes mobile

Mobile network operators and Internet Service Providers will have new
options for delivering information services and generating new revenue
streams with the introduction of Mobile Internet Advertiser from Ericsson.
Mobile Internet Advertiser is based on Ericsson's innovative Internet
Advertiser product, which is a network-based advertising tool that
broadcasts rich media advertisements to Internet subscribers based on
individual user preferences. Internet Advertiser can be used to deliver
free or lower-cost Internet services that are funded by the sale of
targeted advertising.
By bringing Internet Advertiser to mobile networks, Ericsson makes it
possible for service providers to offer similar services to users of
mobile phone and other mobile communication devices.

"Adding the option of mobility to Internet Advertiser opens a whole new
range of possibilities for advertisers," says Harry Hakansson, General
Manager of Interactive Communication for Ericsson.
"With mobility, advertisers can deliver information in a personal manner
when it is most relevant to users, based on location and interest.

Advertisers can provide instant information updates that are useful to
subscribers so that advertising becomes a service rather than an
intrusion," Harry Hakansson continues.
Currently, advertising will be delivered through WAP and other wireless
standards and networks. With the higher bandwidth of 3G wireless
technologies, advertisements can be developed to incorporate rich media,
full-motion video and animation, much like today's television advertising.

The Mobile Internet Advertiser will use the same server technology as
Ericsson Internet Advertiser for wireline systems. It will be available on
wireless networks, such as GPRS and 3G, when these networks become
operational. The product is scheduled for commercial release in the third
quarter of this year.

Ericsson is the leading provider in the new telecoms world, with
communications solutions that combine telecom and datacom technologies
with freedom of mobility for the user. With more than 100,000 employees in
140 countries, Ericsson simplifies communications for its customers -
network operators, service providers, enterprises and consumers - the
world over.
Please visit Ericsson's Press Room at: http://www.ericsson.se/pressroom
FOR FURTHER INFORMATION, PLEASE CONTACT
Johan Wiklund, Ericsson Corporate Communications
Phone: +46 70 560 0134; E-mail: johan.wiklund@lme.ericsson.se
Kathy Egan, Vice President, Corporate Communications, Ericsson Inc.
Phone: +1 212 685 4030; E-mail: kathy.egan@ericsson.com
Mats Eriksson, Product Business Manager, Ericsson Interactive
Communications
Phone: + +46 8 7195124; E-mail: mats.z.eriksson@era.ericsson.se


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:28:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04802
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:28:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.377D4FE0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:23:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66257 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:22:33 -0500
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.A8795510@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:12:32
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Mar  1
          10:14:20 EST 2000
Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean
          [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with
          ESMTP id KAA21735; Wed, 1 Mar 2000 10:14:19 -0500 (EST)
Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id
          KAA13912; Wed, 1 Mar 2000 10:14:19 -0500
Mail-Followup-To: Emad Qaddoura <emadq@nortelnetworks.com>,
                  MOBILE-IP@standards.nortelnetworks.com
References: <F908F961B7CDD111BC720000F8073E4302DD93A6@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: Linux 2.2.12-20
X-Organization: Lucent Technologies, Bell Laboratories
Message-ID:  <20000301101419.L27822@bell-labs.com>
Date:         Wed, 1 Mar 2000 10:14:19 -0500
Reply-To: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Emad Qaddoura <emadq@nortelnetworks.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <F908F961B7CDD111BC720000F8073E4302DD93A6@crchy271.us.nortel.com>; from emadq@nortelnetworks.com on Wed,
              Mar 01, 2000 at 08:48:26AM -0600

Emad:

with "cellular/wireless" I meant that this should apply not only to the
cellular world, but to any kind of wireless technology (Bluetooth, 802.11,
you name it). I think support for fast handoff, be it with HAWAII,
Cellular-IP, Hierarchical FAs, or a combination of them, is a must for MIP
to be used effectively in any kind of wireless technology.

Regards
Luca

On Wed, Mar 01, 2000 at 08:48:26AM -0600, Emad Qaddoura wrote:
>
>    Luca,
>
>            I don't agree that MIP should support fast handover, but is it
>    only directed for cellular? May be a general objective should be
>    "support of fast handover".
>
>    thx.
>
>    > -----Original Message-----
>    > From: Luca Salgarelli [[1]mailto:lsalgarelli@bell-labs.com]
>    > Sent: Tuesday, February 29, 2000 5:54 PM
>    > To: Qaddoura, Emad [RICH2:IP10-M:EXCH]
>    > Cc: MOBILE-IP@standards.nortelnetworks.com
>    > Subject: Re: [MOBILE-IP] charter update?
>    >
>    >
>    > Hi Emad.
>    >
>    > >            So why is the current charter not sufficient for
>    > addressing
>    > >    the interest by the cellular interest?
>    >
>    > Personally, I think that one of the work items that are
>    > missing from the
>    > charter (wrt cellular/wireless) is support for fast handover:
>    > this should
>    > be a must for the use of MIP not only in cellular networks, but in
>    any
>    > wireless network where QoS counts.
>    >
>    > Regards
>    > Luca
>    >
>    > >
>    > >            I understand that the MIP WG is interested in getting
>    MIP
>    > >    deployed over cellular or other technologies. However,
>    > my personal
>    > >    view is: if we mandate the Cellular support as a
>    > requirement in the
>    > >    charter, it may become more of a "MIP for Cellular WG"
>    > than general
>    > >    MIP solution.
>    >
>
> References
>
>    1. mailto:lsalgarelli@bell-labs.com

--
_________________
 Luca Salgarelli
 Bell Laboratories
 Room 4F-506
 101 Crawfords Corner Rd.
 Holmdel, NJ 07733, USA
 Tel: +1-732-332-6870
 Fax: +1-732-949-7397
 E-mail: lsalgarelli@bell-labs.com
 PGP public key at: http://pgp5.ai.mit.edu/pks-commands.html#extract


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:35:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05203
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:35:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.377459C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:30:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66318 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:29:13 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9762D4D0@standards.nortelnetworks.com>; Wed, 1 Mar 2000
          10:19:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF2A@monza.broadswitch.com>
Date:         Wed, 1 Mar 2000 16:22:42 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > > Link Layer Mobility (Inter-BTS hand-off)
> > > - pick a name Mobility (inter-BSC hand-off)
> > These two I would grouped together like micro mobility
> because they have the
> > same access network!!
>
> Here we disagree. Certainly, today's BSCs operate this way,
> but the work being
> done in the All-IP standards will radically change the BSC. I
> see no reason
> why an IP-level mobility cannot be used at the BSC (well, for
> CDMA anyways).
I'm also talking about Ethernet 802.1Q switches which have "local mobility"
in the virtual LANs that the switch defines (subnet and protocol based
VLANs)..
Don understand how you cant agree with that?

Yes and the BSC/RNC controls the BTS'es and if you dont want that in the
BSC/RNC box then you perhaps put it in some server in the access network but
then that server handles the syncronnization, radio resource managment,
mobility managemnt etc..

But I have no problem with having one more layer as you proposed - because
the more generic the better... and let us define those interfaces or
mobility level in an arhitechure document...

ps. the way soft handover for instance is solved i W-CDMA it is practically
impossible to split it up but there might be other access network where it
is possible.. ds.

>
> >
> > In other word the could have the same L2 segment...
> >
> > And the BTS is just a "wireless bridge" and could be an
> access point for a
> > wireless LAN for instance...
>
> hence link-layer Mobility. Yes, I thought of using 802.11 as
> one example, but
> it became harder to provider the other levels using 802.11 :(
>
> >
> > And in cellular sytems for instance it is very difficult to
> break up this
> > that why I think it should go under a common micro-mobility
> > And if it is a wirelles LAN access ponit you probably have
> a ethernet switch
> > connecting all your access points and 802.1Q ethernet gives
> you local
> > mobility...
>
> Again, I respectfully disagree. We only think this way
> because of the current
> systems, but some engineering effort is under way to change
> these systems, so
> I would still prefer to see it the way I proposed. Otherwise,
> we will end up
> with terminology problems when/if they do change.
Ok that debatable (for instance soft handover in UMTS)... But I dont want to
go into that because we agree on whats needs to be done..

Ok let me re-prase... In my deepest ip heart I agree with you, but I want a
network that is flexible to support both ways... I.e one more agressive and
one more "backward compatible" one...
Being able to do so we need to define the interfaces very clear so its is up
to the service provider to chose...

/Thomas


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:39:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05350
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:39:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9EC6220@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:34:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66503 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:34:52 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C7213430@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:34:52
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA16462 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 17:38:22
          +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          RAA16141 for <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar
          2000 17:38:21 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWH1Z>;
          Wed, 1 Mar 2000 09:38:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B92970C@daeis07nok>
Date:         Wed, 1 Mar 2000 09:37:26 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Charter Update
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Just to clarify what the intent of increasing the scope
of the charter is :

We are increasingly seeing proposals to the Mobile IP WG
that deal with handoffs. The cellular/wireless environment
is where handoffs are a critical function. The WG needs to
address this domain without necessarily having to become a
"Mobile IP for Cellular" WG. I need to reiterate that the
solutions developed in this WG are applicable across different
types of access and core networks.

One more thing:
Handoff solutions that the WG needs to work on need to be
applicable to both IPv4/6.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:48:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05677
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:48:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E191F50@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:44:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66562 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:42:28 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D6E61C40@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:42:28
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA25282 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 17:45:57
          +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          RAA19491 for <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar
          2000 17:45:56 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWHHG>;
          Wed, 1 Mar 2000 09:45:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B92970D@daeis07nok>
Date:         Wed, 1 Mar 2000 09:45:01 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>
>All,
>

----snip snip-----

>So, I would like to propose that we agree on some new terminology. I
believe
>that we have: - Link Layer Mobility (Inter-BTS hand-off)
>- pick a name Mobility (inter-BSC hand-off)
>- Intra-Domain Mobility (Inter-MSC hand-off)
>- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>

Pat,

Agreeing on terminology is something that we need to strive for. But
the ones that you mention here are very specific to 2G Wireless/Cellular
networks. It would be better to be more generic or just map them to
functional entities that would exist in any type of network.


>I still don't have a preference for the second name, and I am not married
to
>ANY of the names above. These are merely suggestions. The goal here is to
ALL
>agree on basic terminology so that when we compare protocols, we can match
the
>protocol against a set of common terminology.
>
>Comments? Is this a worthwhile exercise?

Does the WG need to develop a terminology document that can be
referenced by all WG and Mobile IP related docs? It may be a
worthwhile exercise and help us all to be on the same page.

-Basavaraj


>
>PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:52:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05803
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:52:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F6021C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:48:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66606 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:47:37 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8EC2BE90@standards.nortelnetworks.com>; Wed, 1 Mar 2000
          10:47:36 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 09:51:04 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 1
          Mar 2000 10:50:38 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5XQ4TS>; Wed, 1 Mar 2000 09:50:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8395.E2DE5C94"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93AC@crchy271.us.nortel.com>
Date:         Wed, 1 Mar 2000 09:50:25 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF8395.E2DE5C94
Content-Type: text/plain;
        charset="iso-8859-1"

Sorry, meant to say that I AGREE MIP SHOULD support fast handover.

-----Original Message-----
From: Qaddoura, Emad [RICH2:IP10-M:EXCH]
Sent: Wednesday, March 01, 2000 8:48 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] charter update?



Luca,

        I don't agree that MIP should support fast handover, but is it only
directed for cellular? May be a general objective should be "support of fast
handover".

thx.

> -----Original Message-----
> From: Luca Salgarelli [ mailto:lsalgarelli@bell-labs.com
<mailto:lsalgarelli@bell-labs.com> ]
> Sent: Tuesday, February 29, 2000 5:54 PM
> To: Qaddoura, Emad [RICH2:IP10-M:EXCH]
> Cc: MOBILE-IP@standards.nortelnetworks.com
> Subject: Re: [MOBILE-IP] charter update?
>
>
> Hi Emad.
>
> >            So why is the current charter not sufficient for
> addressing
> >    the interest by the cellular interest?
>
> Personally, I think that one of the work items that are
> missing from the
> charter (wrt cellular/wireless) is support for fast handover:
> this should
> be a must for the use of MIP not only in cellular networks, but in any
> wireless network where QoS counts.
>
> Regards
> Luca
>
> >
> >            I understand that the MIP WG is interested in getting MIP
> >    deployed over cellular or other technologies. However,
> my personal
> >    view is: if we mandate the Cellular support as a
> requirement in the
> >    charter, it may become more of a "MIP for Cellular WG"
> than general
> >    MIP solution.
>


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<TITLE>RE: [MOBILE-IP] charter update?</TITLE>
<META content='"MSHTML 4.72.3612.1706"' name=GENERATOR>
</HEAD>
<BODY>
<DIV><SPAN class=282285015-01032000><FONT color=#0000ff face=Arial size=2>Sorry,
meant to say that I AGREE MIP SHOULD support fast handover.</FONT></SPAN></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
    <DIV class=OutlookMessageHeader><FONT face="Times New Roman"
    size=2>-----Original Message-----<BR><B>From:</B> Qaddoura, Emad
    [RICH2:IP10-M:EXCH] <BR><B>Sent:</B> Wednesday, March 01, 2000 8:48
    AM<BR><B>To:</B> MOBILE-IP@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B>
    Re: [MOBILE-IP] charter update?<BR><BR></FONT></DIV>
    <P><FONT size=2>Luca,</FONT> </P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>I don't agree
    that MIP should support fast handover, but is it only directed for cellular?
    May be a general objective should be &quot;support of fast
    handover&quot;.</FONT></P>
    <P><FONT size=2>thx.</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt;
    From: Luca Salgarelli [<A
    href="mailto:lsalgarelli@bell-labs.com">mailto:lsalgarelli@bell-labs.com</A>]</FONT>
    <BR><FONT size=2>&gt; Sent: Tuesday, February 29, 2000 5:54 PM</FONT>
    <BR><FONT size=2>&gt; To: Qaddoura, Emad [RICH2:IP10-M:EXCH]</FONT>
    <BR><FONT size=2>&gt; Cc: MOBILE-IP@standards.nortelnetworks.com</FONT>
    <BR><FONT size=2>&gt; Subject: Re: [MOBILE-IP] charter update?</FONT>
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT
    size=2>&gt; Hi Emad.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
    size=2>&gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So
    why is the current charter not sufficient for </FONT><BR><FONT size=2>&gt;
    addressing</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the interest
    by the cellular interest?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT
    size=2>&gt; Personally, I think that one of the work items that are
    </FONT><BR><FONT size=2>&gt; missing from the</FONT> <BR><FONT size=2>&gt;
    charter (wrt cellular/wireless) is support for fast handover:
    </FONT><BR><FONT size=2>&gt; this should</FONT> <BR><FONT size=2>&gt; be a
    must for the use of MIP not only in cellular networks, but in any</FONT>
    <BR><FONT size=2>&gt; wireless network where QoS counts.</FONT> <BR><FONT
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Regards</FONT> <BR><FONT
    size=2>&gt; Luca</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;
    &gt;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT size=2>&gt;
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I
    understand that the MIP WG is interested in getting MIP</FONT> <BR><FONT
    size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; deployed over cellular or other
    technologies. However, </FONT><BR><FONT size=2>&gt; my personal</FONT>
    <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; view is: if we mandate the
    Cellular support as a </FONT><BR><FONT size=2>&gt; requirement in the</FONT>
    <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; charter, it may become more of
    a &quot;MIP for Cellular WG&quot; </FONT><BR><FONT size=2>&gt; than
    general</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; MIP
    solution.</FONT> <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF8395.E2DE5C94--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 10:57:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05890
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 10:57:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7271220@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:50:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66615 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:48:06 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A0429280@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:48:06
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA17855; Wed, 1 Mar
          2000 17:51:36 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          RAA06069; Wed, 1 Mar 2000 17:51:34 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM293TA>;
          Wed, 1 Mar 2000 09:50:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B92970E@daeis07nok>
Date:         Wed, 1 Mar 2000 09:50:39 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         csirish@HSS.HNS.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>All,
>      Let us give a new terminology 3GMobile-IP, which do not confuse
>3G stands
>for 3rd Generation Mobile Networks. Support for 3G Networks  will be a
grand
>Success for us.
>
>Best Regards
>Sirish

Sirish,

If 3G networks (Wireless/Cellular or otherwise) adopt Mobile IP as a
solution for Mobileity management, that would be a success for this WG,
and as you can see from the current charter the goal is in getting
Mobile IP deployed. But I would refrain from terminology such as
"3GMobile-IP".

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:03:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06178
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:03:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E04BE80@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:59:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66724 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:58:10 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.07F95D40@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:58:09
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA09140; Wed, 1 Mar
          2000 18:01:39 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          SAA26202; Wed, 1 Mar 2000 18:01:38 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWHM1>;
          Wed, 1 Mar 2000 10:01:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929710@daeis07nok>
Date:         Wed, 1 Mar 2000 10:00:43 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         csirish@HSS.HNS.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>
>Hi
>       The grand Success of our Mobile-IP  will be there if we Support
>GPRS,UMTS,CDMA2000 also,
> I would like to work in this context  with the permission or Mr.RAJ any
one
>interested Pl  update me .
>
>Best Regards
>Sirish
>

Sirish,

Deployment of Mobile IP on a global basis would be  what I would term
as a success. In the context of this discussion, all we are proposing
is that the WG needs to address handoff issues and develop a
solution. I don't understand what you mean by this WG supporting GPRS,
UMTS, CDMA2000...
And I guess you were refering to me when you said "with the permission
of Mr. RAJ",... Rest assured that you can work on this context and you
do not need my permission :)

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:07:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06300
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:07:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BF232A50@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:03:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66764 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:02:52 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ADFB8880@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:02:48
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id WAA14043; Wed, 1 Mar
          2000 22:04:14 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256895.0057CD35 ; Wed, 1 Mar 2000 21:29:01 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256895.0057CC40.00@sandesh.hss.hns.com>
Date:         Wed, 1 Mar 2000 21:32:45 +0530
Reply-To: csirish@HSS.HNS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sirish K Challagulla <csirish@HSS.HNS.COM>
Subject:      [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

All,
      Let us give a new terminology 3GMobile-IP, Is more generic, 3G stands  for
3rd Generation Mobile Networks. Support for 3G Networks  will be a grand Success
for us.

Best Regards
Sirish


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:14:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06483
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:14:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BBACABC0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:10:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66818 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:08:31 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7A7914E0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:08:31
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA18948; Wed, 1 Mar
          2000 18:12:01 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          SAA00199; Wed, 1 Mar 2000 18:11:59 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWHPY>;
          Wed, 1 Mar 2000 10:11:58 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929711@daeis07nok>
Date:         Wed, 1 Mar 2000 10:11:04 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         thomas.eklund@SWITCHCORE.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>
>And dont forget to also be more IPv6 centric since the cellular sytems
would
>never be able to grow to their estimated billions of users if its not IPv6
>based...
>
>/Thomas
>

And as a side note: The Mobility Support in IPv6 I-D (Rev 10) has
completed WG last call recently and is on standards track. It should
be a proposed standard in the very near future.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:38:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07278
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:38:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D3C8880@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:34:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 66975 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:33:15 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EEB07CB0@standards.nortelnetworks.com>; Wed, 1 Mar 2000
          11:33:14 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 10:33:44 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 1
          Mar 2000 11:33:20 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5XQYHX>; Wed, 1 Mar 2000 10:33:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF839B.D75C1E32"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93AE@crchy271.us.nortel.com>
Date:         Wed, 1 Mar 2000 10:33:09 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Basavaraj.Patil@NOKIA.COM" <Basavaraj.Patil@NOKIA.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF839B.D75C1E32
Content-Type: text/plain;
        charset="iso-8859-1"

....

> -----Original Message-----
> From: Basavaraj Patil [mailto:Basavaraj.Patil@NOKIA.COM]
> Sent: Wednesday, March 01, 2000 9:45 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
>

....

>
> Does the WG need to develop a terminology document that can be
> referenced by all WG and Mobile IP related docs? It may be a
> worthwhile exercise and help us all to be on the same page.

I agree.

>
> -Basavaraj
>
>
> >
> >PatC
> >
>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>....</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Basavaraj Patil [<A HREF="mailto:Basavaraj.Patil@NOKIA.COM">mailto:Basavaraj.Patil@NOKIA.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, March 01, 2000 9:45 AM</FONT>
<BR><FONT SIZE=2>&gt; To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=2>&gt; Subject: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>....</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Does the WG need to develop a terminology document that can be</FONT>
<BR><FONT SIZE=2>&gt; referenced by all WG and Mobile IP related docs? It may be a</FONT>
<BR><FONT SIZE=2>&gt; worthwhile exercise and help us all to be on the same page.</FONT>
</P>

<P><FONT SIZE=2>I agree. </FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Basavaraj</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF839B.D75C1E32--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:55:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07767
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:55:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.810819E0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:51:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67031 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:50:19 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.EB26EB50@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:40:18
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id LAA07396; Wed, 1 Mar 2000 11:43:42
          -0500 (EST)
Message-ID:  <200003011643.LAA07396@ietf.org>
Date:         Wed, 1 Mar 2000 11:43:41 -0500
Reply-To: iesg@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: The IESG <iesg-secretary@ietf.org>
Subject:      [MOBILE-IP] Last Call: Mobile IP Challenge/Response Extensions to
              Proposed
              Standard
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

The IESG has received a request from the IP Routing for Wireless/Mobile
Hosts Working Group to consider Mobile IP Challenge/Response Extensions
<draft-ietf-mobileip-challenge-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by March 15, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-09.txt


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 11:59:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07852
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 11:59:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9D7A0A0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:53:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67070 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:52:30 -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.9F6BCB70@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:52:30
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Mar  1
          11:54:28 EST 2000
Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by
          bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA26751; Wed, 1
          Mar 2000 11:54:28 -0500 (EST)
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
References: <7B5C0390ACE7D211BC9C0008C7EABA2B92970D@daeis07nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BD4B4F.B760C721@dnrc.bell-labs.com>
Date:         Wed, 1 Mar 2000 16:54:39 +0000
Reply-To: ramjee@DNRC.BELL-LABS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ramachandran Ramjee <ramjee@DNRC.BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Folks,

Basavaraj Patil wrote:
> >So, I would like to propose that we agree on some new terminology. I
> >believe that we have: - Link Layer Mobility (Inter-BTS hand-off)
> >- pick a name Mobility (inter-BSC hand-off)
> >- Intra-Domain Mobility (Inter-MSC hand-off)
> >- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> Pat,
> Agreeing on terminology is something that we need to strive for. But
> the ones that you mention here are very specific to 2G Wireless/Cellular
> networks. It would be better to be more generic or just map them to
> functional entities that would exist in any type of network.

How about the following?

Link-Layer Mobility (Inter-BTS handoff: CDMA, 802.11 access points)
Intra-Domain Mobility (aka Micro-Mobility: Hier. MIP, HAWAII, CIP)
Inter-Domain Mobility (aka Macro-Mobility: Mobile IP)

Note that depending on how a domain is defined, we can have four
combinations (assuming Mobile IP is present):

1) Original scenario of "domain = base station" then
         Mobile IP necessary.

2) If base station acts as a link-layer bridge (access points/cellular
   base stations), "domain = next hop router" then
         Mobile IP  + link-layer mobility necessary.

3) If domain is an entire network and base station is an IP-level
   router
         Mobile IP + intra-domain mobility necessary

4) If domain is an entire network and base station acts as a bridge,then
         Mobile IP + intra-domain  + link-layer mobility necessary

Cellular folks can then map domains into their favorite elements
(BSC/MSC/SSGN/GGSN) and choose option 2 or option 4.
Others such as all-IP proponents can choose option 1 or option 3.
Thus, we allow maximum flexibility.


Cheers,
Ram


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 12:06:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08098
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 12:06:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB2D2580@standards.nortelnetworks.com>; Wed, 1 Mar 2000 12:01:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67145 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 12:00:32 -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BEB4B770@standards.nortelnetworks.com>; Wed, 1 Mar 2000 12:00:32
          -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Mar
          1 12:03:01 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Wed Mar 
          1 12:03:00 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id A82C157042; Wed,  1 Mar 2000 11:02:59 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <7B5C0390ACE7D211BC9C0008C7EABA2B92970C@daeis07nok>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000301170259.A82C157042@king.research.bell-labs.com>
Date:         Wed, 1 Mar 2000 11:02:59 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] Charter Update
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <7B5C0390ACE7D211BC9C0008C7EABA2B92970C@daeis07nok>
Content-Transfer-Encoding: 7bit

Hi, Basavaraj,

I agree with your message below - I think we need to be very cautious
about expanding the charter of the WG to be too cellular-specific.
This is the Mobile IP working group, which means that we should be
defining IP-layer protocols.

There are some link-layer specific questions that need to be
addressed, in terms of how a Mobile IP Foreign Agent should be "glued"
onto the cellular wireless link layer.
draft-ietf-mobileip-3gwireless-ext-02.txt does this pretty well.
However, I do not think we should try to start standardizing other
aspects of a 3rd generation cellular network.  I think some people are
trying to plan a BOF in Adelaide called "IP to the Base Station" that
could address some of these questions, but I am concerned that the
IETF has a fairly limited understanding of the cellular link layer,
especially as it pertains to CDMA - I've read and heard statements
that reveal a certain lack of knowledge of how a CDMA Selection and
Distribution Unit really work, when people try to get IP packets sent
by a MN directly out of a BTS.  Of course, I've also seen people here
who *do* understand the technology quite well - I don't mean to start
a flame war, but I think this kind of work logically belongs in the
respective 3GPPs for each technology.

Certainly the Mobile IP WG should strive to develop an understanding
of the various link-layer technologies so that its protocols are as
widely applicable as possible, and perform well for multimedia
applications.  However, I do not think we should get in the business
of standardizing link layers.

-Pete

Basavaraj Patil <Basavaraj.Patil@NOKIA.COM> (BP) writes:

BP> Just to clarify what the intent of increasing the scope
BP> of the charter is :

BP> We are increasingly seeing proposals to the Mobile IP WG
BP> that deal with handoffs. The cellular/wireless environment
BP> is where handoffs are a critical function. The WG needs to
BP> address this domain without necessarily having to become a
BP> "Mobile IP for Cellular" WG. I need to reiterate that the
BP> solutions developed in this WG are applicable across different
BP> types of access and core networks.

BP> One more thing:
BP> Handoff solutions that the WG needs to work on need to be
BP> applicable to both IPv4/6.

BP> -Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 12:29:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08693
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 12:29:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.258C5AE0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 12:24:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67192 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 12:23:09 -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6FC2FDA0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 12:12:38
          -0500
Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA03162 for
          <mobile-ip@smallworks.com>; Wed, 1 Mar 2000 11:15:57 -0600 (CST)
Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3])
          by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id SAA22704; Wed,
          1 Mar 2000 18:14:31 +0100 (MET)
Received: from pcnt.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB
          5.64/5.1) id AA38846; Wed, 1 Mar 2000 18:10:50 +0100
Address: Mickiewicza 30, 30-059 Krakow, POLAND
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BD518E.818945DE@kt.agh.edu.pl>
Date:         Wed, 1 Mar 2000 18:21:18 +0100
Reply-To: PROMS2000 OC Chair <proms@jupiter.KT.AGH.EDU.PL>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: PROMS2000 OC Chair <proms@jupiter.KT.AGH.EDU.PL>
Organization: University of Mining and Metallurgy
Subject:      [MOBILE-IP] PROMS2000 CfP
X-To:         tccc <tccc@ieee.org>, itc <itc@ieee.org>,
              cschao <cschao@apollo.iecs.fcu.edu.tw>,
              "dave.ingham" <dave.ingham@ncl.ac.uk>,
              kikn <kikn@ep.u-tokai.ac.jp>,
              "Judy.Holyer" <Judy.Holyer@bristol.ac.uk>, jon <jon@cs.utsa.edu>,
              junzhang <junzhang@ccrl.nj.nec.com>,
              zll <zll@graphics.nju.edu.cn>, madhukar <madhukar@cs.utexas.edu>,
              "M.C.Little" <M.C.Little@ncl.ac.uk>,
              sakaguti <sakaguti@ccm.cl.nec.co.jp>,
              urbano <urbano@mail.eecis.udel.edu>, tang <tang@cs.ucla.edu>,
              pauls <pauls@gte.com>, prasant <prasant@iastate.edu>,
              liu <liu@cis.ohio-state.edu>,
              ichikawa <ichikawa@nttslb.slab.ntt.co.jp>,
              echen <echen@cs.nchu.edu.tw>, sigmob <sigmob@acm.org>,
              chiang <chiang@cis.ohio-state.edu>,
              performance <performance@haven.epm.ornl.gov>,
              agrawal <agrawal@cstp.umkc.edu>,
              cellular <cellular@dfv.rwth-aachen.de>,
              cost237-transport <cost237-transport@comp.lancs.ac.uk>,
              ctc-members <ctc-members@redbank.tinac.com>,
              dbworld <dbworld@cs.wisc.edu>, DMANET <DMANET@zpr.uni-koeln.de>,
              end2end-interest <end2end-interest@isi.edu>,
              enternet <enternet@bbn.com>, hipparch <hipparch@sophia.inria.fr>,
              ieeetcpc <ieeetcpc@ccvm.sunysb.edu>,
              kuvs-elg <kuvs-elg@fokus.gmd.de>, manet <manet@itd.nrl.navy.mil>,
              mobile-ip <mobile-ip@smallworks.com>,
              multicomm <multicomm@cc.bellcore.com>,
              multicomm <multicomm@research.panasonic.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Dear Recipient,

Please find enclosed the Protocols for Multimedia Systems conference
CfP.
Feel free to redistribute this information.
We do apologise if you receive multiple copies of this.

With best regards,
Piotr Pacyna.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

(Please apologize, if you receive multiple copies of this CfP)

                       Announcement and Call for Papers

                  PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000

                       Cracow, Poland, October 22-25, 2000
Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap.
Lucent Technologies
                         http://PROMS2000.kt.agh.edu.pl/

After past successful PROMS conferences held in Berlin, Salzburg,
Madrid, and Santiago de Chile now we cordially invite you to
Cracow/Poland, a lovely university city, with a 1000 year history, today

one of cultural capitals of Europe.

Emerging broadband interactive applications along with a development of
different networking technologies should draw telecom operators' and
service providers' attention to protocols supporting multimedia systems
as an interface between these two environments that has to be still
investigated and modified.

The PROMS2000 conference is intended to contribute to a scientific,
strategical and practical cooperation between research institutes and
industrial companies in the area of distributed multimedia applications,

protocols, and intelligent management tools, with emphasis on their
provision over broadband networks.

PROMS2000 will cover papers and demonstrations on research and
achievements related to the following topics:

TOPICS
* design and implementation of multimedia protocols for public switched
telephony networks, mobile networks, data networks, and satellite
networks using IP, ATM or other connectivity techniques;
* application, media, and protocol integration: synchronization of media

streams;
* multiparty and group communication protocols;
* mobile networking and routing: multimedia communication architectures
for mobile networks;
* multimedia applications: video-on-demand, digital video libraries,
video games, virtual community, teleworking, teleteaching, e-commerce,
telemeeting, virtual reality simulations;
* content based searching and querying;
* techniques for the specification of communication services required by

multimedia applications;
* methods for real-time testing and analysis of service implementations;

* integration of media storage and communication mechanisms, operating
system and high-performance issues;
* experiences with service provisioning using distributed multimedia
applications;
* performance of protocols and applications: modeling, simulation and
optimization in different networks
* multimedia traffic engineering;
* applications and platforms for service management and provisioning;
* definition, provisioning, and supervision of QoS parameters for
networked applications and services;
* intelligent management tools pertaining to costs and quality of
service, network access, accounting, security, and system resilience;
* service access - security, authentication, privacy;
* accounting and tariff policing for multimedia teleservices.

IMPORTANT DATES
* Full papers due                     June 26, 2000
* Authors notified                    July 24, 2000
* Full paper camera ready due         September 25, 2000

CONFERENCE TIMETABLE
* 1st day       October 22      full-day sightseeing tour (optional)
* 2nd day       October 23      tutorials, welcome reception
* 3rd day       October 24      invited talks, sessions, panel, banquet
* 4th day       October 25      invited talks, sessions

VENUE
Its history rooted deep in the Middle Ages, Cracow, is the most
celebrated city in Poland. UNESCO has added its architectural complex to

the World Heritage List. Cracow's appeal today, however, is no longer
attributable solely to the beauty of its medieval architecture, but to
its strong scientific potential for applied research and development.

The PROMS2000 Conference will be held on the modern premises of the
Department of Telecommunications within walking distance of both the
downtown area and hotels. Direct flights to Cracow are available to and
from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris,
Rome, Tel Aviv, Vienna and Zurich.

SUBMISSION
Submit a full manuscript to the PROMS chair in an electronic form
(MSWord, Postscript or pdf file); editorial requirements can be found at

http://PROMS2000.kt.agh.edu.pl/.

CONFERENCE CHAIR
Zdzislaw PAPIR
Department of Telecommunications
University of Mining and Metallurgy
Al. Mickiewicza 30
30-059 Cracow, Poland
E-mail: papir@kt.agh.edu.pl
Phone: +48 12 634 55 82
Fax: +48 12 634 23 72

PROGRAM COMMITTEE
Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp
William Atwood, Univ. Concordia, Bill@cs.Concordia.ca
Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es
Stanislaw Budkowski, INT-Evry, stan@int-evry.fr
Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu
Michel Diaz, LAAS-CNRS, diaz@laas.fr
Wolfgang Effelsberg, Univ. Mannheim,
effelsberg@informatik.uni-mannheim.de
Paolo Fasano, CSELT, Paolo.Fasano@cselt.it
Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt
Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca
Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se
Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at
David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk
Yuji Inoue, NTT, yuji@rd.nttdata.co.jp
Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl
Pedro Lizcano, Telefonica Labs, lizcano@tid.es
John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk
Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl
Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it
Thomas Plagemann, Center for Technology, plageman@unik.no
Radia Perlman, SUN, radia.perlman@sun.com
Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de
Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl
Kazem Sohraby, Lucent, sohraby@lucent.com
Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com
Eduardo Vera, Univ. of Chile, evera@accessnova.cl
Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org

ORGANISING COMMITTEE
Chair: Piotr PACYNA, proms@kt.agh.edu.pl
K. Juszkiewicz, juszkiew@kt.agh.edu.pl
J. Gozdecki, gozdecki@kt.agh.edu.pl
J. Roman, roman@kt.agh.edu.pl


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 14:18:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10917
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 14:18:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B9F5BE0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 14:14:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67438 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 14:12:33 -0500
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.C9F16500@standards.nortelnetworks.com>; Wed, 1 Mar 2000 14:02:32
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Mar  1
          14:05:51 EST 2000
Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean
          [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with
          ESMTP id OAA02106 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed,
          1 Mar 2000 14:05:46 -0500 (EST)
Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id
          OAA15253 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000
          14:05:46 -0500
Mail-Followup-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
References: <20000301135011.M27822@bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: Linux 2.2.12-20
X-Organization: Lucent Technologies, Bell Laboratories
Message-ID:  <20000301140546.N27822@bell-labs.com>
Date:         Wed, 1 Mar 2000 14:05:46 -0500
Reply-To: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000301135011.M27822@bell-labs.com>; from
              lsalgarelli@bell-labs.com on Wed, Mar 01, 2000 at 01:50:11PM -0500

Hi Charley and Frank.

I just wanted to add a few thoughts to your discussion, also in light of
the ongoing discussion about cellular/wireless/fast-handoff support in MIP.

As Frank said, every fast-handoff approach which has been proposed so far
requires the use of a different security semantic than MIP a la rfc2002. In
particular, it is necessary for those approaches not to mandate a
verifiable HA-mobile authenticator in every message, in presence of a
verified trust relationship between the mobile and the foreign domain that
it is visiting.

Now, I agree with Charlie's concerns about introducing an adjustment to
rfc2002bis, where the adjustment, such as in this case, has not been proven
to be interoperable.

On the other hand, I think that leaving the door open for the different
security semantic required by fast-handoff proposals is also an important
issue.

A proposal: would it be possible/enough to add yet another appendix to
rfc2002bis, starting with, for example, the statement proposed by Frank?:

> > >                      Perhaps it would be
> > > better to add a statement like "The Mobile-Home Authentication
> > > Extension is not needed if a security association is established between
> > > the Mobile Node and the foreign network's infrastructure, and the
> > > Registration Reply contains a valid Mobile-Foreign Authentication
> > > Extension." This is already explicitly demanded by the HAWAII draft and
> > > implemented, for example, in HUT Dynamics.

Comments?

Thanks
Luca


> Date:         Tue, 29 Feb 2000 09:22:19 +0100
> Reply-To:     paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE
> Sender:       "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
>               <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> From:         Frank Paehlke <paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE>
> Organization: University of Karlsruhe
> Subject:      Re: micromobility in IPv6 ?
> X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hello,
>
> "Charles E. Perkins" wrote:
> >
> > Hello Frank,
> >
> > I take your comment as relevant to the recently announced Last Call
> > for RFC2002bis.  In that case, we should get some clarification so
> > that I can figure out whether to change the current draft.
>
> many thanks for your interest, which I consider a big honour. Since the
> mentioned comment was my first posting to this list, I was really a bit
> afraid of being flamed.
>
> > > the problem, at least as far as I can tell, is the following sentence
> > > which appears in RFC 2002 as well as in the latest RFC 2002bis draft
> > > (section 3.6.2.1):
> > >
> > > "[...] if the Code field indicates that the registration was accepted
> > > by the home agent, exactly one Mobile-Home Authentication Extension
> > > MUST be present in the Registration Reply, and the mobile node MUST
> > > check the  Authenticator value in the Extension."
> >
> > Yes, the idea being that a mobile node registers _only_ with its
> > home agent.
>
> This is surely the most obvious approach as far as optimized local
> handoff is not an issue. It also guarantees secure mutual authentication
> of an MN and its home agent.
>
> > >                      Perhaps it would be
> > > better to add a statement like "The Mobile-Home Authentication
> > > Extension is not needed if a security association is established between
> > > the Mobile Node and the foreign network's infrastructure, and the
> > > Registration Reply contains a valid Mobile-Foreign Authentication
> > > Extension." This is already explicitly demanded by the HAWAII draft and
> > > implemented, for example, in HUT Dynamics.
> >
> > In the first place, any new protocol specification that advances
> > to Proposed Standard can suggest modifications to RFC2002bis that
> > have the effect of obsoleting part of the prior specification for
> > any network device that adheres to the later specification.
> >
> > Even so, I would agree that minor adjustments to RFC2002bis are
> > preferable to waiting for advancement of other specifications,
> > whenever the adjustments are known to be interoperable and effective
> > and so on.
>
> The idea behind my comment was to facilitate the development of
> specifications which provide fast local handoffs (I am doing research in
> this area, together with some colleagues, for my PhD thesis). As far as
> I can see, such handoffs will have to be carried out without involving
> the HA, which is difficult to achieve without breaking the standard in
> its current form. All proposals for fast handoff (e.g., HAWAII the HUT
> Dynamics implementation) require the establishment of a security
> association between the MN and the foreign network, which is then used
> to authenticate the MN upon subsequent registrations without involving
> the home agent.
>
> > I don't see that this change satisfies those criteria.  But, if
> > others in the working group ask for the change, I would not mind
> > putting something in.
> >
> > One major problem would be to have an unambiguous definition of the
> > words "foreign network's infrastructure".  That's pretty vague, it
> > seems to me.
>
> Probably the most common approach would be to establish a security
> association between the MN and the foreign agent (e.g., as specified in
> the AAA-regkey draft). When saying "foreign network's infrastructure", I
> was thinking that perhaps there could also be a security association
> with some other entity, e.g., a AAA server or the like. In HUT Dynamics,
> for example, the security association is between the MN and *all*
> foreign agents on the path towards the "highest FA".
>
> But as long as these thoughts are relatively vague, I now agree with you
> that it would probably be better to explicitly demand a security
> association between the MN and a foreign agent (old, new, or first
> common parent of old and new). I deliberately chose the wording "a
> statement like..." because I was not 100% sure (and because I am not a
> native speaker of English :-)
>
> Regards,
> Frank Paehlke
> --
> Frank Paehlke
> Institut fuer Telematik       Phone: +49 721 608-6398
> Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
> D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 16:07:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13156
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 16:07:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4EB40C0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:03:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67773 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 16:02:42 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.930BFD00@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:02:42
          -0500
Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com
          (8.9.1a/8.9.1) with ESMTP id MAA26258 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar 2000 12:55:13
          -0800 (PST)
Received: from p7020-img-nt (dhcp-171-69-70-185.cisco.com [171.69.70.185]) by
          rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id NAA28926; Wed, 1 Mar 2000
          13:11:19 -0800
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000301093453.03f3f770@flipper.cisco.com>
Date:         Wed, 1 Mar 2000 09:40:58 -0800
Reply-To: Fred Baker <fred@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> MESSAGE-ID field duplicated. Last occurrence
              was retained.
From: Fred Baker <fred@CISCO.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <7B5C0390ACE7D211BC9C0008C7EABA2B92970D@daeis07nok>

At 09:45 AM 3/1/00 -0600, Basavaraj Patil wrote:
>>that we have: - Link Layer Mobility (Inter-BTS hand-off)
>>- pick a name Mobility (inter-BSC hand-off)
>>- Intra-Domain Mobility (Inter-MSC hand-off)
>>- Inter-Domain Mobility (when the hand-off crosses a domain boundary)

another stab:

keying off the issues that "domain" in IETF circles generally refers to an
administrative domain, often one that is reflected in DNS and/or corporate
ownership, and that at the BTS/BSC level what we're really talking about is
wandering around within a particular cellular-etc technology...

        technology-specific mobility
        inter-technology mobility
        intra-domain mobility
        inter-domain mobility


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 16:44:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13844
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 16:44:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A211B6F0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:38:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 67939 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 16:38:36 -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.312C2750@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:28:35
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA25777 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 14:32:02
          -0700 (MST)]
Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by
          pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA17738 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 1 Mar 2000 14:32:00
          -0700 (MST)]
Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id
          <F7B33D8D>; Wed, 1 Mar 2000 15:31:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <51F347B016ADD011963200805FC1456204BCC069@email1.wes.mot.com>
Date:         Wed, 1 Mar 2000 15:31:44 -0600
Reply-To: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Subject:      [MOBILE-IP] draft agenda
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Gentlefolks,

     here's the draft of the agenda for our meetings in Adelaide.

Phil



Draft Agenda for Mobile IP at 47th IETF

First Session  Mon 1530-1730

Intro and Agenda Bashing 5min
AAA draft-ietf-mobileip-aaa-reqts-01.txt Tom Hiller 10min
AAA and IPv6 ?  Charlie Perkins 15min
AAA Keys draft-ietf-mobileip-aaa-keys-01.txt Pat Calhoun 10min
Registration Keys draft-ietf-mobileip-regkeys-01.txt Charlie Perkins 20min
Low Latency Secure Handoff draft-calhoun-mobileip-min-lat-handoff-00.txt Pat
Calhoun 10min
FA assisted handoff draft-calhoun-mobileip-proactive-fa-00.txt 20min
Fast Handover ? Gopal Dommety 15min
Fast Handoffs and Routing in Hierarchical Mobile IP ? Karim El-Malki 15min


Second Session  Tue 0900-1130
Announcement on Connectathon 2000 MIP/AAA/MIPv6 Carl Williams 10min
Xu Mobile IP in 3gWireless draft-ietf-mobileip-3Gwireless-ext-02.txt 15min
GRE draft ? Gopal Dommety 10min
Private IP addresses draft-petri-mobileip-pipe-00.txt  Petri Bernhard 20min
IPv6 draft 10min
RFC2002bis Charlie Perkins 10min
Reverse Tunneling draft-ietf-mobileip-rfc2344-bis-00.txt Gabriel Montenegro
10min
Route Optimization draft-ietf-mobileip-optim-09.txt Charlie Perkins 10min
Regional Registration draft-ietf-mobileip-reg-tunnel-01.txt Eva Gustaffson
15min
Universal Mobile IP ?  John Wang  20min
Generalize NAI draft-mkalil-gnaie-00.txt Pat Calhoun 10min
Dyn HA allocation for multiple sessions ?  Kent Leung 10min


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 18:15:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16161
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 18:15:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84605280@standards.nortelnetworks.com>; Wed, 1 Mar 2000 18:11:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 68132 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 18:09:10 -0500
Received: from hoemail2.firewall.lucent.com (192.11.226.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3DD8E700@standards.nortelnetworks.com>; Wed, 1 Mar 2000
          18:09:10 -0500
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA27165
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar 2000
          18:12:41 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id SAA27156 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Wed, 1 Mar 2000 18:12:40 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <1P82DVXK>; Wed, 1 Mar 2000 23:12:40 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C048769E7@en0060exch001u.uk.lucent.com>
Date:         Wed, 1 Mar 2000 23:12:38 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Any new rechartering should also consider
whether the goal is completing the MIP work
or opening an entire new activity.

If the goal is to solve "mobility in the small", or in access
nets, as I understand some folks are aiming at when they talk
about Fast Handovers, then probably an entire new WG is likely
to be needed.

A spinoff of the MIP WG, say  MIPSAT WG
(IP mobility support over Specific Access Technologies)
would probably be a good thing, accommodating
any need to address specific problems that
MIP is considered not sufficient to address over
specific access Technologies. Also this would
come with the benefit of providing a well defined
scope for each new proposal coming in.

There may be another approach (AKA "the tail that
wags the dog") that is defining a new access network
based on newly IETF specified access protocols, but this
probably would not be useful for some technologies
currently (or about to be) on the
marketplace (cellular and non cellular). It looks
like a long term work.

Which of the two? Both? or none?

alessio

> ----------
> From:         Fred Baker[SMTP:fred@CISCO.COM]
> Reply To:     Fred Baker
> Sent:         01 March 2000 17:40
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter
> update?)
>
> At 09:45 AM 3/1/00 -0600, Basavaraj Patil wrote:
> >>that we have: - Link Layer Mobility (Inter-BTS hand-off)
> >>- pick a name Mobility (inter-BSC hand-off)
> >>- Intra-Domain Mobility (Inter-MSC hand-off)
> >>- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>
> another stab:
>
> keying off the issues that "domain" in IETF circles generally refers to an
> administrative domain, often one that is reflected in DNS and/or corporate
> ownership, and that at the BTS/BSC level what we're really talking about
> is
> wandering around within a particular cellular-etc technology...
>
>         technology-specific mobility
>         inter-technology mobility
>         intra-domain mobility
>         inter-domain mobility
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 18:31:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16581
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 18:31:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2DA5CC0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 18:27:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 68184 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 18:26:03 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.99F7BFA0@standards.nortelnetworks.com>; Wed, 1 Mar 2000
          18:26:03 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 17:25:50 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 1
          Mar 2000 18:25:06 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5XR6CA>; Wed, 1 Mar 2000 17:25:05 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF83D5.5FF26BBE"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93D4@crchy271.us.nortel.com>
Date:         Wed, 1 Mar 2000 17:25:04 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF83D5.5FF26BBE
Content-Type: text/plain;
        charset="iso-8859-1"



> -----Original Message-----
> From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM]
> Sent: Wednesday, March 01, 2000 5:13 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP]
> charter update?)
>
>
> Any new rechartering should also consider
> whether the goal is completing the MIP work
> or opening an entire new activity.
>
> If the goal is to solve "mobility in the small", or in access
> nets, as I understand some folks are aiming at when they talk
> about Fast Handovers, then probably an entire new WG is likely
> to be needed.
>
> A spinoff of the MIP WG, say  MIPSAT WG
> (IP mobility support over Specific Access Technologies)
> would probably be a good thing, accommodating
> any need to address specific problems that
> MIP is considered not sufficient to address over
> specific access Technologies. Also this would
> come with the benefit of providing a well defined
> scope for each new proposal coming in.

An interesting thought.

>
> There may be another approach (AKA "the tail that
> wags the dog") that is defining a new access network
> based on newly IETF specified access protocols, but this
> probably would not be useful for some technologies
> currently (or about to be) on the
> marketplace (cellular and non cellular). It looks
> like a long term work.
>
> Which of the two? Both? or none?
>
> alessio
>
> > ----------
> > From:         Fred Baker[SMTP:fred@CISCO.COM]
> > Reply To:     Fred Baker
> > Sent:         01 March 2000 17:40
> > To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter
> > update?)
> >
> > At 09:45 AM 3/1/00 -0600, Basavaraj Patil wrote:
> > >>that we have: - Link Layer Mobility (Inter-BTS hand-off)
> > >>- pick a name Mobility (inter-BSC hand-off)
> > >>- Intra-Domain Mobility (Inter-MSC hand-off)
> > >>- Inter-Domain Mobility (when the hand-off crosses a
> domain boundary)
> >
> > another stab:
> >
> > keying off the issues that "domain" in IETF circles
> generally refers to an
> > administrative domain, often one that is reflected in DNS
> and/or corporate
> > ownership, and that at the BTS/BSC level what we're really
> talking about
> > is
> > wandering around within a particular cellular-etc technology...
> >
> >         technology-specific mobility
> >         inter-technology mobility
> >         intra-domain mobility
> >         inter-domain mobility
> >
>

------_=_NextPart_001_01BF83D5.5FF26BBE
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Casati, Alessio (Alessio) [<A HREF="mailto:acasati@LUCENT.COM">mailto:acasati@LUCENT.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, March 01, 2000 5:13 PM</FONT>
<BR><FONT SIZE=2>&gt; To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] </FONT>
<BR><FONT SIZE=2>&gt; charter update?)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Any new rechartering should also consider</FONT>
<BR><FONT SIZE=2>&gt; whether the goal is completing the MIP work</FONT>
<BR><FONT SIZE=2>&gt; or opening an entire new activity.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If the goal is to solve &quot;mobility in the small&quot;, or in access</FONT>
<BR><FONT SIZE=2>&gt; nets, as I understand some folks are aiming at when they talk</FONT>
<BR><FONT SIZE=2>&gt; about Fast Handovers, then probably an entire new WG is likely</FONT>
<BR><FONT SIZE=2>&gt; to be needed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A spinoff of the MIP WG, say&nbsp; MIPSAT WG</FONT>
<BR><FONT SIZE=2>&gt; (IP mobility support over Specific Access Technologies)</FONT>
<BR><FONT SIZE=2>&gt; would probably be a good thing, accommodating</FONT>
<BR><FONT SIZE=2>&gt; any need to address specific problems that</FONT>
<BR><FONT SIZE=2>&gt; MIP is considered not sufficient to address over</FONT>
<BR><FONT SIZE=2>&gt; specific access Technologies. Also this would</FONT>
<BR><FONT SIZE=2>&gt; come with the benefit of providing a well defined</FONT>
<BR><FONT SIZE=2>&gt; scope for each new proposal coming in.</FONT>
</P>

<P><FONT SIZE=2>An interesting thought.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There may be another approach (AKA &quot;the tail that</FONT>
<BR><FONT SIZE=2>&gt; wags the dog&quot;) that is defining a new access network</FONT>
<BR><FONT SIZE=2>&gt; based on newly IETF specified access protocols, but this</FONT>
<BR><FONT SIZE=2>&gt; probably would not be useful for some technologies</FONT>
<BR><FONT SIZE=2>&gt; currently (or about to be) on the</FONT>
<BR><FONT SIZE=2>&gt; marketplace (cellular and non cellular). It looks</FONT>
<BR><FONT SIZE=2>&gt; like a long term work.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Which of the two? Both? or none?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; alessio</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; ----------</FONT>
<BR><FONT SIZE=2>&gt; &gt; From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fred Baker[SMTP:fred@CISCO.COM]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Reply To:&nbsp;&nbsp;&nbsp;&nbsp; Fred Baker</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 01 March 2000 17:40</FONT>
<BR><FONT SIZE=2>&gt; &gt; To:&nbsp;&nbsp; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter</FONT>
<BR><FONT SIZE=2>&gt; &gt; update?)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; At 09:45 AM 3/1/00 -0600, Basavaraj Patil wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;that we have: - Link Layer Mobility (Inter-BTS hand-off)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;- pick a name Mobility (inter-BSC hand-off)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;- Intra-Domain Mobility (Inter-MSC hand-off)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&gt;- Inter-Domain Mobility (when the hand-off crosses a </FONT>
<BR><FONT SIZE=2>&gt; domain boundary)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; another stab:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; keying off the issues that &quot;domain&quot; in IETF circles </FONT>
<BR><FONT SIZE=2>&gt; generally refers to an</FONT>
<BR><FONT SIZE=2>&gt; &gt; administrative domain, often one that is reflected in DNS </FONT>
<BR><FONT SIZE=2>&gt; and/or corporate</FONT>
<BR><FONT SIZE=2>&gt; &gt; ownership, and that at the BTS/BSC level what we're really </FONT>
<BR><FONT SIZE=2>&gt; talking about</FONT>
<BR><FONT SIZE=2>&gt; &gt; is</FONT>
<BR><FONT SIZE=2>&gt; &gt; wandering around within a particular cellular-etc technology...</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technology-specific mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inter-technology mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; intra-domain mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inter-domain mobility</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF83D5.5FF26BBE--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  1 18:56:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17933
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 1 Mar 2000 18:56:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.438A3630@standards.nortelnetworks.com>; Wed, 1 Mar 2000 18:52:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 68239 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 18:50:17 -0500
Received: from mail.eecs.uic.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.968DCEC0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 18:40:16
          -0500
Received: from oscar.eecs.uic.edu (oscar.eecs.uic.edu [131.193.41.34]) by
          mail.eecs.uic.edu (8.9.3/8.9.3) with ESMTP id RAA20166 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar 2000 17:41:44
          -0600 (CST)
Received: from localhost by oscar.eecs.uic.edu (8.9.3/8.9.3) with SMTP id
          RAA15663 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 1 Mar
          2000 17:44:23 -0600 (CST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GSO.3.96.1000301174100.15444A-100000@oscar.eecs.uic.edu>
Date:         Wed, 1 Mar 2000 17:44:23 -0600
Reply-To: Debalina Ghosh <dghosh@eecs.uic.edu>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Debalina Ghosh <dghosh@eecs.uic.edu>
Subject:      [MOBILE-IP] rFC2002-BIS
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I think that route optimization should be mentioned somewhere in the rfc
and a reference to it should be given. Please correct me if I am wrong.

Regards
Debalina Ghosh


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 05:04:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09342
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 05:04:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30EE1C30@standards.nortelnetworks.com>; Thu, 2 Mar 2000 5:00:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 68921 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 04:58:12 -0500
Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.E918D3F0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 4:58:12
          -0500
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227]
          (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP
          id LAA25899; Thu, 2 Mar 2000 11:00:42 +0100 (MET)
Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by
          blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA14680; Thu, 2
          Mar 2000 10:59:00 +0100 (MET)
Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id <FLV9Y0X8>;
          Thu, 2 Mar 2000 11:02:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <DF21F4BE7BE3D2119E790060086E64FE80492D@mchh207e.demchh201e.oen.siemens.de>
Date:         Thu, 2 Mar 2000 11:02:05 +0100
Reply-To: Petri Bernhard <Bernhard.Petri@ICN.SIEMENS.DE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Petri Bernhard <Bernhard.Petri@ICN.SIEMENS.DE>
Subject:      Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ?
X-To:         Gabriel Montenegro <gab@eng.sun.com>
X-cc:         "ion@sunroof.eng.sun.com" <ion@sunroof.eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Gabriel,

my proposal wasn't to take oui's as another name space. Instead, I think,
the basic question is whether to solve the handling of private IP addresses
in Mobile IP by a kind of dns/nai-like solution or by something more
directly related to the IP level itself. NAIs are currently used for
authentication and identification purposes, and  by using them, you can
benefit from the existing DNS infrastructure. However,  I currently don't
see yet, how they could efficiently be inserted into every IP packet, e.g.
between FA and HA (the HA somehow has to find the realm, a private IP
address received in an IP packet belongs to). I would be very interested in
your ideas about this.

With regard to your questions on OUIs and realms, please note that not the
OUI, but the whole VPN-ID (= OUI + index value, see RFC 2685) would be used
to identify an IP address realm. This allows for various possibile uses or
allocation algorithms, e.g.:

- a big company runs its own corporate network, and uses one or more private
address realms. In this case, the company may use its own OUI, and may
allocate various identifiers for the particular realms
- small companies may use the services of a network operator or service
provider. If they use a private addressing realm, they may retrieve an index
value from their operator or service provider
- there's also the possibility that IANA acts as a neutral source for the
allocation realm-IDs based on IANA's own OUI (0x00-00-5E). Although this is
just a single OUI, it would allow IANA to allocate as much realm-IDs as we
currently have IP addresses (4 byte value).

Your suggestion to use AS numbers for the VPN-ID, and its implication of
having one VPN-ID / realm ID per AS domain, was also discussed in the ION
group at that time. The agreed format of the VPN-ID somehow reflects a
compromise on this. While most people want to have their VPN-IDs / realm-IDs
to be independent from the specific BGP-4 protocol domains, some in fact
wanted to have 1 realm-ID per BGP-4 domain. The latter was the reason for
the extension of the initial 3-octet index value (as in current MAC
addresses) to 4-octets; this allows to sub-structure the index-values for a
particular OUI into: 2-octet ASN + 2 octet ASN-specific index value.

Looking forward to some more talks on this in Adelaide

Kind regards
- Bernhard

Bernhard Petri, Siemens
Tel: +49 89 722-34578
Fax: +49 89 722-29098
bernhard.petri@icn.siemens.de
______________________________

> -----Original Message-----
> From: Gabriel Montenegro [SMTP:gab@eng.sun.com]
> Sent: Saturday, February 26, 2000 1:59 AM
> To:   Petri Bernhard
> Cc:   'Gabriel Montenegro'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM;
> 'ion@sunroof.eng.sun.com'
> Subject:      RE: [MOBILE-IP] Private addressing reference in rfc2002-bis
> ?
>
> interesting, thanks for the pointer to the vpn-id stuff.
> hmmm... oui's are another name space...
>
> what i like about realm names is that there is no extra
> administration overhead and they are already used within the
> nai. from rfc2486 (nai):
>
>    This document defines a new namespace that will need to be
>    administered, namely the NAI realm namespace. In order to to avoid
>    creating any new administrative procedures, administration of the NAI
>    realm namespace will piggyback on the administration of the DNS
>    namespace.
>
>    NAI realm names are required to be unique and the rights to use a
>    given NAI realm for roaming purposes are obtained coincident with
>    acquiring the rights to use a particular fully qualified domain name
>    (FQDN).  Those wishing to use an NAI realm name should first acquire
>    the rights to use the corresponding FQDN. Using an NAI realm without
>    ownership of the corresponding FQDN creates the possibility of
>    conflict and therefore is to be discouraged.
>
> also, what is the oui for the root realm?
>
> not all realms will map to a unique oui. in order to specify different
> realms (for example for small/informal/impromptu/soho), owners of oui's
> might
> have to get in the business of further administering the subsequent
> 4 byte octet index value in the vpn-id, to avoid collisions. it gets
> messy, specially because the small network operators (driving forces
> behind nats and rsip applications) now have to ask a much larger
> corporation (large enough to own an oui) to allocate some vpn-id
> space for them. perhaps oui's work best at the high-end, with large
> corporations and ISP's. not sure they're a good easy thing to use
> for smaller networks, where a DNS domain name may be simpler.
>
> by the way, if the idea is to use a fixed size binary representation
> for a "vpn-id", did the ion working group consider
>
> in addition to this:
>
>       3 octet oui + 4 octet index value
>
> this?:
>
>       2 octet ASN (autonomous system number) + 4 octet index value
>
> saves you one byte, but most importantly, it reuses stuff that's
> already needed as a precondition to getting on the internet.
> seems like both oui and asn variations could be useful.
>
> regards,
>
> -gabriel


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 07:56:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11319
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 07:56:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F63F7300@standards.nortelnetworks.com>; Thu, 2 Mar 2000 7:50:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69044 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 07:48:30 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B34DD870@standards.nortelnetworks.com>; Thu, 2 Mar 2000 7:48:29
          -0500
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se
          [153.88.251.29]) by penguin.wise.edt.ericsson.se
          (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id NAA26335 for
          <MOBILE-IP@standards.nortelnetworks.com>; Thu, 2 Mar 2000 13:52:02
          +0100 (MET)
Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with
          Microsoft SMTPSVC(5.0.2172.1); Thu, 2 Mar 2000 13:51:54 +0100
Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.29
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 02 Mar 2000
          12:51:54 0000 (GMT)
Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id <G1NG0Z35>;
          Thu, 2 Mar 2000 13:51:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 02 Mar 2000 12:51:54.0609 (UTC)
                       FILETIME=[16487E10:01BF8446]
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA7EEE@esealnt190>
Date:         Thu, 2 Mar 2000 13:51:43 +0100
Reply-To: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
Subject:      Re: [MOBILE-IP] Charter Update
X-To:         "Basavaraj.Patil@NOKIA.COM" <Basavaraj.Patil@NOKIA.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>  One more thing:
>  Handoff solutions that the WG needs to work on need to be
>  applicable to both IPv4/6.
>
>  -Basavaraj

I agree.
For this same reason in Adelaide we will be presenting a
draft describing a Hierarchical extension to MIPv6 and
Fast Handoffs for both Hierarchical MIPv4 (Regional Tunnel Mgt.)
and Hierarchical MIPv6. Fast Handoffs for Hierarchical MIPv4
was already described in a previous draft presented in Oslo
(draft-elmalki-mobileip-fast-handoffs..).
The new draft will be out soon.

Rgds,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 09:21:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13461
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 09:21:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.056ED0D0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 9:16:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69242 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 09:16:22 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.94335900@standards.nortelnetworks.com>;
          Thu, 2 Mar 2000 9:06:21 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id HAA12633; Thu, 2 Mar 2000 07:08:32
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.95.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA09086; Thu, 2 Mar
          2000 06:07:30 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA29381; Thu, 2 Mar 2000 06:07:30 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952006050.27560.pcalhoun@ha1mpk-mail>
Date:         Thu, 2 Mar 2000 06:07:30 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <7B5C0390ACE7D211BC9C0008C7EABA2B92970D@daeis07nok>

> >
> >All,
> >
>
> ----snip snip-----
>
> >So, I would like to propose that we agree on some new terminology. I
> believe
> >that we have: - Link Layer Mobility (Inter-BTS hand-off)
> >- pick a name Mobility (inter-BSC hand-off)
> >- Intra-Domain Mobility (Inter-MSC hand-off)
> >- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> >
>
> Pat,
>
> Agreeing on terminology is something that we need to strive for. But
> the ones that you mention here are very specific to 2G Wireless/Cellular
> networks. It would be better to be more generic or just map them to
> functional entities that would exist in any type of network.

agreed. As I mentioned in the thread, I used these examples to provide some
context, but more generalized examples would be preferred.

>
>
> >I still don't have a preference for the second name, and I am not married
> to
> >ANY of the names above. These are merely suggestions. The goal here is to
> ALL
> >agree on basic terminology so that when we compare protocols, we can match
> the
> >protocol against a set of common terminology.
> >
> >Comments? Is this a worthwhile exercise?
>
> Does the WG need to develop a terminology document that can be
> referenced by all WG and Mobile IP related docs? It may be a
> worthwhile exercise and help us all to be on the same page.

I think that this would be a worthwhile exercise, would I would caution us
putting our existing milestones in jeopardy by doing so.

PatC
>
> -Basavaraj
>
>
> >
> >PatC
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 09:33:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13733
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 09:33:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8579FD0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 9:29:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69266 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 09:27:46 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.2BAEAF90@standards.nortelnetworks.com>;
          Thu, 2 Mar 2000 9:17:45 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id HAA17638; Thu, 2 Mar 2000 07:21:15
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.93.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA09816; Thu, 2 Mar
          2000 06:20:14 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA07840; Thu, 2 Mar 2000 06:20:14 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952006813.31462.pcalhoun@ha1mpk-mail>
Date:         Thu, 2 Mar 2000 06:20:13 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Charter Update
X-To:         Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <20000301170259.A82C157042@king.research.bell-labs.com>

Not sure this thread really belongs here, but...


> Hi, Basavaraj,
>
> I agree with your message below - I think we need to be very cautious
> about expanding the charter of the WG to be too cellular-specific.
> This is the Mobile IP working group, which means that we should be
> defining IP-layer protocols.

agreed, and specifying a better (or faster) hand-off mechanism isn't
cellular-specific, but as you and Raj state, it can be used by these people.
What we need to do is make Mobile IP provide the functionality that they need,
not try to design their networks/systems.

>
> There are some link-layer specific questions that need to be
> addressed, in terms of how a Mobile IP Foreign Agent should be "glued"
> onto the cellular wireless link layer.
> draft-ietf-mobileip-3gwireless-ext-02.txt does this pretty well.
> However, I do not think we should try to start standardizing other
> aspects of a 3rd generation cellular network.  I think some people are
> trying to plan a BOF in Adelaide called "IP to the Base Station" that
> could address some of these questions, but I am concerned that the
> IETF has a fairly limited understanding of the cellular link layer,
> especially as it pertains to CDMA - I've read and heard statements
> that reveal a certain lack of knowledge of how a CDMA Selection and
> Distribution Unit really work, when people try to get IP packets sent
> by a MN directly out of a BTS.  Of course, I've also seen people here
> who *do* understand the technology quite well - I don't mean to start
> a flame war, but I think this kind of work logically belongs in the
> respective 3GPPs for each technology.

Well, I for one will be at this BOF, and I agree that many people don't fully
understand how the macro diversity combiner works. However, I think that it is
a reasonable goal to allow the *control* protocol between the BSC and the BTS
to run over an IP network. Furthermore, once IP is in the BTS, one can
centrally manage it using off the shelf tools, etc.

As for data, is switching or routing better, I'm not conviced the latter is
the right design choice. A layer 2 approach, such as MPLS, may be appropriate.

>
> Certainly the Mobile IP WG should strive to develop an understanding
> of the various link-layer technologies so that its protocols are as
> widely applicable as possible, and perform well for multimedia
> applications.  However, I do not think we should get in the business
> of standardizing link layers.

right.

PatC
>
> -Pete
>
> Basavaraj Patil <Basavaraj.Patil@NOKIA.COM> (BP) writes:
>
> BP> Just to clarify what the intent of increasing the scope
> BP> of the charter is :
>
> BP> We are increasingly seeing proposals to the Mobile IP WG
> BP> that deal with handoffs. The cellular/wireless environment
> BP> is where handoffs are a critical function. The WG needs to
> BP> address this domain without necessarily having to become a
> BP> "Mobile IP for Cellular" WG. I need to reiterate that the
> BP> solutions developed in this WG are applicable across different
> BP> types of access and core networks.
>
> BP> One more thing:
> BP> Handoff solutions that the WG needs to work on need to be
> BP> applicable to both IPv4/6.
>
> BP> -Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 09:40:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13830
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 09:40:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0B75140@standards.nortelnetworks.com>; Thu, 2 Mar 2000 9:35:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69297 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 09:34:44 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.24EC3A50@standards.nortelnetworks.com>;
          Thu, 2 Mar 2000 9:24:43 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id HAA20650; Thu, 2 Mar 2000 07:28:14
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.93.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA10197; Thu, 2 Mar
          2000 06:27:13 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          GAA12413; Thu, 2 Mar 2000 06:27:12 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952007232.5355.pcalhoun@ha1mpk-mail>
Date:         Thu, 2 Mar 2000 06:27:12 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
X-To:         Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <20000301140546.N27822@bell-labs.com>

> Hi Charley and Frank.
>
> I just wanted to add a few thoughts to your discussion, also in light of
> the ongoing discussion about cellular/wireless/fast-handoff support in MIP.
>
> As Frank said, every fast-handoff approach which has been proposed so far
> requires the use of a different security semantic than MIP a la rfc2002. In
> particular, it is necessary for those approaches not to mandate a
> verifiable HA-mobile authenticator in every message, in presence of a
> verified trust relationship between the mobile and the foreign domain that
> it is visiting.
>
> Now, I agree with Charlie's concerns about introducing an adjustment to
> rfc2002bis, where the adjustment, such as in this case, has not been proven
> to be interoperable.
>
> On the other hand, I think that leaving the door open for the different
> security semantic required by fast-handoff proposals is also an important
> issue.
>
> A proposal: would it be possible/enough to add yet another appendix to
> rfc2002bis, starting with, for example, the statement proposed by Frank?:
>
> > > >                      Perhaps it would be
> > > > better to add a statement like "The Mobile-Home Authentication
> > > > Extension is not needed if a security association is established between
> > > > the Mobile Node and the foreign network's infrastructure, and the
> > > > Registration Reply contains a valid Mobile-Foreign Authentication
> > > > Extension." This is already explicitly demanded by the HAWAII draft and
> > > > implemented, for example, in HUT Dynamics.

And I thought that this was a given in Hierarchical Mobile IP, since the
Registration doesn't make it all the way back to the Home Agent. It sounds
like a reasonable change, but I need to think a little more about the possible
security implications.


PatC
>
> Comments?
>
> Thanks
> Luca
>
>
> > Date:         Tue, 29 Feb 2000 09:22:19 +0100
> > Reply-To:     paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE
> > Sender:       "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
> >               <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> > From:         Frank Paehlke <paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE>
> > Organization: University of Karlsruhe
> > Subject:      Re: micromobility in IPv6 ?
> > X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Hello,
> >
> > "Charles E. Perkins" wrote:
> > >
> > > Hello Frank,
> > >
> > > I take your comment as relevant to the recently announced Last Call
> > > for RFC2002bis.  In that case, we should get some clarification so
> > > that I can figure out whether to change the current draft.
> >
> > many thanks for your interest, which I consider a big honour. Since the
> > mentioned comment was my first posting to this list, I was really a bit
> > afraid of being flamed.
> >
> > > > the problem, at least as far as I can tell, is the following sentence
> > > > which appears in RFC 2002 as well as in the latest RFC 2002bis draft
> > > > (section 3.6.2.1):
> > > >
> > > > "[...] if the Code field indicates that the registration was accepted
> > > > by the home agent, exactly one Mobile-Home Authentication Extension
> > > > MUST be present in the Registration Reply, and the mobile node MUST
> > > > check the  Authenticator value in the Extension."
> > >
> > > Yes, the idea being that a mobile node registers _only_ with its
> > > home agent.
> >
> > This is surely the most obvious approach as far as optimized local
> > handoff is not an issue. It also guarantees secure mutual authentication
> > of an MN and its home agent.
> >
> > > >                      Perhaps it would be
> > > > better to add a statement like "The Mobile-Home Authentication
> > > > Extension is not needed if a security association is established between
> > > > the Mobile Node and the foreign network's infrastructure, and the
> > > > Registration Reply contains a valid Mobile-Foreign Authentication
> > > > Extension." This is already explicitly demanded by the HAWAII draft and
> > > > implemented, for example, in HUT Dynamics.
> > >
> > > In the first place, any new protocol specification that advances
> > > to Proposed Standard can suggest modifications to RFC2002bis that
> > > have the effect of obsoleting part of the prior specification for
> > > any network device that adheres to the later specification.
> > >
> > > Even so, I would agree that minor adjustments to RFC2002bis are
> > > preferable to waiting for advancement of other specifications,
> > > whenever the adjustments are known to be interoperable and effective
> > > and so on.
> >
> > The idea behind my comment was to facilitate the development of
> > specifications which provide fast local handoffs (I am doing research in
> > this area, together with some colleagues, for my PhD thesis). As far as
> > I can see, such handoffs will have to be carried out without involving
> > the HA, which is difficult to achieve without breaking the standard in
> > its current form. All proposals for fast handoff (e.g., HAWAII the HUT
> > Dynamics implementation) require the establishment of a security
> > association between the MN and the foreign network, which is then used
> > to authenticate the MN upon subsequent registrations without involving
> > the home agent.
> >
> > > I don't see that this change satisfies those criteria.  But, if
> > > others in the working group ask for the change, I would not mind
> > > putting something in.
> > >
> > > One major problem would be to have an unambiguous definition of the
> > > words "foreign network's infrastructure".  That's pretty vague, it
> > > seems to me.
> >
> > Probably the most common approach would be to establish a security
> > association between the MN and the foreign agent (e.g., as specified in
> > the AAA-regkey draft). When saying "foreign network's infrastructure", I
> > was thinking that perhaps there could also be a security association
> > with some other entity, e.g., a AAA server or the like. In HUT Dynamics,
> > for example, the security association is between the MN and *all*
> > foreign agents on the path towards the "highest FA".
> >
> > But as long as these thoughts are relatively vague, I now agree with you
> > that it would probably be better to explicitly demand a security
> > association between the MN and a foreign agent (old, new, or first
> > common parent of old and new). I deliberately chose the wording "a
> > statement like..." because I was not 100% sure (and because I am not a
> > native speaker of English :-)
> >
> > Regards,
> > Frank Paehlke
> > --
> > Frank Paehlke
> > Institut fuer Telematik       Phone: +49 721 608-6398
> > Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
> > D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 10:13:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14517
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 10:13:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.520C4B50@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:08:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69406 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 10:08:36 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E0063080@standards.nortelnetworks.com>; Thu, 2 Mar 2000 9:58:35
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF31@monza.broadswitch.com>
Date:         Thu, 2 Mar 2000 16:02:01 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
X-To:         Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Luca, I could not agree with you more...
Related work has been done in whats used to be called transport friendly
ipsec but I agree with you that we need a "mobile-optimized" mode of session
key generation/re-generation of IPsec...

/Thomas

> -----Original Message-----
> From: Luca Salgarelli [mailto:lsalgarelli@BELL-LABS.COM]
> Sent: Wednesday, March 01, 2000 8:06 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] micromobility in IPv6 ?
>
>
> Hi Charley and Frank.
>
> I just wanted to add a few thoughts to your discussion, also
> in light of
> the ongoing discussion about cellular/wireless/fast-handoff
> support in MIP.
>
> As Frank said, every fast-handoff approach which has been
> proposed so far
> requires the use of a different security semantic than MIP a
> la rfc2002. In
> particular, it is necessary for those approaches not to mandate a
> verifiable HA-mobile authenticator in every message, in presence of a
> verified trust relationship between the mobile and the
> foreign domain that
> it is visiting.
>
> Now, I agree with Charlie's concerns about introducing an
> adjustment to
> rfc2002bis, where the adjustment, such as in this case, has
> not been proven
> to be interoperable.
>
> On the other hand, I think that leaving the door open for the
> different
> security semantic required by fast-handoff proposals is also
> an important
> issue.
>
> A proposal: would it be possible/enough to add yet another appendix to
> rfc2002bis, starting with, for example, the statement
> proposed by Frank?:
>
> > > >                      Perhaps it would be
> > > > better to add a statement like "The Mobile-Home Authentication
> > > > Extension is not needed if a security association is
> established between
> > > > the Mobile Node and the foreign network's
> infrastructure, and the
> > > > Registration Reply contains a valid Mobile-Foreign
> Authentication
> > > > Extension." This is already explicitly demanded by the
> HAWAII draft and
> > > > implemented, for example, in HUT Dynamics.
>
> Comments?
>
> Thanks
> Luca
>
>
> > Date:         Tue, 29 Feb 2000 09:22:19 +0100
> > Reply-To:     paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE
> > Sender:       "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
> >               <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
> > From:         Frank Paehlke
> <paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE>
> > Organization: University of Karlsruhe
> > Subject:      Re: micromobility in IPv6 ?
> > X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Hello,
> >
> > "Charles E. Perkins" wrote:
> > >
> > > Hello Frank,
> > >
> > > I take your comment as relevant to the recently announced
> Last Call
> > > for RFC2002bis.  In that case, we should get some clarification so
> > > that I can figure out whether to change the current draft.
> >
> > many thanks for your interest, which I consider a big
> honour. Since the
> > mentioned comment was my first posting to this list, I was
> really a bit
> > afraid of being flamed.
> >
> > > > the problem, at least as far as I can tell, is the
> following sentence
> > > > which appears in RFC 2002 as well as in the latest RFC
> 2002bis draft
> > > > (section 3.6.2.1):
> > > >
> > > > "[...] if the Code field indicates that the
> registration was accepted
> > > > by the home agent, exactly one Mobile-Home
> Authentication Extension
> > > > MUST be present in the Registration Reply, and the
> mobile node MUST
> > > > check the  Authenticator value in the Extension."
> > >
> > > Yes, the idea being that a mobile node registers _only_ with its
> > > home agent.
> >
> > This is surely the most obvious approach as far as optimized local
> > handoff is not an issue. It also guarantees secure mutual
> authentication
> > of an MN and its home agent.
> >
> > > >                      Perhaps it would be
> > > > better to add a statement like "The Mobile-Home Authentication
> > > > Extension is not needed if a security association is
> established between
> > > > the Mobile Node and the foreign network's
> infrastructure, and the
> > > > Registration Reply contains a valid Mobile-Foreign
> Authentication
> > > > Extension." This is already explicitly demanded by the
> HAWAII draft and
> > > > implemented, for example, in HUT Dynamics.
> > >
> > > In the first place, any new protocol specification that advances
> > > to Proposed Standard can suggest modifications to RFC2002bis that
> > > have the effect of obsoleting part of the prior specification for
> > > any network device that adheres to the later specification.
> > >
> > > Even so, I would agree that minor adjustments to RFC2002bis are
> > > preferable to waiting for advancement of other specifications,
> > > whenever the adjustments are known to be interoperable
> and effective
> > > and so on.
> >
> > The idea behind my comment was to facilitate the development of
> > specifications which provide fast local handoffs (I am
> doing research in
> > this area, together with some colleagues, for my PhD
> thesis). As far as
> > I can see, such handoffs will have to be carried out
> without involving
> > the HA, which is difficult to achieve without breaking the
> standard in
> > its current form. All proposals for fast handoff (e.g.,
> HAWAII the HUT
> > Dynamics implementation) require the establishment of a security
> > association between the MN and the foreign network, which
> is then used
> > to authenticate the MN upon subsequent registrations
> without involving
> > the home agent.
> >
> > > I don't see that this change satisfies those criteria.  But, if
> > > others in the working group ask for the change, I would not mind
> > > putting something in.
> > >
> > > One major problem would be to have an unambiguous
> definition of the
> > > words "foreign network's infrastructure".  That's pretty vague, it
> > > seems to me.
> >
> > Probably the most common approach would be to establish a security
> > association between the MN and the foreign agent (e.g., as
> specified in
> > the AAA-regkey draft). When saying "foreign network's
> infrastructure", I
> > was thinking that perhaps there could also be a security association
> > with some other entity, e.g., a AAA server or the like. In
> HUT Dynamics,
> > for example, the security association is between the MN and *all*
> > foreign agents on the path towards the "highest FA".
> >
> > But as long as these thoughts are relatively vague, I now
> agree with you
> > that it would probably be better to explicitly demand a security
> > association between the MN and a foreign agent (old, new, or first
> > common parent of old and new). I deliberately chose the wording "a
> > statement like..." because I was not 100% sure (and because
> I am not a
> > native speaker of English :-)
> >
> > Regards,
> > Frank Paehlke
> > --
> > Frank Paehlke
> > Institut fuer Telematik       Phone: +49 721 608-6398
> > Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
> > D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 10:23:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14677
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 10:23:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9876CA0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:18:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69492 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 10:17:34 -0500
Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.86B74E80@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:17:34
          -0500
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com
          [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with
          ESMTP id JAA10908; Thu, 2 Mar 2000 09:19:55 -0600 (CST)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service
          (5.5.2650.21) id <F7X3YRN3>; Thu, 2 Mar 2000 09:19:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <2D11BCC7FFD8D3118FD70000D1ECDC883A1214@pkcexv018.sprintspectrum.com>
Date:         Thu, 2 Mar 2000 09:19:53 -0600
Reply-To: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Subject:      Re: [MOBILE-IP] Last Call: Mobile IP Challenge/Response Extension
              s to
              Proposed Standard
X-To:         "iesg@ietf.org" <iesg@ietf.org>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I support this I-D and would like to see it move to RFC proposed standard as
quickly as possible.

Thanks

Mark A. Lipford
Manager, Wireless Industry Standards - Data
Sprint PCS
8001 College Blvd.; Suite 210
Overland Park, KS  66210
(913) 664-8335 (office)
(913) 664-8440 (fax)
(913) 226-9060 (PCS)


-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]
Sent: Wednesday, March 01, 2000 10:44 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] Last Call: Mobile IP Challenge/Response Extensions
to Proposed Standard


The IESG has received a request from the IP Routing for Wireless/Mobile
Hosts Working Group to consider Mobile IP Challenge/Response Extensions
<draft-ietf-mobileip-challenge-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by March 15, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-09.txt


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 11:07:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16325
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 11:07:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E35433F0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 11:03:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69579 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 11:01:42 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4B2FA510@standards.nortelnetworks.com>; Thu, 2 Mar 2000
          10:51:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF39@monza.broadswitch.com>
Date:         Thu, 2 Mar 2000 16:55:07 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Charter Update
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I could not resist since I work in a silicon company...


> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@HA1MPK-MAIL.ENG.SUN.COM]
> Sent: Thursday, March 02, 2000 3:20 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Charter Update
>
>
> Not sure this thread really belongs here, but...
>
>
> > Hi, Basavaraj,
> >
> > I agree with your message below - I think we need to be
> very cautious
> > about expanding the charter of the WG to be too cellular-specific.
> > This is the Mobile IP working group, which means that we should be
> > defining IP-layer protocols.
>
> agreed, and specifying a better (or faster) hand-off mechanism isn't
> cellular-specific, but as you and Raj state, it can be used
> by these people.
> What we need to do is make Mobile IP provide the
> functionality that they need,
> not try to design their networks/systems.
>
> >
> > There are some link-layer specific questions that need to be
> > addressed, in terms of how a Mobile IP Foreign Agent should
> be "glued"
> > onto the cellular wireless link layer.
> > draft-ietf-mobileip-3gwireless-ext-02.txt does this pretty well.
> > However, I do not think we should try to start standardizing other
> > aspects of a 3rd generation cellular network.  I think some
> people are
> > trying to plan a BOF in Adelaide called "IP to the Base
> Station" that
> > could address some of these questions, but I am concerned that the
> > IETF has a fairly limited understanding of the cellular link layer,
> > especially as it pertains to CDMA - I've read and heard statements
> > that reveal a certain lack of knowledge of how a CDMA Selection and
> > Distribution Unit really work, when people try to get IP
> packets sent
> > by a MN directly out of a BTS.  Of course, I've also seen
> people here
> > who *do* understand the technology quite well - I don't
> mean to start
> > a flame war, but I think this kind of work logically belongs in the
> > respective 3GPPs for each technology.
>
> Well, I for one will be at this BOF, and I agree that many
> people don't fully
> understand how the macro diversity combiner works. However, I
> think that it is
> a reasonable goal to allow the *control* protocol between the
> BSC and the BTS
> to run over an IP network. Furthermore, once IP is in the BTS, one can
> centrally manage it using off the shelf tools, etc.
>
> As for data, is switching or routing better, I'm not conviced
> the latter is
> the right design choice. A layer 2 approach, such as MPLS,
> may be appropriate.

My opinion is that it is the same thing today - technically ... You do l2
switching or ip switching in integrated L2 switch and L3 router in HW
today... In other words L3 switching :-)

And as a sidenote MPLS is seen from the layer two protocol as a layer three
protocol but I would say that it is a useless L2,5 protocol...

/Thomas


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 11:57:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18185
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 11:57:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2A74DF0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 11:53:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 69636 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 11:51:31 -0500
Received: from nausicaa.coritel.it (193.205.242.5) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.40AAC1E0@standards.nortelnetworks.com>; Thu, 2 Mar 2000
          11:41:30 -0500
Received: from ATHENA (athena.coritel.it [193.205.242.51]) by
          nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id RAA28623 for
          <mobile-ip@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:42:10
          +0100 (MET)
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.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID:  <001001bf8466$e0a53fc0$33f2cdc1@ATHENA>
Date:         Thu, 2 Mar 2000 17:46:37 +0100
Reply-To: Gianluca Mauri <mauri@CORITEL.IT>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gianluca Mauri <mauri@CORITEL.IT>
Subject:      [MOBILE-IP] test
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Gianluca Mauri
CoRiTel - Consorzio di Ricerca sulle Telecomunicazioni

EMAIL : mauri@coritel.it     URL : http://www.coritel.it
TEL : +39-06-20410041     ADDRESS : via di Tor Vergata 135
FAX : +39-06-20410037                         00133 Roma - ITALY


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 17:31:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29999
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 17:31:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E7AB700@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:27:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70067 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 17:27:04 -0500
Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.20D9E060@standards.nortelnetworks.com>;
          Thu, 2 Mar 2000 17:17:03 -0500
Received: from cc.hut.fi (positron.tky.hut.fi [130.233.17.47]) by smtp-2.hut.fi
          (8.9.3/8.9.3) with ESMTP id AAA89584; Fri, 3 Mar 2000 00:20:30 +0200
          (EET)
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686)
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.952006050.27560.pcalhoun@ha1mpk-mail>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38BEE9F8.F5A446F7@cc.hut.fi>
Date:         Fri, 3 Mar 2000 00:23:52 +0200
Reply-To: Tom Weckström <tweckstr@CC.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Tom Weckström <tweckstr@CC.HUT.FI>
Organization: HUT/TKK
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

pcalhoun@eng.sun.com wrote:

> > Does the WG need to develop a terminology document that can be
> > referenced by all WG and Mobile IP related docs? It may be a
> > worthwhile exercise and help us all to be on the same page.
>
> I think that this would be a worthwhile exercise, would I would caution us
> putting our existing milestones in jeopardy by doing so.
>
> PatC
> >
> > -Basavaraj


I would like to have that kind of a terminology document. It would unify
terminology, shorten the drafts and RFCs (since a reference to
terminology would replace lengthy terminology chapters), provide a good
reference point to other WGs when using MIP terms (like the AAA WG is
doing).


        Tom


--
        Tom Weckström           tweckstr@cc.hut.fi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 17:41:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00211
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 17:41:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0711A890@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:37:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70135 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 17:36:47 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E23E7930@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:36:47
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA24333; Fri, 3 Mar
          2000 00:40:21 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          AAA28255; Fri, 3 Mar 2000 00:40:19 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29X0N>;
          Thu, 2 Mar 2000 16:39:27 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929733@daeis07nok>
Date:         Thu, 2 Mar 2000 16:39:22 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         tweckstr@CC.HUT.FI
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00211

Comments below:

>> > Does the WG need to develop a terminology document that can be
>> > referenced by all WG and Mobile IP related docs? It may be a
>> > worthwhile exercise and help us all to be on the same page.
>>
>> I think that this would be a worthwhile exercise, would I would caution
us
>> putting our existing milestones in jeopardy by doing so.
>>
>> PatC
>> >
>> > -Basavaraj
>
>
>I would like to have that kind of a terminology document. It would unify
>terminology, shorten the drafts and RFCs (since a reference to
>terminology would replace lengthy terminology chapters), provide a good
>reference point to other WGs when using MIP terms (like the AAA WG is
>doing).
>
>
>        Tom
>
>
>--
>        Tom Weckström           tweckstr@cc.hut.fi


It seems that this effort would be worthwhile. Any volunteers to work
on a terminology draft?  Tom??? 

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 17:58:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00750
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 17:58:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6953B3C0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:54:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70182 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 17:54:35 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5EAEA290@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:54:34
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA20095; Fri, 3 Mar
          2000 00:58:08 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          AAA21364; Fri, 3 Mar 2000 00:58:07 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWRK5>;
          Thu, 2 Mar 2000 16:58:06 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929734@daeis07nok>
Date:         Thu, 2 Mar 2000 16:57:11 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         fred@CISCO.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>>>that we have: - Link Layer Mobility (Inter-BTS hand-off)
>>>- pick a name Mobility (inter-BSC hand-off)
>>>- Intra-Domain Mobility (Inter-MSC hand-off)
>>>- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>
>Fred Wrote:
>
>another stab:
>
>keying off the issues that "domain" in IETF circles generally refers to an
>administrative domain, often one that is reflected in DNS and/or corporate
>ownership, and that at the BTS/BSC level what we're really talking about is
>wandering around within a particular cellular-etc technology...
>
>        technology-specific mobility
>        inter-technology mobility
>        intra-domain mobility
>        inter-domain mobility
>


Handoffs within the same technology or access types can vary depending
on the granularity of the handoff (Sector/Cell/MSC...) and then there
is the problem of handoffs between different technologies. Somehow the
first two suggestions are not very intuitive for the specific problem
on hand. Granularity of handoffs may be more descriptive (Just
thinking aloud)....
Can't come up with anything better at the moment though..

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 18:01:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00857
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 18:01:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B225AB80@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:56:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70177 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 17:56:49 -0500
Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.48ECAD90@standards.nortelnetworks.com>;
          Thu, 2 Mar 2000 17:46:48 -0500
Received: from cc.hut.fi (positron.tky.hut.fi [130.233.17.47]) by smtp-2.hut.fi
          (8.9.3/8.9.3) with ESMTP id AAA89755; Fri, 3 Mar 2000 00:50:22 +0200
          (EET)
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686)
MIME-Version: 1.0
References: <7B5C0390ACE7D211BC9C0008C7EABA2B929733@daeis07nok>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38BEF0F7.BDA85CD0@cc.hut.fi>
Date:         Fri, 3 Mar 2000 00:53:43 +0200
Reply-To: Tom Weckström <tweckstr@CC.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Tom Weckström <tweckstr@CC.HUT.FI>
Organization: HUT/TKK
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Basavaraj Patil wrote:
>
> Comments below:
>
> >> > Does the WG need to develop a terminology document that can be
> >> > referenced by all WG and Mobile IP related docs? It may be a
> >> > worthwhile exercise and help us all to be on the same page.
> >>
> >> I think that this would be a worthwhile exercise, would I would caution
> us
> >> putting our existing milestones in jeopardy by doing so.
> >>
> >> PatC
> >> >
> >> > -Basavaraj
> >
> >
> >I would like to have that kind of a terminology document. It would unify
> >terminology, shorten the drafts and RFCs (since a reference to
> >terminology would replace lengthy terminology chapters), provide a good
> >reference point to other WGs when using MIP terms (like the AAA WG is
> >doing).
> >
> >
> >        Tom
> >
> >
> >--
> >        Tom Weckström           tweckstr@cc.hut.fi
>
> It seems that this effort would be worthwhile. Any volunteers to work
> on a terminology draft?  Tom???
>
> -Basavaraj


I am volunteered to assist. However, writing the doc all alone would
take too long from me. There is a bunch of RFCs and drafts to be
checked.

        Tom


--
        Tom Weckström           tweckstr@cc.hut.fi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 18:04:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00947
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 18:04:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB5BBC40@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:58:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70236 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 17:58:04 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DB5493E0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 17:58:04
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA23060; Fri, 3 Mar
          2000 01:01:37 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          BAA02047; Fri, 3 Mar 2000 01:01:36 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29YD3>;
          Thu, 2 Mar 2000 17:00:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929735@daeis07nok>
Date:         Thu, 2 Mar 2000 17:00:38 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         tweckstr@cc.hut.fi
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA00947

>> >
>> >I would like to have that kind of a terminology document. It would unify
>> >terminology, shorten the drafts and RFCs (since a reference to
>> >terminology would replace lengthy terminology chapters), provide a good
>> >reference point to other WGs when using MIP terms (like the AAA WG is
>> >doing).
>> >
>> >
>> >        Tom
>> >
>> >
>> >--
>> >        Tom Weckström           tweckstr@cc.hut.fi
>> 
>> It seems that this effort would be worthwhile. Any volunteers to work
>> on a terminology draft?  Tom???
>> 
>> -Basavaraj
>
>
>I am volunteered to assist. However, writing the doc all alone would
>take too long from me. There is a bunch of RFCs and drafts to be
>checked.
>
>       Tom
>
>
>-- 
>       Tom Weckström         tweckstr@cc.hut.fi

Thanks Tom. I hope we will be able to get at least two/three more
volunteers to help out in this effort. Anyone else care to assist???

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 18:32:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01446
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 18:32:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C6D8F50@standards.nortelnetworks.com>; Thu, 2 Mar 2000 18:28:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70326 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 18:26:22 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CF615B00@standards.nortelnetworks.com>; Thu, 2 Mar 2000 18:26:22
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA16467; Fri, 3 Mar
          2000 01:29:55 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          BAA06484; Fri, 3 Mar 2000 01:29:54 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29Y2V>;
          Thu, 2 Mar 2000 17:29:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B929739@daeis07nok>
Date:         Thu, 2 Mar 2000 17:28:51 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         acasati@LUCENT.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>
>Any new rechartering should also consider
>whether the goal is completing the MIP work
>or opening an entire new activity.
>

If the WG feels that there are gaps in the current charter that need
to be closed then we should enhance the scope. Of course completing
the work items that are on our plate at the present time is of utmost
importance and not to be discounted at all.

>If the goal is to solve "mobility in the small", or in access
>nets, as I understand some folks are aiming at when they talk
>about Fast Handovers, then probably an entire new WG is likely
>to be needed.
>
>A spinoff of the MIP WG, say  MIPSAT WG
>(IP mobility support over Specific Access Technologies)
>would probably be a good thing, accommodating
>any need to address specific problems that
>MIP is considered not sufficient to address over
>specific access Technologies. Also this would
>come with the benefit of providing a well defined
>scope for each new proposal coming in.
>

Mobile IP's access independence characteristic makes it so viable.
So there's not much to be said for IP mobility support over specific
access technologies as you propose.

>There may be another approach (AKA "the tail that
>wags the dog") that is defining a new access network
>based on newly IETF specified access protocols, but this
>probably would not be useful for some technologies
>currently (or about to be) on the
>marketplace (cellular and non cellular). It looks
>like a long term work.
>

Seriously???

>Which of the two? Both? or none?
>

None, in my opinion.

>alessio

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 19:12:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02037
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 19:12:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5CEE720@standards.nortelnetworks.com>; Thu, 2 Mar 2000 19:08:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70391 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 19:07:59 -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A01BB470@standards.nortelnetworks.com>; Thu, 2 Mar 2000
          19:07:59 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA18945
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 2 Mar 2000
          19:11:34 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id TAA18928 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 2 Mar 2000 19:11:33 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <1P8214BH>; Fri, 3 Mar 2000 00:11:32 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876A00@en0060exch001u.uk.lucent.com>
Date:         Fri, 3 Mar 2000 00:11:31 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

BP,

> Mobile IP's access independence characteristic makes it so viable.
> So there's not much to be said for IP mobility support over specific
> access technologies as you propose.
>
I'm not so sure about this as you are. I just say
IP itself is technology indep., but if you
want to support intserv there is for instance an ISSLOW spec,
an ISATM spec, and a spec on how to support
Qos on 802.x stuff. Just imagine if we want to solve
the problem of supporting IP QoS in mobile environment over
a certain access technology: it is at least as specific to the
technology as it may be for a fixed technology I guess.

I'm not advocating we set up any WG, I'm only examining
the situation and possible scenarios (which may include setting
up a WG)


> >There may be another approach (AKA "the tail that
> >wags the dog") that is defining a new access network
> >based on newly IETF specified access protocols, but this
> >probably would not be useful for some technologies
> >currently (or about to be) on the
> >marketplace (cellular and non cellular). It looks
> >like a long term work.
> >
>
> Seriously???
>
I can answer "YES!" since I'm sure I'm serious ;)
But I'm also interested in knowing what this question is about
(what in the quoted text looks likely not to be serious?)


alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  2 22:03:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04550
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 2 Mar 2000 22:03:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.90823FD0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 21:59:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70534 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 21:57:41 -0500
Received: from taurus.cs.albany.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EEDB74E0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 21:47:40
          -0500
Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by
          taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id VAA26700; Thu, 2
          Mar 2000 21:50:33 -0500 (EST)
Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id
          VAA01454; Thu, 2 Mar 2000 21:49:15 -0500
Message-ID:  <200003030249.VAA01454@euler.cs.albany.edu>
Date:         Thu, 2 Mar 2000 21:49:15 -0500
Reply-To: "S.S.Ravi" <ravi@CS.ALBANY.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "S.S.Ravi" <ravi@CS.ALBANY.EDU>
Subject:      [MOBILE-IP] DIAL M for Mobility (Second Call for Papers)
X-To:         dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de,
              itc@ieee.org, manet@itd.nrl.navy.mil, mobility@media.mit.edu,
              opt-net@zib.de, orcs-l@listserv.okstate.edu,
              podc-post@research.telcordia.com, tccc@ieee.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

       (Please accept our apologies if you receive multiple copies.)

                       SECOND CALL FOR PAPERS

           4th International Workshop on  Discrete Algorithms and
               Methods for Mobile Computing & Communications
                         (DIALM for Mobility)

              August 11, 2000  Boston, Massachusetts, USA
                  In conjunction with ACM MobiCom 2000
                      Sponsored by ACM SIGMOBILE

                   Submission Deadline:  April  25, 2000

       Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html

SCOPE:

  Mobile computing and communications devices such as portable phones,
laptops and palmtops will have an enormous impact on our lifestyle over
the next several decades. The introduction of mobility raises a number
of new research issues. This workshop is devoted to discrete algorithms
and methods in the context of mobile and wireless computing and
communications. The workshop is intended to serve as a forum for open
discussions and lively debate, and to foster cooperation among
practitioners and theoreticians. The workshop encourages submission of
papers based on work-in-progress. Proposals for panels designed to
generate lively discussions are also invited.

  Contributions are solicited in all areas related to mobile computing and
communications where discrete algorithms and methods are utilized,
including, but not limited to:

    distributed algorithms     frequency allocation
    scheduling                 location tracking
    site allocation            multihop packet radio networks
    wireless networks          synchronization
    cryptography and security  error correcting codes
    handover (handoff)         telecommunications
    modeling                   optimization
    routing                    satellite communication



PROGRAM CHAIR:   Errol L. Lloyd
                 Department of Computer and Information Sciences
                 University of Delaware
                 Newark, DE, USA
                 Email: elloyd@udel.edu

PROGRAM COMMITTEE

       Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel
       Anthony Ephremides, University of Maryland, USA
       Aura Ganz, University of Massachusetts, USA
       Juraj Hromkovic, RWTH Aachen, Germany
       Bo Li, Hong Kong University of Science and Technology, Hong Kong
       Jason Yi-Bing Lin, National Chiao-Tung University, ROC
       Errol Lloyd, University of Delaware,USA -- Program Chair
       Madhav Marathe, Los Alamos National Lab
       Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden
       Stephane Perennes, INRIA, France
       Cynthia Phillips, Sandia National Laboratories, USA
       Balaji Raghavachari, University of Texas at Dallas, USA
       S.S. Ravi, SUNY Albany, USA -- Publicity Chair
       Andrea Richa, Arizona State University, USA
       Aravind Srinivasan, Bell Labs, USA
       Martha Steenstrup, BBN, USA
       Subhash Suri, Washington University, USA
       Eli Upfal, Brown University, USA
       Peter Widmayer, ETH Zurich, Switzerland

STEERING COMMITTEE

       Ian Akyildiz, Georgia Tech, USA
       Maurizio Bonuccelli, University of Pisa, Italy (Chair)
       Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France
       Arunabha Sen, Arizona State University, USA.


SUBMISSION GUIDELINES:

   All paper submissions and panel proposals will be handled
electronically. Authors should e-mail a PostScript version of their full
paper to elloyd@udel.edu. The font size should be at least 10 pt. The
paper should not be longer than 10 single spaced pages using a standard
10point font. Panel proposals may be submitted in ASCII or PostScript
format. A panel proposal should include panel topic, sample questions
the panel would address, and proposed panel members and moderator.

   Since deadlines overlap, dual submission of papers to MobiCom and DIALM
is encouraged.  Any paper accepted for MobiCom will automatically be
removed from consideration for DIALM.

   To ensure that the PostScript versions of the papers can be
printed, use PostScript version 2 or later. Also ensure that the paper
fits on "US Letter" size paper (8.5X11 inches). Reference only standard
Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica); other
fonts may be used but must be included in the PostScript file.

   Authors will receive a short email ack of their submission within two
days of submission.  If this is not received, the authors should contact
the Program Chair immediately. Authors should separately email the
title, authors, mailing address, and abstract to elloyd@udel.edu.

IMPORTANT DATES:

    Submissions due        :  April 25, 2000
    Acceptance notification:  May 15, 2000
    Final paper due        :  June 1, 2000
    Workshop               :  August 11, 2000


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 02:51:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20862
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 02:51:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B39D30B0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 2:46:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70774 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 02:46:16 -0500
Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A55640A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 2:46:16
          -0500
Received: from darmstadt.gmd.de (rho [141.12.34.56]) by sonne.darmstadt.gmd.de
          (8.8.8/8.8.5) with ESMTP id IAA14805; Fri, 3 Mar 2000 08:49:41 +0100
          (MET)
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: de,en,it
MIME-Version: 1.0
References: <7B5C0390ACE7D211BC9C0008C7EABA2B929735@daeis07nok>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38BF6E5D.69C7AD5B@darmstadt.gmd.de>
Date:         Fri, 3 Mar 2000 08:48:45 +0100
Reply-To: Wolfgang Schoenfeld <schfeld@DARMSTADT.GMD.DE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Wolfgang Schoenfeld <schfeld@DARMSTADT.GMD.DE>
Organization: GMD IPSI Darmstadt Deutschland
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Basavaraj.Patil@NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Basavaraj,

Terminology document -
I would like to contribute to such an effort.
But I'm not sure whether it can succeed
under the current state of the art.
Quite a lot of abstract modeling might be required
in order to arrive at a common understanding of structural principles
which can then be assigned to some wording.
(See e.g. the micro/macro mobility discussion.)

What about another volunteer with English as native language?

Regards
Wolfgang

Basavaraj Patil wrote:
>
> >> >
> >> >I would like to have that kind of a terminology document. It would unify
> >> >terminology, shorten the drafts and RFCs (since a reference to
> >> >terminology would replace lengthy terminology chapters), provide a good
> >> >reference point to other WGs when using MIP terms (like the AAA WG is
> >> >doing).
> >> >
> >> >
> >> >        Tom
> >> >
> >> >
> >> >--
> >> >        Tom Weckström           tweckstr@cc.hut.fi
> >>
> >> It seems that this effort would be worthwhile. Any volunteers to work
> >> on a terminology draft?  Tom???
> >>
> >> -Basavaraj
> >
> >
> >I am volunteered to assist. However, writing the doc all alone would
> >take too long from me. There is a bunch of RFCs and drafts to be
> >checked.
> >
> >       Tom
> >
> >
> >--
> >       Tom Weckström         tweckstr@cc.hut.fi
>
> Thanks Tom. I hope we will be able to get at least two/three more
> volunteers to help out in this effort. Anyone else care to assist???
>
> -Basavaraj


--
Wolfgang Schoenfeld
GMD-IPSI, Dolivostr. 15, Room 128, D-64293 Darmstadt
+49-6151-869-865 (Phone), -818 (FAX)
+49-170-2285450 (Mobile Phone)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 05:19:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21987
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 05:19:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64D8A6C0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:14:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70849 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 05:13:05 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C23EA230@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:03:05
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF42@monza.broadswitch.com>
Date:         Fri, 3 Mar 2000 11:06:31 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Basavaraj.Patil@NOKIA.COM" <Basavaraj.Patil@NOKIA.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> >A spinoff of the MIP WG, say  MIPSAT WG
> >(IP mobility support over Specific Access Technologies)
> >would probably be a good thing, accommodating
> >any need to address specific problems that
> >MIP is considered not sufficient to address over
> >specific access Technologies. Also this would
> >come with the benefit of providing a well defined
> >scope for each new proposal coming in.
> >
>
> Mobile IP's access independence characteristic makes it so viable.
> So there's not much to be said for IP mobility support over specific
> access technologies as you propose.

I definitatly not agree here.. It is very important to optimize the IP
transport (doen in Robust Header Compression WG), mobility management over
specific link layers, especially over different radio link layers because
they have very special charateristics that needs to be adapted to in order
to make it efficient...

I would say that this is very important and judging from the interest of
trying to solve the micro mobility shows that people are not satisfied with
just running mobile ip over radio....

Important thing to include for instance is more states in the radio like
idle, active mode in order to define location managemnt protocols...

We are speaking about IP based mobility here not mobile IP... But mobile IP
will be the base for all work of course...



>
> >There may be another approach (AKA "the tail that
> >wags the dog") that is defining a new access network
> >based on newly IETF specified access protocols, but this
IETF dont specify access technologies, this is layer 1 and 2 stuff... When
we want to run IP over them, then of course it should be as smooth as
possible this is why we need  clear interfaces that people have been
discussing so when a new acces technology comes you can very easy integrate
it with your ISP backbone...

/Thomas


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 05:23:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22012
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 05:23:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1882340@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:17:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 70862 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 05:17:06 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5146FF40@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:07:05
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF43@monza.broadswitch.com>
Date:         Fri, 3 Mar 2000 11:10:34 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM]
> Sent: Friday, March 03, 2000 1:12 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP]
> charter update?)
>
>
> BP,
>
> > Mobile IP's access independence characteristic makes it so viable.
> > So there's not much to be said for IP mobility support over specific
> > access technologies as you propose.
> >
> I'm not so sure about this as you are. I just say
> IP itself is technology indep., but if you
> want to support intserv there is for instance an ISSLOW spec,
> an ISATM spec, and a spec on how to support
> Qos on 802.x stuff. Just imagine if we want to solve
Since I work with this as well I could not agree more...
It is very important to map the link characteristics to the mobility
management (which in our case is IP based) in order to make it efficient...


> the problem of supporting IP QoS in mobile environment over
> a certain access technology: it is at least as specific to the
> technology as it may be for a fixed technology I guess.

People that dont agree with you here have not worked with layer 2 stuff..:-)



> > >There may be another approach (AKA "the tail that
> > >wags the dog") that is defining a new access network
> > >based on newly IETF specified access protocols, but this
> > >probably would not be useful for some technologies
> > >currently (or about to be) on the
> > >marketplace (cellular and non cellular). It looks
> > >like a long term work.
> > >
> >
> > Seriously???
> >
> I can answer "YES!" since I'm sure I'm serious ;)
> But I'm also interested in knowing what this question is about
> (what in the quoted text looks likely not to be serious?)
>
>
> alessio

At least I agree with you...

/Thomas

>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 08:52:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26805
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 08:52:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39293260@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:48:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71199 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 08:46:35 -0500
Received: from david.siemens.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.95C219D0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:36:35
          -0500
X-Envelope-Sender-Is: Hans-Peter.Huth@mchp.siemens.de (at relayer
                      david.siemens.de)
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by
          david.siemens.de (8.9.3/8.9.3) with ESMTP id OAA28880 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 14:40:11
          +0100 (MET)
Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.202.157])
          by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id OAA24819 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 14:40:10
          +0100 (MET)
Received: from alpha.mchp.siemens.de (alpha [139.23.202.151]) by
          mail-y.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id OAA18389 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 14:40:09
          +0100 (MET)
Received: from mchp.siemens.de (localhost [127.0.0.1]) by alpha.mchp.siemens.de
          (8.9.3/8.9.3) with ESMTP id OAA13582 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 14:40:08
          +0100 (MET)
X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: German/Germany, de-DE, en
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.951919643.19090.pcalhoun@ha1mpk-mail>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Message-ID:  <38BFC0B8.7DBD06ED@mchp.siemens.de>
Date:         Fri, 3 Mar 2000 14:40:08 +0100
Reply-To: hans-peter.huth@MCHP.SIEMENS.DE
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Hans-Peter Huth <Hans-Peter.Huth@MCHP.SIEMENS.DE>
Organization: Siemens AG
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"pcalhoun@eng.sun.com" wrote:
>
> All,
>
> I had a conversation yesterday with Charlie and we both agreed that we need to
> define the different layers of mobility. Today we use micro and macro
> mobility, and these terms mean completely different things, depending upon the
> proposal that you happen to be backing. Therefore, having agreement on the
> list as to what micro vs. macro means will be a long, drawn out battle, and I
> think that we have better things to do with out time (well, at least I do).
>

Maybe we see it this way: different scenarios may need different mechanisms. One
size fits all is not the approach we want.

> btw, in case you still aren't convinced, it isn't clear to me that what we
> today call micro-mobility cannot be achieved via hierarchical Mobile IP, while
> others believe that Hawaii or Cellular IP provides micro-mobility.
>
> So, I would like to propose that we agree on some new terminology. I believe
> that we have: - Link Layer Mobility (Inter-BTS hand-off)

agreed here. LL-Mobility is Mobility on lower layers without involving IP.

> - pick a name Mobility (inter-BSC hand-off)

I'm not sure what You mean here.

> - Intra-Domain Mobility (Inter-MSC hand-off)
> - Inter-Domain Mobility (when the hand-off crosses a domain boundary)

Why not referring to both with "Micro Mobility"? The definition might be, this
is IP-layer mobility with specialized means others than Mobile IP (e.g. Cellular IP
HAWAII).

>
> I still don't have a preference for the second name, and I am not married to
> ANY of the names above. These are merely suggestions. The goal here is to ALL
> agree on basic terminology so that when we compare protocols, we can match the
> protocol against a set of common terminology.
>

I think, the challenge is to allow for very different Mobility algorithms
suitable for very different areas. The crucial point for me is the
interface to the terminals and the access routers of the next Mobility
stage (e.g. a FA). We need standardized interfaces here. I definitely
do not want multiple Mobility driver software in an terminal. For
example binding updates, paging and AAA should use the same interface
no matter what technology actually is used to provide Mobility.

I personally don't think we should adopt the cellular terminology. In
the names You propose are some assumptions on the functionality of
BTS and BSC which may not be valid for all wireless networks although
the mechanisms of the Mobile IP WG should be applicable.

However it perfectly does make sense to me to construct a flexible
Mobility framework which can handle the needs of a cellular network.

Regards,
        Hans-Peter Huth

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  Hans-Peter Huth                         Phone: +49 89 636 430 71 |
|  Siemens AG, Dept. ZT IK 2               FAX:   +49 89 636 51115  |
|  Otto-Hahn-Ring 6          E-mail: Hans-Peter.Huth@mchp.siemens.de|
|D-81730  Munich                                                    |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 10:27:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00371
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 10:27:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.893BC7B0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 10:23:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71426 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 10:21:47 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E2222E70@standards.nortelnetworks.com>; Fri, 3 Mar 2000 10:11:47
          -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id HAA00964; Fri, 3 Mar 2000 07:15:22
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.101.34]) by engmail3.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA04193; Fri, 3 Mar
          2000 07:15:21 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          HAA19212; Fri, 3 Mar 2000 07:15:09 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952096509.12704.pcalhoun@ha1mpk-mail>
Date:         Fri, 3 Mar 2000 07:15:09 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         hans-peter.huth@MCHP.SIEMENS.DE
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <38BFC0B8.7DBD06ED@mchp.siemens.de>

Hans,

I *was* pretty sure that I made myself clear, and based on your response I
apparently didn't.

I don't care much for cellular terminology, but I used it because it was
convenient. Someone else sent an e-mail to this thread with the equivalent in
the 802.11 world. From your e-mail below, you are *already* associating
certain mobility levels to specific techonologies, when you state:

> Why not referring to both with "Micro Mobility"? The definition might be,
> this is IP-layer mobility with specialized means others than Mobile IP (e.g.
> Cellular IP HAWAII).

Why is Hierarchical Mobile IP not included here? Mobile IP can be used to
provide micro mobility. The reason is because some people's definition of
micro mobility is vastly different from others. Hence the reason why I want to
move *away* from these terms, and create something new that is very well
defined.

PatC

> "pcalhoun@eng.sun.com" wrote:
> >
> > All,
> >
> > I had a conversation yesterday with Charlie and we both agreed that we need to
> > define the different layers of mobility. Today we use micro and macro
> > mobility, and these terms mean completely different things, depending upon the
> > proposal that you happen to be backing. Therefore, having agreement on the
> > list as to what micro vs. macro means will be a long, drawn out battle, and I
> > think that we have better things to do with out time (well, at least I do).
> >
>
> Maybe we see it this way: different scenarios may need different mechanisms.
> One size fits all is not the approach we want.
>
> > btw, in case you still aren't convinced, it isn't clear to me that what we
> > today call micro-mobility cannot be achieved via hierarchical Mobile IP, while
> > others believe that Hawaii or Cellular IP provides micro-mobility.
> >
> > So, I would like to propose that we agree on some new terminology. I believe
> > that we have: - Link Layer Mobility (Inter-BTS hand-off)
>
> agreed here. LL-Mobility is Mobility on lower layers without involving IP.
>
> > - pick a name Mobility (inter-BSC hand-off)
>
> I'm not sure what You mean here.
>
> > - Intra-Domain Mobility (Inter-MSC hand-off)
> > - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>
> Why not referring to both with "Micro Mobility"? The definition might be,
> this is IP-layer mobility with specialized means others than Mobile IP (e.g.
> Cellular IP HAWAII).
>
> >
> > I still don't have a preference for the second name, and I am not married to
> > ANY of the names above. These are merely suggestions. The goal here is to ALL
> > agree on basic terminology so that when we compare protocols, we can match the
> > protocol against a set of common terminology.
> >
>
> I think, the challenge is to allow for very different Mobility algorithms
> suitable for very different areas. The crucial point for me is the
> interface to the terminals and the access routers of the next Mobility
> stage (e.g. a FA). We need standardized interfaces here. I definitely
> do not want multiple Mobility driver software in an terminal. For
> example binding updates, paging and AAA should use the same interface
> no matter what technology actually is used to provide Mobility.
>
> I personally don't think we should adopt the cellular terminology. In
> the names You propose are some assumptions on the functionality of
> BTS and BSC which may not be valid for all wireless networks although
> the mechanisms of the Mobile IP WG should be applicable.
>
> However it perfectly does make sense to me to construct a flexible
> Mobility framework which can handle the needs of a cellular network.
>
> Regards,
>         Hans-Peter Huth
>
> --
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> |  Hans-Peter Huth                         Phone: +49 89 636 430 71 |
> |  Siemens AG, Dept. ZT IK 2               FAX:   +49 89 636 51115  |
> |  Otto-Hahn-Ring 6          E-mail: Hans-Peter.Huth@mchp.siemens.de|
> |D-81730  Munich                                                    |
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 11:05:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01742
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 11:05:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB00E8A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 11:01:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71478 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 11:00:24 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AC989170@standards.nortelnetworks.com>; Fri, 3 Mar 2000 11:00:23
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA29286; Fri, 3 Mar
          2000 18:03:51 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          SAA13650; Fri, 3 Mar 2000 18:03:49 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <F5PHWTWS>;
          Fri, 3 Mar 2000 10:03:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B92973F@daeis07nok>
Date:         Fri, 3 Mar 2000 10:02:50 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         thomas.eklund@SWITCHCORE.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>> >A spinoff of the MIP WG, say  MIPSAT WG
>> >(IP mobility support over Specific Access Technologies)
>> >would probably be a good thing, accommodating
>> >any need to address specific problems that
>> >MIP is considered not sufficient to address over
>> >specific access Technologies. Also this would
>> >come with the benefit of providing a well defined
>> >scope for each new proposal coming in.
>> >
>>
>> Mobile IP's access independence characteristic makes it so viable.
>> So there's not much to be said for IP mobility support over specific
>> access technologies as you propose.
>
>I definitatly not agree here.. It is very important to optimize the IP
>transport (doen in Robust Header Compression WG), mobility management over
>specific link layers, especially over different radio link layers because
>they have very special charateristics that needs to be adapted to in order
>to make it efficient...
>

The ROHC BOF/WG aims to optimize IP transport via compression or
stripping of headers over the air interface. And because of the
limited spectrum it needs to be efficient. But what does mobility and
handoffs have to do with that? How you handle IP transport over
specific access types and link layers is independent of mobility
management (well at least to some extent).

-Basavaraj

>
>/Thomas


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 11:44:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02873
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 11:44:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BDC93F0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 11:39:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71517 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 11:38:43 -0500
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.07450E00@standards.nortelnetworks.com>; Fri, 3 Mar 2000 11:38:43
          -0500
Received: from zrchh190 by smtprich.nortel.com; Fri, 3 Mar 2000 10:41:54 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchh190; Fri, 3
          Mar 2000 10:41:03 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GB5X49S2>; Fri, 3 Mar 2000 10:38:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF852E.E96BE398"
X-Orig: <emadq@americasm01.nt.com>
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD93FA@crchy271.us.nortel.com>
Date:         Fri, 3 Mar 2000 10:38:31 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

------_=_NextPart_001_01BF852E.E96BE398
Content-type: text/plain; charset="iso-8859-1"

Hi,

        Has anyone done some analysis on the different mirco mobility
solutions presented in the MIP WG?
        This would be a good mechanism to understand how well Hierarchical
MIP, cellular IP, HAWAII or others would fit the real time need of
technologies like cellular.

thx.

> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@HA1MPK-MAIL.ENG.SUN.COM]
> Sent: Friday, March 03, 2000 9:15 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP]
> charter update?)
>
>
> Hans,
>
> I *was* pretty sure that I made myself clear, and based on
> your response I
> apparently didn't.
>
> I don't care much for cellular terminology, but I used it
> because it was
> convenient. Someone else sent an e-mail to this thread with
> the equivalent in
> the 802.11 world. From your e-mail below, you are *already*
> associating
> certain mobility levels to specific techonologies, when you state:
>
> > Why not referring to both with "Micro Mobility"? The
> definition might be,
> > this is IP-layer mobility with specialized means others
> than Mobile IP (e.g.
> > Cellular IP HAWAII).
>
> Why is Hierarchical Mobile IP not included here? Mobile IP
> can be used to
> provide micro mobility. The reason is because some people's
> definition of
> micro mobility is vastly different from others. Hence the
> reason why I want to
> move *away* from these terms, and create something new that
> is very well
> defined.
>
> PatC
>
> > "pcalhoun@eng.sun.com" wrote:
> > >
> > > All,
> > >
> > > I had a conversation yesterday with Charlie and we both
> agreed that we need to
> > > define the different layers of mobility. Today we use
> micro and macro
> > > mobility, and these terms mean completely different
> things, depending upon the
> > > proposal that you happen to be backing. Therefore, having
> agreement on the
> > > list as to what micro vs. macro means will be a long,
> drawn out battle, and I
> > > think that we have better things to do with out time
> (well, at least I do).
> > >
> >
> > Maybe we see it this way: different scenarios may need
> different mechanisms.
> > One size fits all is not the approach we want.
> >
> > > btw, in case you still aren't convinced, it isn't clear
> to me that what we
> > > today call micro-mobility cannot be achieved via
> hierarchical Mobile IP, while
> > > others believe that Hawaii or Cellular IP provides micro-mobility.
> > >
> > > So, I would like to propose that we agree on some new
> terminology. I believe
> > > that we have: - Link Layer Mobility (Inter-BTS hand-off)
> >
> > agreed here. LL-Mobility is Mobility on lower layers
> without involving IP.
> >
> > > - pick a name Mobility (inter-BSC hand-off)
> >
> > I'm not sure what You mean here.
> >
> > > - Intra-Domain Mobility (Inter-MSC hand-off)
> > > - Inter-Domain Mobility (when the hand-off crosses a
> domain boundary)
> >
> > Why not referring to both with "Micro Mobility"? The
> definition might be,
> > this is IP-layer mobility with specialized means others
> than Mobile IP (e.g.
> > Cellular IP HAWAII).
> >
> > >
> > > I still don't have a preference for the second name, and
> I am not married to
> > > ANY of the names above. These are merely suggestions. The
> goal here is to ALL
> > > agree on basic terminology so that when we compare
> protocols, we can match the
> > > protocol against a set of common terminology.
> > >
> >
> > I think, the challenge is to allow for very different
> Mobility algorithms
> > suitable for very different areas. The crucial point for me is the
> > interface to the terminals and the access routers of the
> next Mobility
> > stage (e.g. a FA). We need standardized interfaces here. I
> definitely
> > do not want multiple Mobility driver software in an terminal. For
> > example binding updates, paging and AAA should use the same
> interface
> > no matter what technology actually is used to provide Mobility.
> >
> > I personally don't think we should adopt the cellular
> terminology. In
> > the names You propose are some assumptions on the functionality of
> > BTS and BSC which may not be valid for all wireless
> networks although
> > the mechanisms of the Mobile IP WG should be applicable.
> >
> > However it perfectly does make sense to me to construct a flexible
> > Mobility framework which can handle the needs of a cellular network.
> >
> > Regards,
> >         Hans-Peter Huth
> >
> > --
> >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > |  Hans-Peter Huth                         Phone: +49 89
> 636 430 71 |
> > |  Siemens AG, Dept. ZT IK 2               FAX:   +49 89
> 636 51115  |
> > |  Otto-Hahn-Ring 6          E-mail:
> Hans-Peter.Huth@mchp.siemens.de|
> > |D-81730  Munich
>         |
> >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

------_=_NextPart_001_01BF852E.E96BE398
Content-type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!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.2651.65">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter =
update?)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Has anyone =
done some analysis on the different mirco mobility solutions presented =
in the MIP WG?</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>This =
would be a good mechanism to understand how well Hierarchical MIP, =
cellular IP, HAWAII or others would fit the real time need of =
technologies like cellular.</FONT></P>

<P><FONT SIZE=3D2>thx.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: pcalhoun@eng.sun.com [<A =
HREF=3D"mailto:pcalhoun@HA1MPK-MAIL.ENG.SUN.COM">mailto:pcalhoun@HA1MPK-=
MAIL.ENG.SUN.COM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, March 03, 2000 9:15 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [MOBILE-IP] Terminology (was: =
[MOBILE-IP] </FONT>
<BR><FONT SIZE=3D2>&gt; charter update?)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hans,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I *was* pretty sure that I made myself clear, =
and based on </FONT>
<BR><FONT SIZE=3D2>&gt; your response I</FONT>
<BR><FONT SIZE=3D2>&gt; apparently didn't.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't care much for cellular terminology, but =
I used it </FONT>
<BR><FONT SIZE=3D2>&gt; because it was</FONT>
<BR><FONT SIZE=3D2>&gt; convenient. Someone else sent an e-mail to this =
thread with </FONT>
<BR><FONT SIZE=3D2>&gt; the equivalent in</FONT>
<BR><FONT SIZE=3D2>&gt; the 802.11 world. From your e-mail below, you =
are *already* </FONT>
<BR><FONT SIZE=3D2>&gt; associating</FONT>
<BR><FONT SIZE=3D2>&gt; certain mobility levels to specific =
techonologies, when you state:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why not referring to both with &quot;Micro =
Mobility&quot;? The </FONT>
<BR><FONT SIZE=3D2>&gt; definition might be,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this is IP-layer mobility with specialized =
means others </FONT>
<BR><FONT SIZE=3D2>&gt; than Mobile IP (e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cellular IP HAWAII).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why is Hierarchical Mobile IP not included =
here? Mobile IP </FONT>
<BR><FONT SIZE=3D2>&gt; can be used to</FONT>
<BR><FONT SIZE=3D2>&gt; provide micro mobility. The reason is because =
some people's </FONT>
<BR><FONT SIZE=3D2>&gt; definition of</FONT>
<BR><FONT SIZE=3D2>&gt; micro mobility is vastly different from others. =
Hence the </FONT>
<BR><FONT SIZE=3D2>&gt; reason why I want to</FONT>
<BR><FONT SIZE=3D2>&gt; move *away* from these terms, and create =
something new that </FONT>
<BR><FONT SIZE=3D2>&gt; is very well</FONT>
<BR><FONT SIZE=3D2>&gt; defined.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;pcalhoun@eng.sun.com&quot; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I had a conversation yesterday with =
Charlie and we both </FONT>
<BR><FONT SIZE=3D2>&gt; agreed that we need to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; define the different layers of =
mobility. Today we use </FONT>
<BR><FONT SIZE=3D2>&gt; micro and macro</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; mobility, and these terms mean =
completely different </FONT>
<BR><FONT SIZE=3D2>&gt; things, depending upon the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; proposal that you happen to be =
backing. Therefore, having </FONT>
<BR><FONT SIZE=3D2>&gt; agreement on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; list as to what micro vs. macro means =
will be a long, </FONT>
<BR><FONT SIZE=3D2>&gt; drawn out battle, and I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think that we have better things to =
do with out time </FONT>
<BR><FONT SIZE=3D2>&gt; (well, at least I do).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Maybe we see it this way: different =
scenarios may need </FONT>
<BR><FONT SIZE=3D2>&gt; different mechanisms.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; One size fits all is not the approach we =
want.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; btw, in case you still aren't =
convinced, it isn't clear </FONT>
<BR><FONT SIZE=3D2>&gt; to me that what we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; today call micro-mobility cannot be =
achieved via </FONT>
<BR><FONT SIZE=3D2>&gt; hierarchical Mobile IP, while</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; others believe that Hawaii or =
Cellular IP provides micro-mobility.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So, I would like to propose that we =
agree on some new </FONT>
<BR><FONT SIZE=3D2>&gt; terminology. I believe</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that we have: - Link Layer Mobility =
(Inter-BTS hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; agreed here. LL-Mobility is Mobility on =
lower layers </FONT>
<BR><FONT SIZE=3D2>&gt; without involving IP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - pick a name Mobility (inter-BSC =
hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I'm not sure what You mean here.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - Intra-Domain Mobility (Inter-MSC =
hand-off)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - Inter-Domain Mobility (when the =
hand-off crosses a </FONT>
<BR><FONT SIZE=3D2>&gt; domain boundary)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why not referring to both with &quot;Micro =
Mobility&quot;? The </FONT>
<BR><FONT SIZE=3D2>&gt; definition might be,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this is IP-layer mobility with specialized =
means others </FONT>
<BR><FONT SIZE=3D2>&gt; than Mobile IP (e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cellular IP HAWAII).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I still don't have a preference for =
the second name, and </FONT>
<BR><FONT SIZE=3D2>&gt; I am not married to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ANY of the names above. These are =
merely suggestions. The </FONT>
<BR><FONT SIZE=3D2>&gt; goal here is to ALL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; agree on basic terminology so that =
when we compare </FONT>
<BR><FONT SIZE=3D2>&gt; protocols, we can match the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol against a set of common =
terminology.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think, the challenge is to allow for =
very different </FONT>
<BR><FONT SIZE=3D2>&gt; Mobility algorithms</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; suitable for very different areas. The =
crucial point for me is the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; interface to the terminals and the access =
routers of the </FONT>
<BR><FONT SIZE=3D2>&gt; next Mobility</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; stage (e.g. a FA). We need standardized =
interfaces here. I </FONT>
<BR><FONT SIZE=3D2>&gt; definitely</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; do not want multiple Mobility driver =
software in an terminal. For</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; example binding updates, paging and AAA =
should use the same </FONT>
<BR><FONT SIZE=3D2>&gt; interface</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; no matter what technology actually is used =
to provide Mobility.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I personally don't think we should adopt =
the cellular </FONT>
<BR><FONT SIZE=3D2>&gt; terminology. In</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the names You propose are some assumptions =
on the functionality of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; BTS and BSC which may not be valid for all =
wireless </FONT>
<BR><FONT SIZE=3D2>&gt; networks although</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the mechanisms of the Mobile IP WG should =
be applicable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; However it perfectly does make sense to me =
to construct a flexible</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mobility framework which can handle the =
needs of a cellular network.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hans-Peter =
Huth</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FON=
T>
<BR><FONT SIZE=3D2>&gt; &gt; |&nbsp; Hans-Peter =
Huth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Phone: +49 89 </FONT>
<BR><FONT SIZE=3D2>&gt; 636 430 71 |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; |&nbsp; Siemens AG, Dept. ZT IK =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; FAX:&nbsp;&nbsp; +49 89 </FONT>
<BR><FONT SIZE=3D2>&gt; 636 51115&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; |&nbsp; Otto-Hahn-Ring =
6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E-mail: </FONT>
<BR><FONT SIZE=3D2>&gt; Hans-Peter.Huth@mchp.siemens.de|</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; |D-81730&nbsp; =
Munich&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FON=
T>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF852E.E96BE398--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 14:43:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07449
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 14:43:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37625ED0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 14:39:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71700 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 14:37:03 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8AE6C020@standards.nortelnetworks.com>; Fri, 3 Mar 2000 14:27:02
          -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id LAA21110; Fri, 3 Mar 2000 11:30:38
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          LAA26085; Fri, 3 Mar 2000 11:30:37 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id LAA27258; Fri, 3 Mar 2000 11:30:37
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vTI3V7l90aMv0qRIrtIeAw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003031930.LAA27258@nasnfs.eng.sun.com>
Date:         Fri, 3 Mar 2000 11:32:06 -0800
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         qa3445@EMAIL1.WES.MOT.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I just joined the mail alias.

>So I'd like to find out whether there is interest in the group to extending
>the charter for specific support of cellular systems.  If there is general

I think this is an excellent idea. I've been working with the
Mobile Wireless Internet Forum on defining an open radio access network
based on IP. One of the chief concerns is how to support micromobility
given the need for extremely low latency handoff.

>support I'll propose some wording.  One obvious work item would be to submit
>a draft to the IESG for support of fast handover.
>

Any proposal needs to account for the reality of how CDMA does macrodiversity
combining (SDU function). There are potentially competing ways that this
could be done, some based more or less on the current mobile IP framework,
some involving quite different approaches. I think it would be valuable
to examine these approaches, and, indeed, what would be most valuable
is having some simulation or implementation results whereby the approaches
can be compared. Before this is done, I think it would be premature
to submit a draft to IESG.

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 15:31:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08500
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 15:31:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F0567CE0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 15:27:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71785 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 15:25:46 -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.596A46F0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 15:15:46
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA10905 for
          <mobile-ip@standards.nortelnetworks.com>; Fri, 3 Mar 2000 13:19:22
          -0700 (MST)]
Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA07915 for
          <mobile-ip@standards.nortelnetworks.com>; Fri, 3 Mar 2000 13:19:22
          -0700 (MST)]
Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id
          <GFB4RKCZ>; Fri, 3 Mar 2000 14:19:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <51F347B016ADD011963200805FC1456204BCC082@email1.wes.mot.com>
Date:         Fri, 3 Mar 2000 14:19:08 -0600
Reply-To: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Subject:      [MOBILE-IP] charter update
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

The discussion is still going although it seems to have strayed from the
point just a tad..  Here's what I've gathered from all the posts so far.

First, there does seem to be some interest in producing a document with the
goal of achieving some common definitions about handover so that we'll
understand more easily what one another say.  It sounds like at least a
couple of people are interested in working on such a document.  From past
experience working between the TDMA and the CDMA  worlds and trying to
explain some of the possibilities to folks who are new to this I would have
to say this could be a very valuable tool.

Second, although there are discussions about exactly how mobility is to be
supported in cellular networks I haven't heard anything that sounds like a
consensus to update the charter of this working group to do this work.  I
think Pat said it well that he suggested our task was to find ways to
support the needs of the cellular industry without trying to design their
networks for them.
Perhaps if there is interest in one or more of the fast handoff drafts we
can make them work items under the activity of "facilitating deployment of
mobile ip" and just leave the charter as is for now.

Seem okay?


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 15:39:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08622
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 15:39:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.106EEDE0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 15:35:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71828 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 15:33:30 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.D40254F0@standards.nortelnetworks.com>;
          Fri, 3 Mar 2000 15:33:30 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA14844 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 13:37:07
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          MAA24102 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar
          2000 12:37:06 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id MAA29216; Fri, 3 Mar 2000 12:37:05
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MRBRXPb8QhiUbVTRx3w8GA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003032037.MAA29216@nasnfs.eng.sun.com>
Date:         Fri, 3 Mar 2000 12:38:35 -0800
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         pcalhoun@ha1mpk-mail.eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Pat,

>So, I would like to propose that we agree on some new terminology. I believe
>that we have: - Link Layer Mobility (Inter-BTS hand-off)
>- pick a name Mobility (inter-BSC hand-off)
>- Intra-Domain Mobility (Inter-MSC hand-off)
>- Inter-Domain Mobility (when the hand-off crosses a domain boundary)

I think this is a useful characterization, but I would be careful about
specifying in relation to physical elements in the current CDMA IS-95
networks.

The problem is that most RAN vendors do SDU/macrodiversity combining
at the BSC, but Lucent has a product that does it at the MSC. Hence,
specifying with relation to the physical location of the SDU/macrodiversity
function can be looked at as excluding the mapping of a particular
function to a particular physical implementation. I think
the relevent dividing line is where the macrodiversity combining is
occuring. It is that feature which determines whether mobile-IP
in its current form will work.

So I would say that the characterization should be:

Link Layer, or Micro, Mobility (currently) - multiple CDMA radio streams present
Macromobility - macrodiversity combining has been performed
...

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 16:34:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09994
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 16:34:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B798FD0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 16:28:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71904 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 16:26:39 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.40C86280@standards.nortelnetworks.com>; Fri, 3 Mar 2000 16:26:39
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA12745 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 13:30:16
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          NAA28319; Fri, 3 Mar 2000 13:30:15 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id NAA00524; Fri, 3 Mar 2000 13:30:15
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cWxKXYCF5ruj00HKKdnJ/g==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003032130.NAA00524@nasnfs.eng.sun.com>
Date:         Fri, 3 Mar 2000 13:31:44 -0800
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@eng.sun.com>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         pcalhoun@ha1mpk-mail.eng.sun.com
X-cc:         pcalhoun@ha1mpk-mail.eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>Jim, my intention was not to get boggled down in cellular terminology, and
>especially not in any particular vendor's implementation. If one
>implementation doesn't respect the different levels below, then so be it. I am
>trying to describe the various levels, assuming someone has created a truly
>modular network.
>

Sorry, Pat, you asked for comment so I commented. :-)

>That said, let's forget the cellular terminology, and rather concentrate on
>the new terminology that we need to create.
>
>

Yes, I agree.

I also agree with the goal of trying to come up with a flexible framework
that will accommodate the maximum possible radio technologies.

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 16:38:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09996
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 16:34:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7BA1FF60@standards.nortelnetworks.com>; Fri, 3 Mar 2000 16:28:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 71901 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 16:26:55 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E421EDE0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 16:16:54
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA08583 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 3 Mar 2000 13:20:31
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.55.34]) by engmail2.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id NAA26549; Fri, 3 Mar
          2000 13:20:30 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          NAA26047; Fri, 3 Mar 2000 13:20:24 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952118424.26240.pcalhoun@ha1mpk-mail>
Date:         Fri, 3 Mar 2000 13:20:24 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         James Kempf <James.Kempf@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <200003032037.MAA29216@nasnfs.eng.sun.com>

Sigh.

Jim, my intention was not to get boggled down in cellular terminology, and
especially not in any particular vendor's implementation. If one
implementation doesn't respect the different levels below, then so be it. I am
trying to describe the various levels, assuming someone has created a truly
modular network.

That said, let's forget the cellular terminology, and rather concentrate on
the new terminology that we need to create.

PatC

> Hi Pat,
>
> >So, I would like to propose that we agree on some new terminology. I believe
> >that we have: - Link Layer Mobility (Inter-BTS hand-off) >- pick a name
> Mobility (inter-BSC hand-off) >- Intra-Domain Mobility (Inter-MSC hand-off)
> >- Inter-Domain Mobility (when the hand-off crosses a domain boundary)
>
> I think this is a useful characterization, but I would be careful about
> specifying in relation to physical elements in the current CDMA IS-95
> networks.
>
> The problem is that most RAN vendors do SDU/macrodiversity combining
> at the BSC, but Lucent has a product that does it at the MSC. Hence,
> specifying with relation to the physical location of the SDU/macrodiversity
> function can be looked at as excluding the mapping of a particular
> function to a particular physical implementation. I think
> the relevent dividing line is where the macrodiversity combining is
> occuring. It is that feature which determines whether mobile-IP
> in its current form will work.
>
> So I would say that the characterization should be:
>
> Link Layer, or Micro, Mobility (currently) - multiple CDMA radio streams
> present Macromobility - macrodiversity combining has been performed
> ...
>
>               jak
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 19:10:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12390
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 19:10:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97003720@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:06:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72098 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 19:04:43 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.55509270@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:04:43
          -0500
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 QAA20733;
          Fri, 3 Mar 2000 16:08:15 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id QAA18719; Fri, 3 Mar 2000 16:08:14 -0800
X-Virus-Scanned:  Fri, 3 Mar 2000 16:08:14 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma018309; Fri, 3 Mar 00 16:08:03 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <45AFD48D077ED211BB4700A0C9DCE8FD15AF43@monza.broadswitch.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C053E3.E298A102@iprg.nokia.com>
Date:         Fri, 3 Mar 2000 16:08:03 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Thomas Eklund <thomas.eklund@SWITCHCORE.COM>,
              Alessio Casati <acasati@LUCENT.COM>,
              "Basavaraj Patil (NTC/Dallas)" <Raj.Patil@nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Thomas and Alessio and Basavaraj,

>>> Mobile IP's access independence characteristic makes it so viable.
>>> So there's not much to be said for IP mobility support over specific
>>> access technologies as you propose.

>> I'm not so sure about this as you are. I just say
>> IP itself is technology indep., but if you
>> want to support intserv there is for instance an ISSLOW spec,
>> an ISATM spec, and a spec on how to support
>> Qos on 802.x stuff.

> Since I work with this as well I could not agree more...
> It is very important to map the link characteristics to the mobility
> management (which in our case is IP based) in order to make it efficient...

But whether it is important depends on the link.  For some or maybe
most links, Mobile IP works great without any changes.  And a lot
of the recent discussion about changes to Mobile IP doesn't have
anything to do with link characteristics, but more how the link is
to be operated because of very high-level policy decisions.

I'd rather consider Mobile IP as link-independent, and then engineer
specific extensions for particular links when and if they are needed.

For the specific case of QoS, I reckon that a layer-2 mechanism is
required to implement whatever layer-3 allocations have been made
(on the basis of whatever application-layer requests have been
 fulfilled).  But that is a QoS problem, not a Mobile IP problem.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 19:29:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12518
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 19:29:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.409932D0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:25:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72143 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 19:24:35 -0500
Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1BD21160@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:24:35
          -0500
Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61])
          by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id TAA13579;
          Fri, 3 Mar 2000 19:28:09 -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <45AFD48D077ED211BB4700A0C9DCE8FD15AF43@monza.broadswitch.com>
            <38C053E3.E298A102@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C085FE.71A2E0ED@comet.columbia.edu>
Date:         Fri, 3 Mar 2000 19:41:50 -0800
Reply-To: campbell@comet.columbia.edu
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
Organization: Center for Telecommunications Research
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree with Charlie on decoupling for QOS.

IP is link independent as Mobile IP is.

When a QOS model is developed out for Mobile IP (e.g.,
wireless DiffServ) on could imagine mapping to the radio link
via issll type techniques via some open API that
provides quality indicators for handoff (SNR, etc.)
and for resource allocation.

But to make Mobile IP dependent on that API is
a NOP.

Andrew



"Charles E. Perkins" wrote:
>
> Hello Thomas and Alessio and Basavaraj,
>
> >>> Mobile IP's access independence characteristic makes it so viable.
> >>> So there's not much to be said for IP mobility support over specific
> >>> access technologies as you propose.
>
> >> I'm not so sure about this as you are. I just say
> >> IP itself is technology indep., but if you
> >> want to support intserv there is for instance an ISSLOW spec,
> >> an ISATM spec, and a spec on how to support
> >> Qos on 802.x stuff.
>
> > Since I work with this as well I could not agree more...
> > It is very important to map the link characteristics to the mobility
> > management (which in our case is IP based) in order to make it efficient...
>
> But whether it is important depends on the link.  For some or maybe
> most links, Mobile IP works great without any changes.  And a lot
> of the recent discussion about changes to Mobile IP doesn't have
> anything to do with link characteristics, but more how the link is
> to be operated because of very high-level policy decisions.
>
> I'd rather consider Mobile IP as link-independent, and then engineer
> specific extensions for particular links when and if they are needed.
>
> For the specific case of QoS, I reckon that a layer-2 mechanism is
> required to implement whatever layer-3 allocations have been made
> (on the basis of whatever application-layer requests have been
>  fulfilled).  But that is a QoS problem, not a Mobile IP problem.
>
> Regards,
> Charlie P.

--
Andrew
http://comet.columbia.edu/~campbell


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 19:49:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12695
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 19:49:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0EE18230@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:45:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72205 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 19:44:33 -0500
Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.E5CCD890@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:44:32
          -0500
Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61])
          by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id TAA14251;
          Fri, 3 Mar 2000 19:48:05 -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C08AA9.E7E74AE4@comet.columbia.edu>
Date:         Fri, 3 Mar 2000 20:01:45 -0800
Reply-To: campbell@comet.columbia.edu
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
Organization: Center for Telecommunications Research
Subject:      [MOBILE-IP] Thesis/Cellular IP
X-cc:         cellularip@comet.columbia.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Folks:

Andras Valko's thesis work on  "Design and Analysis of
Cellular Mobile Data Networks" is available at

 http://comet.columbia.edu/cellularip/

It includes the most complete reference on
the Cellular IP work at Columbia.

The source code for Cellular IP is avail
at the same site. We also intend to release the
NS code in a few weeks for those interested.

Best,
Andrew


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 20:48:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13180
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 20:48:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4F9D3050@standards.nortelnetworks.com>; Fri, 3 Mar 2000 20:44:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72257 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 20:43:12 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.B1DD6390@standards.nortelnetworks.com>;
          Fri, 3 Mar 2000 20:33:12 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id SAA06892; Fri, 3 Mar 2000 18:36:48
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.93.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id RAA19717; Fri, 3 Mar
          2000 17:36:47 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          RAA24039; Fri, 3 Mar 2000 17:36:46 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  <Roam.SIMC.2.0.6.952133805.13083.pcalhoun@ha1mpk-mail>
Date:         Fri, 3 Mar 2000 17:36:45 -0800
Reply-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <51F347B016ADD011963200805FC1456204BCC082@email1.wes.mot.com>

> The discussion is still going although it seems to have strayed from the
> point just a tad..  Here's what I've gathered from all the posts so far.
>
> First, there does seem to be some interest in producing a document with the
> goal of achieving some common definitions about handover so that we'll
> understand more easily what one another say.  It sounds like at least a
> couple of people are interested in working on such a document.  From past
> experience working between the TDMA and the CDMA  worlds and trying to
> explain some of the possibilities to folks who are new to this I would have
> to say this could be a very valuable tool.
>
> Second, although there are discussions about exactly how mobility is to be
> supported in cellular networks I haven't heard anything that sounds like a
> consensus to update the charter of this working group to do this work.  I
> think Pat said it well that he suggested our task was to find ways to
> support the needs of the cellular industry without trying to design their
> networks for them.
> Perhaps if there is interest in one or more of the fast handoff drafts we
> can make them work items under the activity of "facilitating deployment of
> mobile ip" and just leave the charter as is for now.
>
> Seem okay?

not really. AAA is one way to facilitate deployment of Mobile IP, but not fast
hand-off, IMHO. This is really new work, and although we could conceal it
under a variety of existing work items in the charter, I think that we should
specifically spell out that we will develop a scheme to provide fast hand-off
at the IP layer. Please note, however, that we *may* find that there are
optimizations that can be done for specific link layers, and if we decide that
hand-offs is a work item that we want to take on, we will get into link layer
issues. A one-size fits all may not apply here.

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar  3 21:05:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13346
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 3 Mar 2000 21:05:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8E82A690@standards.nortelnetworks.com>; Fri, 3 Mar 2000 21:00:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72323 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 20:59:24 -0500
Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.5AEF1160@standards.nortelnetworks.com>; Fri, 3 Mar 2000 20:59:24
          -0500
Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61])
          by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id VAA16337;
          Fri, 3 Mar 2000 21:02:57 -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.952133805.13083.pcalhoun@ha1mpk-mail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C09C35.50900004@comet.columbia.edu>
Date:         Fri, 3 Mar 2000 21:16:37 -0800
Reply-To: campbell@comet.columbia.edu
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
Organization: Center for Telecommunications Research
Subject:      Re: [MOBILE-IP] charter update
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
X-cc:         cellularip@comet.columbia.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pat:

"pcalhoun@eng.sun.com" wrote:

> not really. AAA is one way to facilitate deployment of Mobile IP, but not fast
> hand-off, IMHO. This is really new work, and although we could conceal it
> under a variety of existing work items in the charter, I think that we should
> specifically spell out that we will develop a scheme to provide fast hand-off
> at the IP layer. Please note, however, that we *may* find that there are
> optimizations that can be done for specific link layers, and if we decide that
> hand-offs is a work item that we want to take on, we will get into link layer
> issues. A one-size fits all may not apply here.
>
> PatC

I think there has been a wide range of proposals on micro-mobility.

If the working group thinks it worthwhile (or even needed, above and
beyond
making Mobile IP go faster and, be more scalable in the signaling
load it generates under wide scale deployment) then some
consensus could be reached by considering the
existing proposals.

My feeling is that the solution space for
micro-mobiliy is well covered. That is not to
say that better solutions could not be proposed.

Of course I would be in favor for the charter to
explicitly call out a specific work item on
"micro-mobility. People actively pushing micro-mobility
could come to a consensus with a join ID for the
working group to consider. I think this could
be done quite quickly once we understand the
trade off of the current proposals.

--
Andrew
http://comet.columbia.edu/~campbell


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar  4 05:49:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01800
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Mar 2000 05:49:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6811780@standards.nortelnetworks.com>; Sat, 4 Mar 2000 5:45:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72689 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Mar 2000 05:43:36 -0500
Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.95844810@standards.nortelnetworks.com>; Sat, 4 Mar 2000 5:43:35
          -0500
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA19552
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Mar 2000
          05:47:14 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id FAA19538 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Sat, 4 Mar 2000 05:47:14 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <1P82F41G>; Sat, 4 Mar 2000 10:47:13 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876A09@en0060exch001u.uk.lucent.com>
Date:         Sat, 4 Mar 2000 10:47:11 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Thomas Eklund <thomas.eklund@SWITCHCORE.COM>,
              "Basavaraj Patil (NTC/Dallas)" <Raj.Patil@nokia.com>,
              "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charlie,

Mobile IP [RFC2002 and its bis] is link independent.
No discussion.
Nobody argues.

But, since we have recorded many messages on updating
charter, we have to carefully understand what can fit
in this group activity and what not.

What's wrong with this? (which is what I meant in my msg)

> I'd rather consider Mobile IP as link-independent, and then engineer
> specific extensions for particular links when and if they are needed.
>
...And this may be work to be handled by another WG. Much in the
same way as the INTSERV WG and an ISSLL WG.

> For the specific case of QoS, I reckon that a layer-2 mechanism is
> required to implement whatever layer-3 allocations have been made
> (on the basis of whatever application-layer requests have been
>  fulfilled).  But that is a QoS problem, not a Mobile IP problem.
>
Which may require a new WG.

Regards

alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar  4 06:07:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01937
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Mar 2000 06:07:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CF900A0@standards.nortelnetworks.com>; Sat, 4 Mar 2000 6:03:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 72738 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Mar 2000 06:02:26 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3739EAA0@standards.nortelnetworks.com>; Sat, 4 Mar 2000 6:02:26
          -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA07246
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Mar 2000
          06:06:05 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id GAA07239 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Sat, 4 Mar 2000 06:06:04 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <1P82F4GR>; Sat, 4 Mar 2000 11:06:03 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876A0C@en0060exch001u.uk.lucent.com>
Date:         Sat, 4 Mar 2000 11:06:00 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         "campbell@comet.columbia.edu" <campbell@comet.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Pat:
>
> "pcalhoun@eng.sun.com" wrote:
>
> > not really. AAA is one way to facilitate deployment of Mobile IP, but
> not fast
> > hand-off, IMHO. This is really new work, and although we could conceal
> it
> > under a variety of existing work items in the charter, I think that we
> should
> > specifically spell out that we will develop a scheme to provide fast
> hand-off
> > at the IP layer. Please note, however, that we *may* find that there are
> > optimizations that can be done for specific link layers, and if we
> decide that
> > hand-offs is a work item that we want to take on, we will get into link
> layer
> > issues. A one-size fits all may not apply here.
> >
> > PatC
>
> I think there has been a wide range of proposals on micro-mobility.
>
> If the working group thinks it worthwhile (or even needed, above and
> beyond
> making Mobile IP go faster and, be more scalable in the signaling
> load it generates under wide scale deployment) then some
> consensus could be reached by considering the
> existing proposals.
>
Andrew, would a FA at a GGSN require a micromobility support?
Would a FA at a PDSN require anything more than what the
R-P interface provides?

If not, then Pat is right (and you are wrong)

> My feeling is that the solution space for
> micro-mobiliy is well covered. That is not to
> say that better solutions could not be proposed.
>
>
Current micromobility solution do actually cover a solution
space. I would like to know which problem space this solution
space is mapped to.

Micromobility is by definition provided
by access nets, so the only way the IETF could
claim to provide micromobility protocols
is to enter in the access nets business (which are
layer 2).

There are two ways the IETF can enter the access net business:
either by defining a protocol that fits in an access net
designed by other bodies (and the R-P is the first instance
I've seen along these lines) or by defining it's own
router based access network. The second goal is far more ambitious
that the first and I sort of condider this a long term
work (if the IETF will ever like to enter this business).


cheers


alessio





> Of course I would be in favor for the charter to
> explicitly call out a specific work item on
> "micro-mobility. People actively pushing micro-mobility
> could come to a consensus with a join ID for the
> working group to consider. I think this could
> be done quite quickly once we understand the
> trade off of the current proposals.
>
> --
> Andrew
> http://comet.columbia.edu/~campbell
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar  4 18:04:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08829
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Mar 2000 18:04:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75F33440@standards.nortelnetworks.com>; Sat, 4 Mar 2000 18:00:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73191 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Mar 2000 17:58:46 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4986AD10@standards.nortelnetworks.com>; Sat, 4 Mar 2000 17:58:46
          -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id PAA19707 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Mar 2000 15:02:26
          -0800 (PST)
Received: from antley.eng.sun.com (antley.Eng.Sun.COM [129.146.86.225]) by
          engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          PAA28573 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sat, 4 Mar
          2000 15:02:25 -0800 (PST)
Received: from antley (antley [129.146.86.225]) by antley.eng.sun.com
          (8.9.3+Sun/8.9.3) with SMTP id PAA07118; Sat, 4 Mar 2000 15:02:10
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: VggXPqLuioJDD62uUN4hUA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc
Message-ID:  <200003042302.PAA07118@antley.eng.sun.com>
Date:         Sat, 4 Mar 2000 15:02:10 -0800
Reply-To: Carl Williams <carlw@antley.eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Carl Williams <carlw@antley.eng.sun.com>
Subject:      [MOBILE-IP] Reminder:  San Jose -- IPv6 Wireless and Mobility
              Roundtable
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Reminder:  The wireless and mobility roundtable
is this Monday from 4:00pm-6:00pm at the Crowne Plaza
Hotel in downtown San Jose, CA.  This event
is open to everyone. No need to register.
Please drop by to what will be an interesting
discussion!

See you then...

Carl

Details below:


IPv6 Wireless and Mobility Roundtable
=====================================

Connectathon 2000 is presenting a roundtable
discussion on IPv6 Wireless and Mobility as part of
the interoperability testing event this year. The
roundtable is being cosponsored with the IPv6 Forum.

The panel will contain key individuals leading the
standards, research and/or implementation efforts in
IPv6 and Wireless protocols. The discussion is open to
anyone.  An email invitation is being sent out to the
Mobile IP and IPv6 IETF working group members to
participate in the audience.  Members of the audience
will have an opportunity to ask questions to the panel
on topics relating to IPv6 and Wireless.

Round Table Discussion: IPv6 for Wireless and Mobility

The wireless cellular industry, particularly as it
prepares to deploy 2.5G and 3G services has been touted
as the "killer application" for IPv6. An obvious first
consideration to support this notion is the sheer number of
devices expected to come on-line via cellular technologies.
Predictions range from 600 million to 1 billion at the turn
of 4 to 5 years. Managing such a large and sudden influx
of devices connected via highly dynamic and unreliable
links is a task far more challenging than any the Internet
has faced to date.

The panel will explore how IPv6 can rise to the challenge,
as well as its remaining deficiencies. The following
features of IPv6 are some of the topics (but not limited to)
that will be discussed at the roundtable:

- How can IPv6 streamline the routing infrastructure?
  IPv6 may have a better chance than IPv4 at
  route aggregation, because of better initial
  assignment of address ranges and because of
  its provisions for renumbering. What remains
  to be done?
- Role of autoconfiguration for mobile networking.
  Mobile and wireless devices need to bootstrap all
  configuration information based on a secure token
  or on a cryptographic identity. The rest should
  be automatic. This is particularly relevant when
  considering other wireless technologies like
  Bluetooth that will need to interact with cellular,
  and in which the automatic configuration requirements
  apply to a collection of devices.
- How can IPv6 improve the security infrastructure?
  IPv6 does mandate IPsec, but how practical or
  deployable is it in a cellular environment?
- Can Mobile IP simplify the future Internet? Does
  IPv6 provide other mechanisms to deal with mobility?
  Is it better handled at a layer other than layer 3
  (as in Mobile IP)?
- What is the interaction between IPv6 and cellular
  telephone standards?
  There seems to be little more than lip service to IPv6
  on the part of next generation cellular consortiums
  like 3GPP, 3GPP2, and MWIF. Do they have valid concerns?
- Issues with supporting 500 Million IP Wireless Devices.
  What is the right addressing scheme that needs to be used?
  Are E.164 based addresses more appropriate for cellular
  than EUI-64 (more common with LAN hardware)?
- The IPv6 header is twice as large as its IPv4 counterpart,
  but routers should have a much easier time processing and
  forwarding packets.  The IPv6 header is simpler to compress.
  The size of the average compressed IPv6 header will be
  smaller than the  corresponding IPv4 header (although the
  difference is not large).  So the cost of using IPv6
  over the air links will be somewhat less than when using
  IPv4.

The above issues apply to both the core network as well as
to the wireless devices.  Members of the audience can
raise any topic regarding IPv6 for Mobility or Wireless
at this roundtable.  Discussion is not limited to those
topics above.


Roundtable Panel

Charlie Perkins                      Robert Hinden
Nokia Research Laboratories          Nokia

Steve Deering                        Martin Korling
Cisco Systems                        Ericsson Research

Erik Nordmark                        Dave Johnson
Sun Microsystems                     Carnegie Mellon University

Brian Zill                           Jun-ichiro Hagino
Microsoft Research                   Internet Initiative Japan Inc.

Mihai Mateescu
Mobile and Broadband Wireless Communications of GMD


Date, Time and Place

Monday, March 6, 2000
4:00pm-6:00pm

Crowne Plaza Hotel
282 Almaden Blvd
San Jose, CA
Phone # for Crowne Plaza: (408) 998-0400

The roundtable discussion will take place in the Crowne
Plaza Hotel Ballroom.  You do *not* need to RSVP to attend
the roundtable.  Just show up at the Crowne Plaza Hotel
Ballroom.  There is no registration required for participating.
While admission to the IPv6 Wireless and Mobility roundtable is
free and open to all, only registered participants of Connectathon
will be allowed into the testing halls.

Mobile IP Dinner
================

Some members of the panel will be joining Connectathon
participants for dinner after the event at a local San Jose
restaurant.  If you are interested in attending the dinner
you *must* RSVP John Hird at jrh@eng.sun.com.  You will be
responsible for the cost of your dinner.  More information
about where the dinner will be provided at the roundtable
event.  There will be limited room so the RSVP will be on
a first come basis.

Ericsson Presentation
=====================

A presentation by Ericsson will be made on their Mobile IPv6
research implementation immediately preceding the roundtable
in the same room (Crowne Plaza Hotel Ballroom) from 3:00pm-3:45pm.
Conny Larsson of Ericsson Research will be presenting.  Again,
this is open to anyone.

Abstract of talk by Conny Larsson, Ericsson Research:

The Ericsson Mobile IPv6 implementation is a free implementation
using FreeBSD and the KAME IPv6 implementation. It has been
implemented as part of a research project at Ericsson. It consists
of three parts; the Correspondent Node, the Home Agent and the
Mobile Node. In addition, two applications are offered for
configuration and retrieving statistical information.  This talk
will go over the Ericsson Research Mobile IPv6 implementation.


References:

www.connectathon.org  - for more information on Connectathon 2000.
www.ipv6forum.com     - for more information on the Worldwide
                        consortium of leading Internet vendors,
                        Research & Education Networks.

Connectathon 2000 participants performing interoperability testing
for the Mobile IP, IPv6, Mobile IPv6 and/or DIAMETER protocols:

Apple Computer, Inc., Cisco Systems, Inc., Carnegie Mellon University,
Ericsson Inc., ENST (Ecole National Superieure des Telecommunications) Bretagne,
Hewlett-Packard Company, Hitachi, Ltd., IBM Corporation, KAME Project,
MCI Worldcom, Microsoft Corporation, NEC Corporation, Nokia Research Center,
SCO Ltd., Sun Microsystems, Inc., Silicon Graphics, Inc., TAHI, Toshiba
Corporation, University of New Hampshire, Mobile and Broadband Wireless
Communications of GMD


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar  4 18:12:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08889
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Mar 2000 18:12:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.963685D0@standards.nortelnetworks.com>; Sat, 4 Mar 2000 18:08:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73234 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Mar 2000 18:06:31 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.5E2CD1D0@standards.nortelnetworks.com>; Sat, 4 Mar 2000 18:06:30
          -0500
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 PAA10755;
          Sat, 4 Mar 2000 15:10:09 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id PAA18106; Sat, 4 Mar 2000 15:10:09 -0800
X-Virus-Scanned:  Sat, 4 Mar 2000 15:10:09 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma017978; Sat, 4 Mar 00 15:10:06 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.952133805.13083.pcalhoun@ha1mpk-mail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C197CE.9579051@iprg.nokia.com>
Date:         Sat, 4 Mar 2000 15:10:06 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] charter update
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Pat,


>                ..............                                but not fast
> hand-off, IMHO. This is really new work, and although we could conceal it
> under a variety of existing work items in the charter, I think that we should
> specifically spell out that we will develop a scheme to provide fast hand-off
> at the IP layer.

While I'm not adverse to taking this on as a charter goal,
I feel a little disconcerted to hear it described as new
work.  After all, we had a route optimization draft with
the Previous Foreign Agent Notification extension for years,
and a Registration Keys draft intended to make it secure.
Plus, there have been for years various attempts to create
regional registrations.

You may rightfully point out that the existing schemes could
be made better.  That doesn't justify consigning them into
a box of irrelevancies.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar  4 21:19:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09926
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 4 Mar 2000 21:19:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB88F880@standards.nortelnetworks.com>; Sat, 4 Mar 2000 21:15:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73350 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 4 Mar 2000 21:13:26 -0500
Received: from mail.swiss-sport.ch (194.209.220.10) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.15164DA0@standards.nortelnetworks.com>; Sat, 4 Mar 2000
          21:03:25 -0500
Received: from ip120.providence11.ri.pub-ip.psi.net
          (ip120.providence11.ri.pub-ip.psi.net [38.26.242.120]) by
          mail.swiss-sport.ch (NTMail 4.20.0009/NU0900.00.1c00e0e6) with ESMTP
          id uetcaaaa for <mobile-ip@standards.nortelnetworks.com>; Sun, 5 Mar
          2000 03:04:32 +0100
X-Mailer: Mozilla 4.50 [en] (Win95; I)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <02043260912214@bettergolf.net>
Date:         Sat, 4 Mar 2000 19:40:39 -0500
Reply-To: Wayne <petr82@BETTERGOLF.NET>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Wayne <petr82@BETTERGOLF.NET>
Subject:      [MOBILE-IP] Retire in 2-3 years
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA09926

I'm looking for quality individuals serious about earning a minimum
of $10,000 a month, not MLM.

Are YOU serious about earning that type of money?

Call toll free 24 hrs/ 1-800-320-9895 ext 8702

/////////////////////////////////////////////////////////////////////
/
Please remove at:
mailto:frank4545@yahoo.com?subject=remove
//////////////////////////////////////////////////////////////////////


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar  5 04:49:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07320
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 5 Mar 2000 04:49:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A137C350@standards.nortelnetworks.com>; 5 Mar 2000 4:45:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73538 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Mar 2000 04:43:31 -0500
Received: from igw1.ericsson.com.au by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F575FEC0@standards.nortelnetworks.com>; 5 Mar 2000 4:33:30 -0500
Received: from brsi02.epa.ericsson.se ([146.11.15.8]) by igw1.ericsson.com.au
          (8.9.1b+Sun/8.9.1) with ESMTP id UAA05671; Sun, 5 Mar 2000 20:37:09
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA28503; Sun, 5
          Mar 2000 20:37:42 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0)
          id <GD47F08B>; Sun, 5 Mar 2000 20:37:06 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8686.5E74D37C"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50185D745@eaubrnt018.epa.ericsson.se>
Date:         Sun, 5 Mar 2000 20:37:02 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF8686.5E74D37C
Content-Type: text/plain

Hi Pat

> Why is Hierarchical Mobile IP not included here? Mobile IP can be used to
> provide micro mobility. The reason is because some people's definition of
> micro mobility is vastly different from others. Hence the reason why I
> want to
> move *away* from these terms, and create something new that is very well
> defined.
>
> PatC
>
        Absolutely, we have a draft adressing exactly that (HMIP) for both
V4 and V6.

        Hesham

------_=_NextPart_001_01BF8686.5E74D37C
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2644.0">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hi Pat</FONT>
</P>
<UL>
<P><FONT SIZE=2 FACE="Arial">Why is Hierarchical Mobile IP not included here? Mobile IP can be used to</FONT>
<BR><FONT SIZE=2 FACE="Arial">provide micro mobility. The reason is because some people's definition of</FONT>
<BR><FONT SIZE=2 FACE="Arial">micro mobility is vastly different from others. Hence the reason why I want to</FONT>
<BR><FONT SIZE=2 FACE="Arial">move *away* from these terms, and create something new that is very well</FONT>
<BR><FONT SIZE=2 FACE="Arial">defined.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">PatC</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Absolutely, we have a draft adressing exactly that (HMIP) for both V4 and V6.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BF8686.5E74D37C--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar  5 16:07:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11434
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 5 Mar 2000 16:07:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42174C60@standards.nortelnetworks.com>; 5 Mar 2000 16:02:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 73839 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Mar 2000 16:01:32 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.131FFBA0@standards.nortelnetworks.com>; 5 Mar 2000 16:01:32 -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA11805 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 5 Mar 2000 13:05:14
          -0800 (PST)
Received: from antley.eng.sun.com (antley.Eng.Sun.COM [129.146.86.225]) by
          engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          NAA21563 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 5 Mar
          2000 13:05:14 -0800 (PST)
Received: from antley (antley [129.146.86.225]) by antley.eng.sun.com
          (8.9.3+Sun/8.9.3) with SMTP id NAA08557; Sun, 5 Mar 2000 13:04:57
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DLQ/3by0dLrvZz8iJNx1kg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc
Message-ID:  <200003052104.NAA08557@antley.eng.sun.com>
Date:         Sun, 5 Mar 2000 13:04:57 -0800
Reply-To: Carl Williams <carlw@antley.eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Carl Williams <carlw@antley.eng.sun.com>
Subject:      [MOBILE-IP] Mobile IP dinner
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Will happen after the Roundtable. Still some room.
We have about 50 signed up.

Again, send email to jrh@eng.sun.com for RSVP to
do the Mobile iP dinner.  *NO* need to RSVP for
attending roundtable - it is open to anyone and
no registration required.

Also Reminder:  Conny Larson will be talking at 3:00pm
at the Crowne Plaza Ballroom on the Ericsson Mobile IPv6
research implementation on Monday (3/6).


Mobile IP Dinner
================

Some members of the panel will be joining Connectathon
participants for dinner after the event at a local San Jose
restaurant.  If you are interested in attending the dinner
you *must* RSVP John Hird at jrh@eng.sun.com.  You will be
responsible for the cost of your dinner.  More information
about where the dinner will be provided at the roundtable
event.  There will be limited room so the RSVP will be on
a first come basis.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 02:35:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00422
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 02:35:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C32F0430@standards.nortelnetworks.com>; Mon, 6 Mar 2000 2:29:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74142 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 02:27:22 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.802CC7D0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 2:27:21
          -0500
Received: from gdommety-pc2 (gdommety-dsl2.cisco.com [10.19.17.139]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          XAA27525 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Sun, 5 Mar
          2000 23:31:01 -0800 (PST)
X-Sender: gdommety@omega.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003060731.XAA27525@omega.cisco.com>
Date:         Sun, 5 Mar 2000 23:42:39 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      [MOBILE-IP] Vendor Specific Extensions draft
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003052104.NAA08557@antley.eng.sun.com>

Hello:

        In the format of the Vendor Specific Extensions, we are making the following change:

Previously Vendor-Type and opaque data were defined. It was  recommended that the opaque date be encoded as length and value pair.

Now Vendor-Type, Vendor-Lenght, and Vendor-Value are defined.

Please let me know if any of you have any objections. I am appending the draft.

Thanks
Gopal



Mobile IP Working Group                                    Gopal Dommety
INTERNET DRAFT                                             Kent Leung
February 2000                                              cisco Systems

Expires August 2000

           Mobile IP Vendor/Organization-Specific Extensions
                draft-ietf-mobileip-vendor-ext-10.txt

Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document defines two new extensions to Mobile
   IP [1]. These extensions will facilitate equipment vendors and
   organizations to make specific use of these extensions as they see
   fit for research or deployment purposes.

Dommety, Leung                                                  [Page 1]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

1. Introduction

   Current specification of Mobile IP [1] does not allow for
   organizations and vendors to include organization/vendor-specific
   information in the Mobile IP messages. With the imminent wide scale
   deployment of Mobile IP it is useful to have vendor or
   organization-Specific Extensions to support this capability. This
   draft defines two extensions that can be used for making
   organization specific extensions by vendors/organizations for
   their own specific purposes.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the requirements
   of the specification.

   silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.


2. Vendor/Organization Specific Extensions

   Two Vendor/Organization Specific Extensions are described, Critical
   (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions.
   The basic differences  between the Critical and Normal Extensions
   are that when the Critical extension is encountered but not recognized,
   the message containing the extension MUST be silently discarded, whereas
   when a Normal Vendor/Organization Specific Extension is encountered
   but not recognized, the extension SHOULD be ignored, but the rest of the
   Extensions and message data MUST still be processed. Another
   difference between the two is that Critical Vendor/Organization
   Extension has a length field of two octets and the NVSE has a
   length field of only one octet.

2.1. Critical Vendor/Organization Specific Extension (CVSE)

   The format of this extension is as shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor/Org-ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Vendor-CVSE-Type     |         Vendor-Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Vendor-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



             Figure 1: Critical Vendor/Organization Specific Extension

   Type       38 (To be assigned by IANA)


   Reserved   Reserved for future use. MUST be set to 0 on sending,
              MUST be ignored on reception.

   Length     Length in bytes of this extension, not including the
              Type and Length bytes.

   Vendor/Org-ID
              The high-order octet is 0 and the low-order 3 octets

Dommety, Leung                                                  [Page 2]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

              are the SMI Network Management Private Enterprise Code
              of the Vendor in network byte order, as defined in the
              Assigned Numbers RFC [2].

   Vendor-CVSE-Type
              Indicates the particular type of Vendor-Sub-Extension.  The
              administration of the Vendor-CVSE-Types is done by the
              Vendor.
   Vendor-Length
              Length in bytes of this Vendor-Sub-Extension, not including the
              Vendor-CVSE-Type and Vendor-Length bytes.

   Vendor-Data

              Vendor/organization specific data of this Vendor-Sub-Extension.
              These data fields may be published in future RFCs.  The
              Vendor-Data is zero or more octets.

   Multiple Vendor-Sub-Extensions specified by Vendor-CVSE-Type, Vendor-Length,
   and Vendor-Data can be included in a CVSE.

   The length field of this extension is chosen to be two bytes long
   to allow for more than 248 bytes of Opaque Data.  If an
   implementation does not recognize the CVSE, according to RFC [1]
   the entire packet is to be silently dropped. But if an agent
   recognizes the CVSE, then it is aware of how to deal with the
   length size.

2.2. Normal Vendor/Organization Specific Extension (NVSE)

   The format of this extension is as shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |               Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vendor/Org-ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Vendor-NVSE-Type           | Vendor-Length | Vendor-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 2: Normal Vendor/Organization Specific Extension

   Type       134 (To be assigned by IANA)

   Length     Length in bytes of this extension, not including the
              Type and Length bytes.

   Reserved   Reserved for future use. To be set to 0.

   Vendor/Org-ID
              The high-order octet is 0 and the low-order 3
              octets are the SMI Network Management Private
              Enterprise Code of the Vendor in network byte order,
              as defined in the Assigned Numbers RFC [2].

    Vendor-NVSE-Type
              Indicates the particular type of Vendor-Sub-Extension.
              The administration of the Vendor-NVSE-Types is done by the
              Vendor.

   Vendor-Length
              Length in bytes of this Vendor-Sub-Extension, not including the
              Vendor-NVSE-Type and Vendor-Length bytes.

   Vendor-Data

              Vendor/organization specific data of this Vendor-Sub-Extension.
              These data fields may be published in future RFCs.  The
              Vendor-Data is zero or more octets.

   Multiple Vendor-Sub-Extensions specified by Vendor-NVSE-Type,
   Vendor-Length, and Vendor-Data can be included in a NVSE.

2.3 Vendor/Organization Specific Extensions Processing Considerations

   When a Mobile IP entity receives a registration request message (or
   any other request/update message) with an extension of type 38
   (CVSE) and recognizes it, but the extension contains an
   unknown/unsupported vendor ID or does not know how to interpret the
   opaque data or a part of opaque data, a registration reject (or the
   appropriate deny message) MUST be sent with the error code to
   indicate that the registration was rejected due to the presence of
   an unknown CVSE.

   When a Mobile IP entity receives a registration reply (or any other
   mobile IP reply/acknowledgement message) with an extension of type 38
   (CVSE) and recognizes it, but the extensions contains an
   unknown/unsupported vendor ID or does not know how to interpret the
   opaque data or a part of opaque data, the processing is performed as
   described below.

   1. If the Mobile IP entity is a transit node for the reply (i.e, this
   entity  processes and sends the registration reply to another entity)
   a registration reject (or the appropriate deny message) MUST be sent
   with the error code to indicate that the registration was rejected due
   to the presence of an unknown CVSE. For example, FA when it receives an
   un understood CVSE in a registration reply from the HA, should send a
   registration reject to the MN.

   2. If the Mobile IP entity is not a transit node for the reply, the
   reply is treated as a reject (or the appropriate deny message) due to
   the presence of an unknown CVSE.

   While designing enhancements wherein a CVSE is included in a reply
   message, it should noted that the reply message could be discarded
   by the mobile IP entity processing this message.  Enhancements that
   include  a CVSE should take this into consideration during design.

   When a Mobile IP entity receives a mobile IP related message
   (registration request/reply, advertisement/solicitation, etc) with
   an extension of type 134 (NVSE) and recognizes it, but the extension
   contains an unknown/unsupported vendor ID or does not know how to
   interpret the opaque data, the entire extension is skipped. If it does
   not know how to interpret only a part of the opaque data that part of
   the extension is skipped.

   NOTE that according to RFC 2002 [1], when an extension numbered within
   the range 0 through 127 is encountered in a registration message but
   not recognized, the message containing that extension MUST be
   silently discarded.  This draft is compliant with the above
   specification and specifies the action if the extension of type 38
   is encountered and recognized, but does not support the vendor ID or
   the vendor type extension within.

2.4 Error Codes

   The following error codes are defined.

   Registration denied by the Foreign agent:

        107: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the
        Foreign Agent.

        108: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Home Agent to the
        Foreign Agent.

   Registration denied by the Home agent:

        141: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the Home Agent.

        142: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Foreign Agent to the Home Agent.

Dommety, Leung                                                  [Page 3]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

3. Restrictions

   Multiple TLV's with the types 38 and 134 can be included in a
   message.  TLVs with types 38 and 134 can be placed anywhere after
   the fixed portion of the Mobile IP message.  These TLVs
   are expected to be protected by the corresponding authenticator as
   necessary.  Ordering of these TLV's should not be modified by
   intermediate nodes.

4. IANA Considerations

   The  Critical Vendor/Organization Specific Extension (CVSE) as
   defined in Section 2.1  and Normal  Vendor/Organization  Specific
   Extension (NVSE) as defined in section 2.2 are proposed new
   extensions to the Mobile IP protocol, defined in RFC 2002 [1] and
   extended in RFC 2356 [5].

   The Authors request IANA to assign the Type value of 38 for the
   Critical Vendor/Organization Specific Extension (CVSE), and a Type
   value of 134 for the Normal Vendor/Organization Specific Extension
   (NVSE) from the. The numbers 38 and 134 for the CVSE and the NVSE
   are taken from the numbering space defined for Mobile IP
   registration extensions [1].

   The new code values specified for errors 107, 108, 141, and
   142 as listed in section 2.4, MUST NOT conflict with any other
   code values listed in RFC 2002, RFC 2344 [9], or RFC 2356 [10]. The
   Authors request IANA to record these values.

   The Type  and code numbers requested have  been identified  as not
   conflicting with any numbers defined in RFC 2002 [1] and extended in
   RFC 2344 [4] and RFC 2356 [5] and documented at
   http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.

5. Security Considerations

   This document assumes that the Mobile IP messages are authenticated
   using a method defined by the Mobile IP protocol.  This document does
   not impose any additional requirements on Mobile IP messages from a
   security point of view. So this is not expected to be a security
   issue.

6. Acknowledgments

   The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj
   Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for
   their useful discussions.

7. References

   [1] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       USC/Information Sciences Institute, October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.

   [4] G. Montenegro.  Reverse Tunneling for Mobile IP.  RFC 2344, May
       1998.

   [5] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
       Mobile IP.  RFC 2356, June 1998.

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: gdommety@cisco.com

   Kent Leung
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: kleung@cisco.com

Dommety, Leung

Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 03:45:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00899
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 03:45:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B33660F0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 3:40:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74183 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 03:39:25 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2B6C86F0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 3:29:24
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA05914; Mon, 6 Mar
          2000 10:33:06 +0200 (EET)
Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com
          [131.228.118.244]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP
          id KAA02614; Mon, 6 Mar 2000 10:33:05 +0200 (EET)
Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id <GCLGW2AS>;
          Mon, 6 Mar 2000 10:33:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <771290CD2EE0D211B1940008C7894D0E02AAB566@eseis09nok>
Date:         Mon, 6 Mar 2000 10:32:30 +0200
Reply-To: Jari.T.Malinen@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jari.T.Malinen@NOKIA.COM
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         campbell@comet.columbia.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello, Andrew, and others,

Keeping Mobile IP decoupled from link-specific issues is possibly
needed e.g. to have the flexibility for now unkonwn technologies.

However, since micro-mobility solutions for different scenarios appear
anyway,
mechanisms to provide interoperability, or at least a graceful fallback to
macro-mobility in some cases might be needed. I would also much like to see
a
one-fits-all micromobility/QoS extension set but since this might be
non-trivial to
achieve, the next best thing would be to be able to negotiate what kind of
micro-mobility
extensions are in use. This might or might not need some API definitions,
depending on the extensions/technology used (key operations, network-layer
entity
calibration to some link-information, etc.). Rather, I would imagine a
Mobile IP
protocol handshake (flags?) identifying the micro-mobility extension(s)
supported.
These extensions should be kept as simple as possible.

OTOH, if a one-fits-all solution is searched, there might be a need for
careful
identification of both the terms and goals of micro-mobility, as well as the
least
common denominators among used technologies and how these provide or assist
in
reaching the goals sought for.

regards,

Jari Malinen,
Nokia Research Center, Finland.

> -----Original Message-----
> From: EXT Andrew T. Campbell [mailto:campbell@comet.columbia.edu]
> Sent: 04. March 2000 5:42
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP]
> charter update?)
>
>
> I agree with Charlie on decoupling for QOS.
>
> IP is link independent as Mobile IP is.
>
> When a QOS model is developed out for Mobile IP (e.g.,
> wireless DiffServ) on could imagine mapping to the radio link
> via issll type techniques via some open API that
> provides quality indicators for handoff (SNR, etc.)
> and for resource allocation.
>
> But to make Mobile IP dependent on that API is
> a NOP.
>
> Andrew
>
>
>
> "Charles E. Perkins" wrote:
> >
> > Hello Thomas and Alessio and Basavaraj,
> >
> > >>> Mobile IP's access independence characteristic makes it
> so viable.
> > >>> So there's not much to be said for IP mobility support
> over specific
> > >>> access technologies as you propose.
> >
> > >> I'm not so sure about this as you are. I just say
> > >> IP itself is technology indep., but if you
> > >> want to support intserv there is for instance an ISSLOW spec,
> > >> an ISATM spec, and a spec on how to support
> > >> Qos on 802.x stuff.
> >
> > > Since I work with this as well I could not agree more...
> > > It is very important to map the link characteristics to
> the mobility
> > > management (which in our case is IP based) in order to
> make it efficient...
> >
> > But whether it is important depends on the link.  For some or maybe
> > most links, Mobile IP works great without any changes.  And a lot
> > of the recent discussion about changes to Mobile IP doesn't have
> > anything to do with link characteristics, but more how the link is
> > to be operated because of very high-level policy decisions.
> >
> > I'd rather consider Mobile IP as link-independent, and then engineer
> > specific extensions for particular links when and if they
> are needed.
> >
> > For the specific case of QoS, I reckon that a layer-2 mechanism is
> > required to implement whatever layer-3 allocations have been made
> > (on the basis of whatever application-layer requests have been
> >  fulfilled).  But that is a QoS problem, not a Mobile IP problem.
> >
> > Regards,
> > Charlie P.
>
> --
> Andrew
> http://comet.columbia.edu/~campbell
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 04:18:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01146
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 04:18:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.763D4D30@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:14:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74310 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:13:17 -0500
Received: from jm2.epitest.fi (194.241.248.126) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.4C05CE70@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:13:16
          -0500
Received: (qmail 7811 invoked by uid 500); 6 Mar 2000 09:17:00 -0000
References: <200003052104.NAA08557@antley.eng.sun.com>
            <200003060731.XAA27525@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
Message-ID:  <20000306111700.A7527@jm.epitest.fi>
Date:         Mon, 6 Mar 2000 11:17:00 +0200
Reply-To: Jouni Malinen <jkmaline@CC.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jouni Malinen <jkmaline@CC.HUT.FI>
Subject:      Re: [MOBILE-IP] Vendor Specific Extensions draft
X-To:         Gopal Dommety <gdommety@CISCO.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003060731.XAA27525@omega.cisco.com>

On Sun, Mar 05, 2000 at 11:42:39PM -0800, Gopal Dommety wrote:

> In the format of the Vendor Specific Extensions, we are making the
> following change:
>
> Previously Vendor-Type and opaque data were defined. It was
> recommended that the opaque date be encoded as length and value
> pair.
>
> Now Vendor-Type, Vendor-Lenght, and Vendor-Value are defined.

Is there a good reason for requiring the vendor extensions to have two
length fields even if they have only one sub-extension? The draft
allows one to use multiple vendor extensions in one message and
multiple sub-extensions within each vendor extension. I think that the
internal structure of the vendor extension is up to the vendor
designing it and I thus liked the possibility to use opaque data
without the requirement for strict formating.


> 2.2. Normal Vendor/Organization Specific Extension (NVSE)
>
>    The format of this extension is as shown below.
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |               Reserved        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                             Vendor/Org-ID                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Vendor-NVSE-Type           | Vendor-Length | Vendor-Data ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Have you some plans for the reserved space in the header? I have been
using multiple NVSEs in a registration message, but these extensions
have only one "sub-extension" and no need for the extra length
field. I would thus like to be able to use something like the
following structure in the extensions (saving three octets):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Vendor-Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor/Org-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Opaque Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


This way I could use sub-extensions, if I wanted, but at least so far
I haven't come up with a reason to add the concept of
sub-extensions. They would, at least, make the parsing of messages a
bit more complicated and I don't see any extra possibilities compared
to multiple vendor extensions. If I need to add a non-vendor-extension
between two sub-extensions, I would anyway have to separate them in
two vendor extensions. Do you have some examples, in which the
sub-extensions would be more convenient?

--
Jouni Malinen


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 04:22:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01177
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 04:22:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BDE78DD0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:16:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74294 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:14:33 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.13BB3650@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:04:32
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF50@monza.broadswitch.com>
Date:         Mon, 6 Mar 2000 10:08:10 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

But the mobility management is NOT independent of the access network if you
want it optimized...
/Thomas

> -----Original Message-----
> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]
> Sent: Friday, March 03, 2000 5:03 PM
> To: thomas.eklund@SWITCHCORE.COM;
> MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: [MOBILE-IP] Terminology (was: [MOBILE-IP]
> charter update?)
>
>
>
> >> >A spinoff of the MIP WG, say  MIPSAT WG
> >> >(IP mobility support over Specific Access Technologies)
> >> >would probably be a good thing, accommodating
> >> >any need to address specific problems that
> >> >MIP is considered not sufficient to address over
> >> >specific access Technologies. Also this would
> >> >come with the benefit of providing a well defined
> >> >scope for each new proposal coming in.
> >> >
> >>
> >> Mobile IP's access independence characteristic makes it so viable.
> >> So there's not much to be said for IP mobility support
> over specific
> >> access technologies as you propose.
> >
> >I definitatly not agree here.. It is very important to
> optimize the IP
> >transport (doen in Robust Header Compression WG), mobility
> management over
> >specific link layers, especially over different radio link
> layers because
> >they have very special charateristics that needs to be
> adapted to in order
> >to make it efficient...
> >
>
> The ROHC BOF/WG aims to optimize IP transport via compression or
> stripping of headers over the air interface. And because of the
> limited spectrum it needs to be efficient. But what does mobility and
> handoffs have to do with that? How you handle IP transport over
> specific access types and link layers is independent of mobility
> management (well at least to some extent).
>
> -Basavaraj
>
> >
> >/Thomas
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 04:47:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01382
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 04:47:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.232C5C40@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:40:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74430 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:39:40 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.96136890@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:29:39
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF52@monza.broadswitch.com>
Date:         Mon, 6 Mar 2000 10:33:14 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "campbell@comet.columbia.edu" <campbell@comet.columbia.edu>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Well I speak about IP based mobility not mobileIP... We all know what mobile
ip is best for and what is not...

We where originally speaking about that mobile IP is not enough to solve the
mobility management...

We need clearer interfaces and I  posted a network arhitechure, which Pat
also agreed on, what we name it is irrellevant...

But what we need is clear interfaces so we can extend the mobility
management in the future....
The 4 levels that we discussed is tighhtly closed to how it looks in the
network today...

If we have clear interfaces and several layers of course it has also to be
some kind of hierarhical mobility management, but what is more important is
a defined framework for these different levels....

> I agree with Charlie on decoupling for QOS.
Well so do I, I was just speaking about that different links have different
characteristics....

And at the lowest level of a mobility arhictecture framework it should take
the link layer features into characteristics, or at least have the
possibility to do so... The fallback could of course be mobile IP for
operators that is satisfied with that, but my guess is that mobile ip is not
enough over many access networks...
... at least thats my opinion...

>
> IP is link independent as Mobile IP is.
>
> When a QOS model is developed out for Mobile IP (e.g.,
> wireless DiffServ) on could imagine mapping to the radio link
> via issll type techniques via some open API that
> provides quality indicators for handoff (SNR, etc.)
> and for resource allocation.
Agree with you here..:-)

>
> But to make Mobile IP dependent on that API is
> a NOP.
Well if you dont want any advanced policy in your move detection policy it
is up to you....

Best Regards Thomas
>
> Andrew
>
>
>
> "Charles E. Perkins" wrote:
> >
> > Hello Thomas and Alessio and Basavaraj,
> >
> > >>> Mobile IP's access independence characteristic makes it
> so viable.
> > >>> So there's not much to be said for IP mobility support
> over specific
> > >>> access technologies as you propose.
> >
> > >> I'm not so sure about this as you are. I just say
> > >> IP itself is technology indep., but if you
> > >> want to support intserv there is for instance an ISSLOW spec,
> > >> an ISATM spec, and a spec on how to support
> > >> Qos on 802.x stuff.
> >
> > > Since I work with this as well I could not agree more...
> > > It is very important to map the link characteristics to
> the mobility
> > > management (which in our case is IP based) in order to
> make it efficient...
> >
> > But whether it is important depends on the link.  For some or maybe
> > most links, Mobile IP works great without any changes.  And a lot
> > of the recent discussion about changes to Mobile IP doesn't have
> > anything to do with link characteristics, but more how the link is
> > to be operated because of very high-level policy decisions.
> >
> > I'd rather consider Mobile IP as link-independent, and then engineer
> > specific extensions for particular links when and if they
> are needed.
> >
> > For the specific case of QoS, I reckon that a layer-2 mechanism is
> > required to implement whatever layer-3 allocations have been made
> > (on the basis of whatever application-layer requests have been
> >  fulfilled).  But that is a QoS problem, not a Mobile IP problem.
> >
> > Regards,
> > Charlie P.
>
> --
> Andrew
> http://comet.columbia.edu/~campbell
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 04:47:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01385
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 04:47:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B5765A0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:42:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74431 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:41:09 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CB9957E0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:31:09
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF53@monza.broadswitch.com>
Date:         Mon, 6 Mar 2000 10:34:49 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > Seem okay?
>
> not really. AAA is one way to facilitate deployment of Mobile
> IP, but not fast
> hand-off, IMHO. This is really new work, and although we
> could conceal it
> under a variety of existing work items in the charter, I
> think that we should
> specifically spell out that we will develop a scheme to
> provide fast hand-off
> at the IP layer. Please note, however, that we *may* find
> that there are
> optimizations that can be done for specific link layers, and
> if we decide that
> hand-offs is a work item that we want to take on, we will get
> into link layer
> issues. A one-size fits all may not apply here.
This is EXACTLY my point here as well...

I agree with you, on this....

/Thomas




>
> PatC
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 04:56:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01460
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 04:56:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3FA1A90@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:51:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74498 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:51:20 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.375D4670@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:41:19
          -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8750.A54B5CBA"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF55@monza.broadswitch.com>
Date:         Mon, 6 Mar 2000 10:44:54 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF8750.A54B5CBA
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Hesham,
it is not a discusion about hierarchical mobile IP..
It is a discussion about defining clearer interfaces than today, and to
achieve this of course you need a hierarchical mobility management...
But the issues is that we need a good ip based mobility frameworks with
clear interfaces so new technologies, access network etc.. could be easy
integrated..

Cheers Thomas


-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU]
Sent: Sunday, March 05, 2000 10:37 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)



Hi Pat

        Why is Hierarchical Mobile IP not included here? Mobile IP can be
used to
provide micro mobility. The reason is because some people's definition of
micro mobility is vastly different from others. Hence the reason why I want
to
move *away* from these terms, and create something new that is very well
defined.

        PatC

        Absolutely, we have a draft adressing exactly that (HMIP) for both
V4 and V6.

        Hesham


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=508294109-06032000>Hi
Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=508294109-06032000>it is
not a discusion about hierarchical mobile IP..</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=508294109-06032000>It is
a discussion about defining clearer interfaces than today, and to achieve this
of course you need a hierarchical mobility management...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=508294109-06032000>But
the issues is that we need a good ip based mobility frameworks with clear
interfaces so new technologies, access network etc.. could be easy
integrated..</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=508294109-06032000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=508294109-06032000>Cheers
Thomas</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=508294109-06032000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA)
  [mailto:Hesham.Soliman@ERICSSON.COM.AU]<BR><B>Sent:</B> Sunday, March 05, 2000
  10:37 AM<BR><B>To:</B>
  MOBILE-IP@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Re: [MOBILE-IP]
  Terminology (was: [MOBILE-IP] charter update?)<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face=Arial size=2>Hi Pat</FONT> </P>
  <UL>
    <P><FONT face=Arial size=2>Why is Hierarchical Mobile IP not included here?
    Mobile IP can be used to</FONT> <BR><FONT face=Arial size=2>provide micro
    mobility. The reason is because some people's definition of</FONT> <BR><FONT
    face=Arial size=2>micro mobility is vastly different from others. Hence the
    reason why I want to</FONT> <BR><FONT face=Arial size=2>move *away* from
    these terms, and create something new that is very well</FONT> <BR><FONT
    face=Arial size=2>defined.</FONT> </P>
    <P><FONT face=Arial size=2>PatC</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Absolutely, we have a draft
    adressing exactly that (HMIP) for both V4 and V6.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT>
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF8750.A54B5CBA--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 05:05:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01573
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 05:05:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8EA4ED0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 5:01:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74695 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:59:21 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BC08FB10@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:59:21
          -0500
Received: from gdommety-pc2 (gdommety-dsl2.cisco.com [10.19.17.139]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          CAA07895; Mon, 6 Mar 2000 02:02:33 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <200003060731.XAA27525@omega.cisco.com>
            <200003052104.NAA08557@antley.eng.sun.com>
            <200003060731.XAA27525@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003061002.CAA07895@omega.cisco.com>
Date:         Mon, 6 Mar 2000 02:13:56 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] Vendor Specific Extensions draft
X-To:         Jouni Malinen <jkmaline@CC.HUT.FI>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000306111700.A7527@jm.epitest.fi>

Jouni:

I too prefer the opaque data type.  There was a comment from IESG to look into
strict typing. Since there was strict typing, I saw no reason not to have multiple sub-extension.
 I did send them a reply stating my preference for leaving it opaque. They came back with the
same suggestion.


At 11:17 AM 06/03/00 +0200, Jouni Malinen wrote:
>On Sun, Mar 05, 2000 at 11:42:39PM -0800, Gopal Dommety wrote:
>
>> In the format of the Vendor Specific Extensions, we are making the
>> following change:
>>
>> Previously Vendor-Type and opaque data were defined. It was
>> recommended that the opaque date be encoded as length and value
>> pair.
>>
>> Now Vendor-Type, Vendor-Lenght, and Vendor-Value are defined.
>
>Is there a good reason for requiring the vendor extensions to have two
>length fields even if they have only one sub-extension? The draft
>allows one to use multiple vendor extensions in one message and
>multiple sub-extensions within each vendor extension. I think that the
>internal structure of the vendor extension is up to the vendor
>designing it and I thus liked the possibility to use opaque data
>without the requirement for strict formating.
>
>
>> 2.2. Normal Vendor/Organization Specific Extension (NVSE)
>>
>>    The format of this extension is as shown below.
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Type      |    Length     |               Reserved        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                             Vendor/Org-ID                     |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |    Vendor-NVSE-Type           | Vendor-Length | Vendor-Data ...
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>Have you some plans for the reserved space in the header? I have been

Nothing that I can think of. We left it to align. If we do not have multiple sub-extensions
in a extensions, we have the format as you suggested (only for logical seperation we might
prefer to leave it alone). But I agree about the usage of two extra bytes.



>using multiple NVSEs in a registration message, but these extensions
>have only one "sub-extension" and no need for the extra length
>field. I would thus like to be able to use something like the
>following structure in the extensions (saving three octets):
>



>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |     Type      |    Length     |          Vendor-Type          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Vendor/Org-ID                           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Opaque Data ...
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>This way I could use sub-extensions, if I wanted, but at least so far
>I haven't come up with a reason to add the concept of
>sub-extensions. They would, at least, make the parsing of messages a
>bit more complicated and I don't see any extra possibilities compared
>to multiple vendor extensions. If I need to add a non-vendor-extension
>between two sub-extensions, I would anyway have to separate them in
>two vendor extensions. Do you have some examples, in which the
>sub-extensions would be more convenient?
>
>--
>Jouni Malinen
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 07:27:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03173
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 07:27:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DCB76FE0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 7:23:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 74969 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 07:21:27 -0500
Received: from igw1.ericsson.com.au by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.95A354C0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 7:21:26
          -0500
Received: from brsi02.epa.ericsson.se ([146.11.15.8]) by igw1.ericsson.com.au
          (8.9.1b+Sun/8.9.1) with ESMTP id XAA25589; Mon, 6 Mar 2000 23:25:03
          +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA28404; Mon, 6
          Mar 2000 23:25:36 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0)
          id <GD47GSLH>; Mon, 6 Mar 2000 23:25:00 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8766.FDCAC8C4"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50185D755@eaubrnt018.epa.ericsson.se>
Date:         Mon, 6 Mar 2000 23:25:00 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
X-To:         Thomas Eklund <thomas.eklund@switchcore.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF8766.FDCAC8C4
Content-Type: text/plain

Hi Thomas,

I was just agreeing specifically with the statement that Pat made about
considering HMIP as a possible candidate for the "micro-mobility" management
amongst other proposals.

I used "micro-mobility" until the WG defines a more accurate term ;)

Cheers,
Hesham

> -----Original Message-----
> From: Thomas Eklund [SMTP:thomas.eklund@switchcore.com]
> Sent: Monday, 6 March 2000 8:45
> To:   'Hesham Soliman (EPA)'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter
> update?)
>
> Hi Hesham,
> it is not a discusion about hierarchical mobile IP..
> It is a discussion about defining clearer interfaces than today, and to
> achieve this of course you need a hierarchical mobility management...
> But the issues is that we need a good ip based mobility frameworks with
> clear interfaces so new technologies, access network etc.. could be easy
> integrated..
>
> Cheers Thomas
>
>
>       -----Original Message-----
>       From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU]
>       Sent: Sunday, March 05, 2000 10:37 AM
>       To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>       Subject: Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter
> update?)
>
>
>
>       Hi Pat
>
>               Why is Hierarchical Mobile IP not included here? Mobile IP
> can be used to
>       provide micro mobility. The reason is because some people's
> definition of
>       micro mobility is vastly different from others. Hence the reason why
> I want to
>       move *away* from these terms, and create something new that is very
> well
>       defined.
>
>               PatC
>
>               Absolutely, we have a draft adressing exactly that (HMIP)
> for both V4 and V6.
>
>               Hesham
>

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

<!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.2644.0">
<TITLE>RE: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter =
update?)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Thomas,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I was just agreeing =
specifically with the statement that Pat made about considering HMIP as =
a possible candidate for the &quot;micro-mobility&quot; management =
amongst other proposals. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I used =
&quot;micro-mobility&quot; until the WG defines a more accurate term =
;)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thomas Eklund =
[SMTP:thomas.eklund@switchcore.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, 6 March 2000 8:45</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Hesham Soliman (EPA)'; =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [MOBILE-IP] Terminology (was: =
[MOBILE-IP] charter update?)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Hesham,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">it is not a =
discusion about hierarchical mobile IP..</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It is a discussion =
about defining clearer interfaces than today, and to achieve this of =
course you need a hierarchical mobility management...</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But the issues is =
that we need a good ip based mobility frameworks with clear interfaces =
so new technologies, access network etc.. could be easy =
integrated..</FONT></P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers =
Thomas</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Hesham Soliman (EPA) [</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:Hesham.Soliman@ERICSSON.COM.AU">mailto:Hesham.Soliman@ERI=
CSSON.COM.AU</A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Sunday, March 05, 2000 10:37 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> MOBILE-IP@STANDARDS.NORTELNETWORKS.COM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] =
charter update?)<BR>
<BR>
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Pat</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Why is Hierarchical Mobile IP not included here? Mobile =
IP can be used to</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">provide micro mobility. The reason =
is because some people's definition of</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">micro mobility is vastly different =
from others. Hence the reason why I want to</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">move *away* from these terms, and =
create something new that is very well</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">defined.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">PatC</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Absolutely, we have a draft adressing exactly =
that (HMIP) for both V4 and V6.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Hesham</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01BF8766.FDCAC8C4--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 08:58:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06184
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 08:58:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76E477F0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 8:53:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75116 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 08:53:04 -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FCB373B0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 8:43:04
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA06713; Mon, 6 Mar
          2000 15:46:45 +0200 (EET)
Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76])
          by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA07796; Mon, 6
          Mar 2000 15:46:40 +0200 (EET)
Received: from possu.research.nokia.com (possu.research.nokia.com
          [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP
          id PAA07885; Mon, 6 Mar 2000 15:46:40 +0200 (EET)
Received: from localhost (asokan@localhost) by possu.research.nokia.com
          (8.9.1/8.9.1) with ESMTP id PAA11908; Mon, 6 Mar 2000 15:46:39 +0200
          (EET)
X-Authentication-Warning: possu.research.nokia.com: asokan owned process doing
                         -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GS4.4.10.10003061315300.687-100000@possu.research.nokia.com>
Date:         Mon, 6 Mar 2000 15:46:39 +0200
Reply-To: n.asokan@nokia.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "N. Asokan" <n.asokan@nokia.com>
Subject:      [MOBILE-IP] Generalized key distribution exts. draft
X-cc:         charlie@research.nokia.com, Pat Calhoun <pcalhoun@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charlie and Pat,

In draft-ietf-mobileip-gen-key-00.txt, the MN-FA Key Reply Extension does
not have a lifetime field.  I realize that there was some discussion on
this topic and the conclusion was that MN-FA key can be considered valid
as long as the MN resides in the visited domain.

This would be a valid assumption if the AAA authorization and Mobile IP
registration are tightly coupled.  But they may not be.  In this case, the
validity of the AAA authorization can be different from the validity of
the home registration.  We need a way to force the MN to authorize itself
again and obtain a new MN-FA key (or extend the lifetime of the current
MN-FA key).

So, I request an MN-FA Key Reply Extension with a lifetime field in it.

Thanks and regards,
- Asokan

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 09:10:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06624
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 09:10:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27C56C90@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:05:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75207 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 09:04:16 -0500
Received: from homebase.htt-consult.com (63.82.18.210) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F2C04600@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:04:15
          -0500
Received: from rgm ([207.155.230.79]) by homebase.htt-consult.com ; Mon, 06 Mar
          2000 09:08:29 -0500
X-Sender: rgm-ietf@homebase.htt-consult.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.0.58.20000306075308.03680990@homebase.htt-consult.com>
Date:         Mon, 6 Mar 2000 06:56:50 -0500
Reply-To: Robert Moskowitz <rgm-ietf@HTT-CONSULT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Robert Moskowitz <rgm-ietf@HTT-CONSULT.COM>
Subject:      Re: [MOBILE-IP] Reminder:  San Jose -- IPv6 Wireless and Mobility
              Roundtable
X-To:         Carl Williams <carlw@antley.eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003042302.PAA07118@antley.eng.sun.com>

At 03:02 PM 3/4/2000 -0800, Carl Williams wrote:
>Reminder:  The wireless and mobility roundtable
>is this Monday from 4:00pm-6:00pm at the Crowne Plaza
>Hotel in downtown San Jose, CA.  This event
>is open to everyone. No need to register.

ARGH!!!


Here I am, flying to a PKI meeting in Foster City, and will not be able to
'get away' so easily.  Plus I did not get a rental car, so even coming down
for the evening is not easy.  :(

Well, you will be challenged to do much of what you want to accomplish if
we don't fix the PKI arena, so one nibble at a time.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 09:28:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07122
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 09:28:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0A220B0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:23:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75263 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 09:22:17 -0500
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.112DED30@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:12:16
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Mar  6
          09:14:31 EST 2000
Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean
          [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with
          ESMTP id JAA02596; Mon, 6 Mar 2000 09:14:30 -0500 (EST)
Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id
          JAA06542; Mon, 6 Mar 2000 09:14:30 -0500
Mail-Followup-To: "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>,
                  MOBILE-IP@standards.nortelnetworks.com
References: <51F347B016ADD011963200805FC1456204BCC082@email1.wes.mot.com>
            <Roam.SIMC.2.0.6.952133805.13083.pcalhoun@ha1mpk-mail>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: Linux 2.2.12-20
X-Organization: Lucent Technologies, Bell Laboratories
Message-ID:  <20000306091430.N19788@bell-labs.com>
Date:         Mon, 6 Mar 2000 09:14:30 -0500
Reply-To: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Luca Salgarelli <lsalgarelli@BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         "pcalhoun@eng.sun.com" <pcalhoun@ha1mpk-mail.Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <Roam.SIMC.2.0.6.952133805.13083.pcalhoun@ha1mpk-mail>; from
              pcalhoun@ha1mpk-mail.Eng.Sun.COM on Fri, Mar 03,
              2000 at 05:36:45PM -0800

Hi Pat.

On Fri, Mar 03, 2000 at 05:36:45PM -0800, pcalhoun@eng.sun.com wrote:
> not really. AAA is one way to facilitate deployment of Mobile IP, but not fast
> hand-off, IMHO. This is really new work, and although we could conceal it
> under a variety of existing work items in the charter, I think that we should
> specifically spell out that we will develop a scheme to provide fast hand-off
> at the IP layer.

I do not agree with the fact that optimizations to RFC2002 for supporting
fast handoffs is new work. I think there have been plenty of proposals,
starting with all the drafts on hierarchical FAs, to Cellular IP, and to
HAWAII. I guess a lot of work has been done on these proposals, and I would
rather say that they have reached a certain stage of maturity.

> Please note, however, that we *may* find that there are
> optimizations that can be done for specific link layers, and if we decide that
> hand-offs is a work item that we want to take on, we will get into link layer
> issues. A one-size fits all may not apply here.

I also do not agree on this: every optimization for fast handoff proposed
so far has been designed to work regardless of the underlying link-layer.

I think that RFC2002 offers a very good base protocol for mobility
management, but we all know a few of its shortcomings, e.g. when the HA is
several hops away from the visited network, and the user changes FA very
often. I think that the three proposal above address very well this issue,
with different pros and cons, without introducing any link-layer
dependency.

Therefore I think that the working group should work on these proposals,
harmonizing them, and coming up with a common approach to extend RFC2002 in
order for Mobile-IP to be able to support fast-handoffs.

Regards
Luca


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 09:41:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07583
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 09:41:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.857F93C0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:37:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75344 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 09:35:04 -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DA5B47B0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 9:25:03
          -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AF5F@monza.broadswitch.com>
Date:         Mon, 6 Mar 2000 15:28:42 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Reminder:  San Jose -- IPv6 Wireless and Mobility
              Roundtable
X-To:         Robert Moskowitz <rgm-ietf@HTT-CONSULT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Well since IP sec i mandatory for IPv6 so the mechanism to obtain a quality
PKI infrastructure are there...

Then how people agree on the policies (AAA on one side and PKI or even SPKI
on the other) is the big problem and tends to involve a lot of politics...

But the way I see it - the sooner IPv6 come, the better for a PKI based
infrastrucure....

Best Regards Thomas

> -----Original Message-----
> From: Robert Moskowitz [mailto:rgm-ietf@HTT-CONSULT.COM]
> Sent: Monday, March 06, 2000 12:57 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Reminder: San Jose -- IPv6 Wireless and
> Mobility Roundtable
>
>
> At 03:02 PM 3/4/2000 -0800, Carl Williams wrote:
> >Reminder:  The wireless and mobility roundtable
> >is this Monday from 4:00pm-6:00pm at the Crowne Plaza
> >Hotel in downtown San Jose, CA.  This event
> >is open to everyone. No need to register.
>
> ARGH!!!
>
>
> Here I am, flying to a PKI meeting in Foster City, and will
> not be able to
> 'get away' so easily.  Plus I did not get a rental car, so
> even coming down
> for the evening is not easy.  :(
>
> Well, you will be challenged to do much of what you want to
> accomplish if
> we don't fix the PKI arena, so one nibble at a time.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 10:33:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10040
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 10:33:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D69C7BE0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 10:29:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75654 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 10:27:38 -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.327DFA30@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          10:17:37 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          JAA13663; Mon, 6 Mar 2000 09:20:37 -0600 (CST)
X-Sender: "Vincent Magret" <magrvi@eagle.aud.alcatel.com> (Unverified)
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <CE835E918749D21191B10060084C377E01B5DEB7@ismail1.icomverse.com>
Content-Type: multipart/mixed; boundary="------------29E561C920D62B4029DF466B"
Message-ID:  <38C0E966.3356FC2D@usa.alcatel.com>
Date:         Sat, 4 Mar 2000 04:45:58 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------29E561C920D62B4029DF466B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

I don't get the point of taking into account the WAP. The WAP architecture
relies on IP and does not make any requirements regarding IP mobility.

Vincent.

"Klein, Eric" wrote:

> All,
>
> I would have to agree with Pat and Mark, today the biggest push for
> mobile-IP will be the cellular market. What we need to take into account is
> both cellular data and WAP applications. This is a real hot topic right now
> with Microsoft, AOL, and Yahoo trying to take the dominate position for
> configuration and portals. These areas are now in the same stage that BBS'
> were 10 years ago with different rules and speeds. As these all will be
> using some form of IP we should look at a way to integrate all of them into
> both the charter and the final recommendations and standards.
>
>   Eric Klein
>   Network Specialist
>   star*home, a Comverse Company
>
>   Phone:  +972 (3) 765-5793
>   Cell:    +972 (51) 232-375
>   Fax:    +972 (3) 765-5688
>   Email:   eric_klein@starhome.com
>   Web:    http:/www.starhome.com
>
> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> Sent: Wednesday, March 01, 2000 3:56 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
> All,
>
> I find it difficult to justify NOT updating the draft to include cellular
> specific extensions. As many of you know, Mobile IP has been in RFC form for
> quite some time now, and until the cellular folks decided to adopt it, we
> really didn't have much deployment. If cellular is the killer Mobile IP
> service, then we should do what we can to help make Mobile IP successful.
>
> PatC
>
> > I think the charter should be updated to support cellular specific
> > extensions.
> >
> > Mark A. Lipford
> > Manager, Wireless Industry Standards - Data
> > Sprint PCS
> > 8001 College Blvd.; Suite 210
> > Overland Park, KS  66210
> > (913) 664-8335 (office)
> > (913) 664-8440 (fax)
> > (913) 226-9060 (PCS)
> >
> >
> > -----Original Message-----
> > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > Sent: Tuesday, February 29, 2000 5:14 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: [MOBILE-IP] charter update?
> >
> >
> > Greetings gentlepeople,
> >
> >     We've got 4 presentations lined up at the Adelaide meeting on various
> > proposals for handoff.  This together with the fact that several of our
> > current drafts are motivated by 3G data support indicates to Raj and me
> that
> > there continues to be some interest in the group in supporting cellular
> > specific extensions to mobile-ip.  The charter doesn't specify a strong
> > support of these activities.  The current wording is "The WG moving
> forward
> > will focus on deployment issues in Mobile IP and provide appropriate
> > protocol solutions to address known deficiencies and shortcomings. For
> > example, the wireless/cellular industry is considering using Mobile IP as
> > one technique for IP mobility for wireless data. The working group will
> > endeavor to gain an understanding of data service in cellular systems such
> > as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
> > trying to adopt and deploy Mobile IP WG protocols in these contexts."
> > So I'd like to find out whether there is interest in the group to
> extending
> > the charter for specific support of cellular systems.  If there is general
> > support I'll propose some wording.  One obvious work item would be to
> submit
> > a draft to the IESG for support of fast handover.
> >
> > Comments?
> > Phil

--------------29E561C920D62B4029DF466B
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincent.magret.vcf"
Content-Description: Card for Vincent Magret
Content-Disposition: attachment;
 filename="vincent.magret.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Magret;Vincent
tel;fax:+1 972 996 5902
tel;work:+1 972 996 2625
x-mozilla-html:FALSE
version:2.1
email;internet:vincent.magret@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA
fn:Vincent Magret
end:vcard

--------------29E561C920D62B4029DF466B--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 10:37:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10262
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 10:37:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F07E9A0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 10:31:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75667 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 10:31:09 -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B06CE640@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          10:21:09 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          JAA13719; Mon, 6 Mar 2000 09:23:37 -0600 (CST)
X-Sender: "Vincent Magret" <magrvi@eagle.aud.alcatel.com> (Unverified)
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <Roam.SIMC.2.0.6.951922697.17324.pcalhoun@ha1mpk-mail>
Content-Type: multipart/mixed; boundary="------------B4E89E7AE3E4D3AB6EEA8835"
Message-ID:  <38C0FD84.EEB22E0B@usa.alcatel.com>
Date:         Sat, 4 Mar 2000 06:11:49 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------B4E89E7AE3E4D3AB6EEA8835
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hello,

I would agree that "cellular" is simply an illustration. Designs based on 802.11
or Hiperlan-2 may require similar features to support micro mobility.


Vincent.
"pcalhoun@eng.sun.com" wrote:

> Emad,
>
> I used the cellular terminology loosely to provide an example of what each of
> the terms would mean. Certainly these could be applied to other networks. As
> an example, say using Hierarchical Mobile-IP, one could design a 802.11-based
> service that provides all of the examples below (of course, that would
> requires lots of bridges :) If the network was flat (no Hierarchical Mobile
> IP), the second bullet wouldn't be used.
>
> PatC
>
> > Pat,
> >
> > ....
> >
> > > So, I would like to propose that we agree on some new
> > > terminology. I believe
> > > that we have: - Link Layer Mobility (Inter-BTS hand-off)
> > > - pick a name Mobility (inter-BSC hand-off)
> > > - Intra-Domain Mobility (Inter-MSC hand-off)
> > > - Inter-Domain Mobility (when the hand-off crosses a domain boundary)
> > >
> >
> > So are these the only mobility related technology that MIP should be
> > applied/used for?
> >
> > > I still don't have a preference for the second name, and I am
> > > not married to
> > > ANY of the names above. These are merely suggestions. The
> > > goal here is to ALL
> > > agree on basic terminology so that when we compare protocols,
> > > we can match the
> > > protocol against a set of common terminology.
> > >
> > > Comments? Is this a worthwhile exercise?
> >
> > The objective of agreeing on terminology is great. However, if we go this
> > specific to cellular, I may be the only one suggesting renaming the MIP WG
> > to "MIP For Cellular".
> >
> > >
> > > PatC
> > >

--------------B4E89E7AE3E4D3AB6EEA8835
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincent.magret.vcf"
Content-Description: Card for Vincent Magret
Content-Disposition: attachment;
 filename="vincent.magret.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Magret;Vincent
tel;fax:+1 972 996 5902
tel;work:+1 972 996 2625
x-mozilla-html:FALSE
version:2.1
email;internet:vincent.magret@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA
fn:Vincent Magret
end:vcard

--------------B4E89E7AE3E4D3AB6EEA8835--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 10:43:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10516
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 10:43:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41793EC0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 10:39:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75805 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 10:38:25 -0500
Received: from mailgw2.netvision.net.il (194.90.1.9) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.18707C00@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          10:38:22 -0500
Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il
          [199.203.174.65]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with
          ESMTP id RAA18176 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon,
          6 Mar 2000 17:42:01 +0200 (IST)
Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2]) by
          sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id RAA30183 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Mar 2000 17:42:30
          +0200
Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id
          <1RMLN6L4>; Mon, 6 Mar 2000 17:41:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <CE835E918749D21191B10060084C377E01B5E035@ismail1.icomverse.com>
Date:         Mon, 6 Mar 2000 17:41:58 +0200
Reply-To: "Klein, Eric" <Eric_Klein@STARHOME.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Klein, Eric" <Eric_Klein@STARHOME.COM>
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Vincent,

I disagree. I have been doing a lot of work lately on WAP, and there is no
standard currently for roaming using WAP. These users would need to have a
mobile IP address that would be valid on the visited network, while still
being valid for retrieval and security based access on their home network.

Right now the GSM Association is proposing one solution and the WAP Forum is
proposing a different one. We need to have something flexible enough to
handle single carriers with a million or more users.

Eric

-----Original Message-----
From: Vincent Magret [mailto:vincent.magret@USA.ALCATEL.COM]
Sent: Saturday, March 04, 2000 12:46 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] charter update?


Hello,

I don't get the point of taking into account the WAP. The WAP architecture
relies on IP and does not make any requirements regarding IP mobility.

Vincent.

"Klein, Eric" wrote:

> All,
>
> I would have to agree with Pat and Mark, today the biggest push for
> mobile-IP will be the cellular market. What we need to take into account
is
> both cellular data and WAP applications. This is a real hot topic right
now
> with Microsoft, AOL, and Yahoo trying to take the dominate position for
> configuration and portals. These areas are now in the same stage that BBS'
> were 10 years ago with different rules and speeds. As these all will be
> using some form of IP we should look at a way to integrate all of them
into
> both the charter and the final recommendations and standards.
>
>   Eric Klein
>   Network Specialist
>   star*home, a Comverse Company
>
>   Phone:  +972 (3) 765-5793
>   Cell:    +972 (51) 232-375
>   Fax:    +972 (3) 765-5688
>   Email:   eric_klein@starhome.com
>   Web:    http:/www.starhome.com
>
> -----Original Message-----
> From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> Sent: Wednesday, March 01, 2000 3:56 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
> All,
>
> I find it difficult to justify NOT updating the draft to include cellular
> specific extensions. As many of you know, Mobile IP has been in RFC form
for
> quite some time now, and until the cellular folks decided to adopt it, we
> really didn't have much deployment. If cellular is the killer Mobile IP
> service, then we should do what we can to help make Mobile IP successful.
>
> PatC
>
> > I think the charter should be updated to support cellular specific
> > extensions.
> >
> > Mark A. Lipford
> > Manager, Wireless Industry Standards - Data
> > Sprint PCS
> > 8001 College Blvd.; Suite 210
> > Overland Park, KS  66210
> > (913) 664-8335 (office)
> > (913) 664-8440 (fax)
> > (913) 226-9060 (PCS)
> >
> >
> > -----Original Message-----
> > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > Sent: Tuesday, February 29, 2000 5:14 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: [MOBILE-IP] charter update?
> >
> >
> > Greetings gentlepeople,
> >
> >     We've got 4 presentations lined up at the Adelaide meeting on
various
> > proposals for handoff.  This together with the fact that several of our
> > current drafts are motivated by 3G data support indicates to Raj and me
> that
> > there continues to be some interest in the group in supporting cellular
> > specific extensions to mobile-ip.  The charter doesn't specify a strong
> > support of these activities.  The current wording is "The WG moving
> forward
> > will focus on deployment issues in Mobile IP and provide appropriate
> > protocol solutions to address known deficiencies and shortcomings. For
> > example, the wireless/cellular industry is considering using Mobile IP
as
> > one technique for IP mobility for wireless data. The working group will
> > endeavor to gain an understanding of data service in cellular systems
such
> > as GPRS, UMTS, CDMA2000, and interact with other standards bodies that
are
> > trying to adopt and deploy Mobile IP WG protocols in these contexts."
> > So I'd like to find out whether there is interest in the group to
> extending
> > the charter for specific support of cellular systems.  If there is
general
> > support I'll propose some wording.  One obvious work item would be to
> submit
> > a draft to the IESG for support of fast handover.
> >
> > Comments?
> > Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 11:03:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12205
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 11:03:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE4FD940@standards.nortelnetworks.com>; Mon, 6 Mar 2000 10:58:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75916 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 10:57:45 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CD1C3ED0@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          10:57:44 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 09:55:45 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 6
          Mar 2000 10:55:18 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <GH0WH1BL>; Mon, 6 Mar 2000 09:55:17 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8784.5E0ECF88"
Message-ID:  <F908F961B7CDD111BC720000F8073E4302DD9415@crchy271.us.nortel.com>
Date:         Mon, 6 Mar 2000 09:55:12 -0600
Reply-To: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Emad Qaddoura <emadq@NORTELNETWORKS.COM>
Subject:      Re: [MOBILE-IP] charter update?
X-To:         "Klein, Eric" <Eric_Klein@STARHOME.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF8784.5E0ECF88
Content-Type: text/plain;
        charset="ISO-8859-1"

Eric,


> -----Original Message-----
> From: Klein, Eric [mailto:Eric_Klein@STARHOME.COM]
> Sent: Monday, March 06, 2000 9:42 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
>
> Vincent,
>
> I disagree. I have been doing a lot of work lately on WAP,
> and there is no
> standard currently for roaming using WAP. These users would
> need to have a
> mobile IP address that would be valid on the visited network,
> while still
> being valid for retrieval and security based access on their
> home network.

        Are you proposing MIP solution for WAP mobility? I would agree with
you. Don't see why mobility should be done at WAP or other applications if
it is already handled by MIP.

>
> Right now the GSM Association is proposing one solution and
> the WAP Forum is
> proposing a different one. We need to have something flexible
> enough to
> handle single carriers with a million or more users.
>
> Eric
>
> -----Original Message-----
> From: Vincent Magret [mailto:vincent.magret@USA.ALCATEL.COM]
> Sent: Saturday, March 04, 2000 12:46 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
>
> Hello,
>
> I don't get the point of taking into account the WAP. The WAP
> architecture
> relies on IP and does not make any requirements regarding IP mobility.
>
> Vincent.
>
> "Klein, Eric" wrote:
>
> > All,
> >
> > I would have to agree with Pat and Mark, today the biggest push for
> > mobile-IP will be the cellular market. What we need to take
> into account
> is
> > both cellular data and WAP applications. This is a real hot
> topic right
> now
> > with Microsoft, AOL, and Yahoo trying to take the dominate
> position for
> > configuration and portals. These areas are now in the same
> stage that BBS'
> > were 10 years ago with different rules and speeds. As these
> all will be
> > using some form of IP we should look at a way to integrate
> all of them
> into
> > both the charter and the final recommendations and standards.
> >
> >   Eric Klein
> >   Network Specialist
> >   star*home, a Comverse Company
> >
> >   Phone:  +972 (3) 765-5793
> >   Cell:    +972 (51) 232-375
> >   Fax:    +972 (3) 765-5688
> >   Email:   eric_klein@starhome.com
> >   Web:    http:/www.starhome.com
> >
> > -----Original Message-----
> > From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> > Sent: Wednesday, March 01, 2000 3:56 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: [MOBILE-IP] charter update?
> >
> > All,
> >
> > I find it difficult to justify NOT updating the draft to
> include cellular
> > specific extensions. As many of you know, Mobile IP has
> been in RFC form
> for
> > quite some time now, and until the cellular folks decided
> to adopt it, we
> > really didn't have much deployment. If cellular is the
> killer Mobile IP
> > service, then we should do what we can to help make Mobile
> IP successful.
> >
> > PatC
> >
> > > I think the charter should be updated to support cellular specific
> > > extensions.
> > >
> > > Mark A. Lipford
> > > Manager, Wireless Industry Standards - Data
> > > Sprint PCS
> > > 8001 College Blvd.; Suite 210
> > > Overland Park, KS  66210
> > > (913) 664-8335 (office)
> > > (913) 664-8440 (fax)
> > > (913) 226-9060 (PCS)
> > >
> > >
> > > -----Original Message-----
> > > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > > Sent: Tuesday, February 29, 2000 5:14 PM
> > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > > Subject: [MOBILE-IP] charter update?
> > >
> > >
> > > Greetings gentlepeople,
> > >
> > >     We've got 4 presentations lined up at the Adelaide meeting on
> various
> > > proposals for handoff.  This together with the fact that
> several of our
> > > current drafts are motivated by 3G data support indicates
> to Raj and me
> > that
> > > there continues to be some interest in the group in
> supporting cellular
> > > specific extensions to mobile-ip.  The charter doesn't
> specify a strong
> > > support of these activities.  The current wording is "The
> WG moving
> > forward
> > > will focus on deployment issues in Mobile IP and provide
> appropriate
> > > protocol solutions to address known deficiencies and
> shortcomings. For
> > > example, the wireless/cellular industry is considering
> using Mobile IP
> as
> > > one technique for IP mobility for wireless data. The
> working group will
> > > endeavor to gain an understanding of data service in
> cellular systems
> such
> > > as GPRS, UMTS, CDMA2000, and interact with other
> standards bodies that
> are
> > > trying to adopt and deploy Mobile IP WG protocols in
> these contexts."
> > > So I'd like to find out whether there is interest in the group to
> > extending
> > > the charter for specific support of cellular systems.  If there is
> general
> > > support I'll propose some wording.  One obvious work item
> would be to
> > submit
> > > a draft to the IESG for support of fast handover.
> > >
> > > Comments?
> > > Phil
>

------_=_NextPart_001_01BF8784.5E0ECF88
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!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.2651.65">
<TITLE>RE: [MOBILE-IP] charter update?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric,</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Klein, Eric [<A =
HREF=3D"mailto:Eric_Klein@STARHOME.COM">mailto:Eric_Klein@STARHOME.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, March 06, 2000 9:42 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [MOBILE-IP] charter update?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Vincent,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I disagree. I have been doing a lot of work =
lately on WAP, </FONT>
<BR><FONT SIZE=3D2>&gt; and there is no</FONT>
<BR><FONT SIZE=3D2>&gt; standard currently for roaming using WAP. These =
users would </FONT>
<BR><FONT SIZE=3D2>&gt; need to have a</FONT>
<BR><FONT SIZE=3D2>&gt; mobile IP address that would be valid on the =
visited network, </FONT>
<BR><FONT SIZE=3D2>&gt; while still</FONT>
<BR><FONT SIZE=3D2>&gt; being valid for retrieval and security based =
access on their </FONT>
<BR><FONT SIZE=3D2>&gt; home network.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Are you =
proposing MIP solution for WAP mobility? I would agree with you. Don't =
see why mobility should be done at WAP or other applications if it is =
already handled by MIP.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Right now the GSM Association is proposing one =
solution and </FONT>
<BR><FONT SIZE=3D2>&gt; the WAP Forum is</FONT>
<BR><FONT SIZE=3D2>&gt; proposing a different one. We need to have =
something flexible </FONT>
<BR><FONT SIZE=3D2>&gt; enough to</FONT>
<BR><FONT SIZE=3D2>&gt; handle single carriers with a million or more =
users.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Eric</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Vincent Magret [<A =
HREF=3D"mailto:vincent.magret@USA.ALCATEL.COM">mailto:vincent.magret@USA=
.ALCATEL.COM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, March 04, 2000 12:46 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [MOBILE-IP] charter update?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't get the point of taking into account =
the WAP. The WAP </FONT>
<BR><FONT SIZE=3D2>&gt; architecture</FONT>
<BR><FONT SIZE=3D2>&gt; relies on IP and does not make any requirements =
regarding IP mobility.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Vincent.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Klein, Eric&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I would have to agree with Pat and Mark, =
today the biggest push for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mobile-IP will be the cellular market. =
What we need to take </FONT>
<BR><FONT SIZE=3D2>&gt; into account</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; both cellular data and WAP applications. =
This is a real hot </FONT>
<BR><FONT SIZE=3D2>&gt; topic right</FONT>
<BR><FONT SIZE=3D2>&gt; now</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with Microsoft, AOL, and Yahoo trying to =
take the dominate </FONT>
<BR><FONT SIZE=3D2>&gt; position for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; configuration and portals. These areas are =
now in the same </FONT>
<BR><FONT SIZE=3D2>&gt; stage that BBS'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; were 10 years ago with different rules and =
speeds. As these </FONT>
<BR><FONT SIZE=3D2>&gt; all will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; using some form of IP we should look at a =
way to integrate </FONT>
<BR><FONT SIZE=3D2>&gt; all of them</FONT>
<BR><FONT SIZE=3D2>&gt; into</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; both the charter and the final =
recommendations and standards.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Eric Klein</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Network Specialist</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; star*home, a Comverse =
Company</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Phone:&nbsp; +972 (3) =
765-5793</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Cell:&nbsp;&nbsp;&nbsp; +972 =
(51) 232-375</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Fax:&nbsp;&nbsp;&nbsp; +972 =
(3) 765-5688</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Email:&nbsp;&nbsp; =
eric_klein@starhome.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Web:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http:/www.starhome.com" =
TARGET=3D"_blank">http:/www.starhome.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: pcalhoun@eng.sun.com [<A =
HREF=3D"mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM">mailto:pcalhoun@ha1mpk-=
mail.Eng.Sun.COM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, March 01, 2000 3:56 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: [MOBILE-IP] charter =
update?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I find it difficult to justify NOT =
updating the draft to </FONT>
<BR><FONT SIZE=3D2>&gt; include cellular</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; specific extensions. As many of you know, =
Mobile IP has </FONT>
<BR><FONT SIZE=3D2>&gt; been in RFC form</FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; quite some time now, and until the =
cellular folks decided </FONT>
<BR><FONT SIZE=3D2>&gt; to adopt it, we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; really didn't have much deployment. If =
cellular is the </FONT>
<BR><FONT SIZE=3D2>&gt; killer Mobile IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; service, then we should do what we can to =
help make Mobile </FONT>
<BR><FONT SIZE=3D2>&gt; IP successful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I think the charter should be updated =
to support cellular specific</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extensions.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mark A. Lipford</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Manager, Wireless Industry Standards =
- Data</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sprint PCS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 8001 College Blvd.; Suite 210</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Overland Park, KS&nbsp; 66210</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (913) 664-8335 (office)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (913) 664-8440 (fax)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (913) 226-9060 (PCS)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Roberts Phil-QA3445 [<A =
HREF=3D"mailto:qa3445@EMAIL1.WES.MOT.COM">mailto:qa3445@EMAIL1.WES.MOT.C=
OM</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Tuesday, February 29, 2000 5:14 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: [MOBILE-IP] charter =
update?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Greetings gentlepeople,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; We've got 4 =
presentations lined up at the Adelaide meeting on</FONT>
<BR><FONT SIZE=3D2>&gt; various</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; proposals for handoff.&nbsp; This =
together with the fact that </FONT>
<BR><FONT SIZE=3D2>&gt; several of our</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; current drafts are motivated by 3G =
data support indicates </FONT>
<BR><FONT SIZE=3D2>&gt; to Raj and me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; there continues to be some interest =
in the group in </FONT>
<BR><FONT SIZE=3D2>&gt; supporting cellular</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; specific extensions to =
mobile-ip.&nbsp; The charter doesn't </FONT>
<BR><FONT SIZE=3D2>&gt; specify a strong</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; support of these activities.&nbsp; =
The current wording is &quot;The </FONT>
<BR><FONT SIZE=3D2>&gt; WG moving</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; forward</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; will focus on deployment issues in =
Mobile IP and provide </FONT>
<BR><FONT SIZE=3D2>&gt; appropriate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; protocol solutions to address known =
deficiencies and </FONT>
<BR><FONT SIZE=3D2>&gt; shortcomings. For</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; example, the wireless/cellular =
industry is considering </FONT>
<BR><FONT SIZE=3D2>&gt; using Mobile IP</FONT>
<BR><FONT SIZE=3D2>&gt; as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; one technique for IP mobility for =
wireless data. The </FONT>
<BR><FONT SIZE=3D2>&gt; working group will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; endeavor to gain an understanding of =
data service in </FONT>
<BR><FONT SIZE=3D2>&gt; cellular systems</FONT>
<BR><FONT SIZE=3D2>&gt; such</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; as GPRS, UMTS, CDMA2000, and interact =
with other </FONT>
<BR><FONT SIZE=3D2>&gt; standards bodies that</FONT>
<BR><FONT SIZE=3D2>&gt; are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; trying to adopt and deploy Mobile IP =
WG protocols in </FONT>
<BR><FONT SIZE=3D2>&gt; these contexts.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So I'd like to find out whether there =
is interest in the group to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; extending</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the charter for specific support of =
cellular systems.&nbsp; If there is</FONT>
<BR><FONT SIZE=3D2>&gt; general</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; support I'll propose some =
wording.&nbsp; One obvious work item </FONT>
<BR><FONT SIZE=3D2>&gt; would be to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; submit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a draft to the IESG for support of =
fast handover.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Comments?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Phil</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF8784.5E0ECF88--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 11:14:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12644
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 11:14:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7AE0D840@standards.nortelnetworks.com>; Mon, 6 Mar 2000 11:09:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 75935 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 11:08:54 -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F6AA8540@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          10:58:54 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          KAA14418; Mon, 6 Mar 2000 10:02:28 -0600 (CST)
X-Sender: "Vincent Magret" <magrvi@eagle.aud.alcatel.com>
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <CE835E918749D21191B10060084C377E01B5E035@ismail1.icomverse.com>
Content-Type: multipart/mixed; boundary="------------A24482771FC0398B0D733BE3"
Message-ID:  <38C3D5F8.8325310C@usa.alcatel.com>
Date:         Mon, 6 Mar 2000 09:59:52 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Re: [MOBILE-IP] charter update?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------A24482771FC0398B0D733BE3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Eric,

The WAP forum has been working on some issues related to inter gateway
switching. This in order to support roaming services between WAP Service
providers. But I agree with you that the current architecture does not offer
such service.

Vincent.
"Klein, Eric" wrote:

> Vincent,
>
> I disagree. I have been doing a lot of work lately on WAP, and there is no
> standard currently for roaming using WAP. These users would need to have a
> mobile IP address that would be valid on the visited network, while still
> being valid for retrieval and security based access on their home network.
>
> Right now the GSM Association is proposing one solution and the WAP Forum is
> proposing a different one. We need to have something flexible enough to
> handle single carriers with a million or more users.
>
> Eric
>
> -----Original Message-----
> From: Vincent Magret [mailto:vincent.magret@USA.ALCATEL.COM]
> Sent: Saturday, March 04, 2000 12:46 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] charter update?
>
> Hello,
>
> I don't get the point of taking into account the WAP. The WAP architecture
> relies on IP and does not make any requirements regarding IP mobility.
>
> Vincent.
>
> "Klein, Eric" wrote:
>
> > All,
> >
> > I would have to agree with Pat and Mark, today the biggest push for
> > mobile-IP will be the cellular market. What we need to take into account
> is
> > both cellular data and WAP applications. This is a real hot topic right
> now
> > with Microsoft, AOL, and Yahoo trying to take the dominate position for
> > configuration and portals. These areas are now in the same stage that BBS'
> > were 10 years ago with different rules and speeds. As these all will be
> > using some form of IP we should look at a way to integrate all of them
> into
> > both the charter and the final recommendations and standards.
> >
> >   Eric Klein
> >   Network Specialist
> >   star*home, a Comverse Company
> >
> >   Phone:  +972 (3) 765-5793
> >   Cell:    +972 (51) 232-375
> >   Fax:    +972 (3) 765-5688
> >   Email:   eric_klein@starhome.com
> >   Web:    http:/www.starhome.com
> >
> > -----Original Message-----
> > From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM]
> > Sent: Wednesday, March 01, 2000 3:56 PM
> > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: [MOBILE-IP] charter update?
> >
> > All,
> >
> > I find it difficult to justify NOT updating the draft to include cellular
> > specific extensions. As many of you know, Mobile IP has been in RFC form
> for
> > quite some time now, and until the cellular folks decided to adopt it, we
> > really didn't have much deployment. If cellular is the killer Mobile IP
> > service, then we should do what we can to help make Mobile IP successful.
> >
> > PatC
> >
> > > I think the charter should be updated to support cellular specific
> > > extensions.
> > >
> > > Mark A. Lipford
> > > Manager, Wireless Industry Standards - Data
> > > Sprint PCS
> > > 8001 College Blvd.; Suite 210
> > > Overland Park, KS  66210
> > > (913) 664-8335 (office)
> > > (913) 664-8440 (fax)
> > > (913) 226-9060 (PCS)
> > >
> > >
> > > -----Original Message-----
> > > From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> > > Sent: Tuesday, February 29, 2000 5:14 PM
> > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > > Subject: [MOBILE-IP] charter update?
> > >
> > >
> > > Greetings gentlepeople,
> > >
> > >     We've got 4 presentations lined up at the Adelaide meeting on
> various
> > > proposals for handoff.  This together with the fact that several of our
> > > current drafts are motivated by 3G data support indicates to Raj and me
> > that
> > > there continues to be some interest in the group in supporting cellular
> > > specific extensions to mobile-ip.  The charter doesn't specify a strong
> > > support of these activities.  The current wording is "The WG moving
> > forward
> > > will focus on deployment issues in Mobile IP and provide appropriate
> > > protocol solutions to address known deficiencies and shortcomings. For
> > > example, the wireless/cellular industry is considering using Mobile IP
> as
> > > one technique for IP mobility for wireless data. The working group will
> > > endeavor to gain an understanding of data service in cellular systems
> such
> > > as GPRS, UMTS, CDMA2000, and interact with other standards bodies that
> are
> > > trying to adopt and deploy Mobile IP WG protocols in these contexts."
> > > So I'd like to find out whether there is interest in the group to
> > extending
> > > the charter for specific support of cellular systems.  If there is
> general
> > > support I'll propose some wording.  One obvious work item would be to
> > submit
> > > a draft to the IESG for support of fast handover.
> > >
> > > Comments?
> > > Phil

--------------A24482771FC0398B0D733BE3
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincent.magret.vcf"
Content-Description: Card for Vincent Magret
Content-Disposition: attachment;
 filename="vincent.magret.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Magret;Vincent
tel;fax:+1 972 996 5902
tel;work:+1 972 996 2625
x-mozilla-html:FALSE
org:;Network Strategy Group
version:2.1
email;internet:vincent.magret@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA
fn:Vincent Magret
end:vcard

--------------A24482771FC0398B0D733BE3--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 18:20:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25953
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 18:20:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F68165B0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 18:15:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76579 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 18:13:39 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.B2AD5A60@standards.nortelnetworks.com>;
          Mon, 6 Mar 2000 18:13:39 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id QAA03320 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Mar 2000 16:17:24
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          PAA07023 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 6 Mar
          2000 15:17:23 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id PAA19676; Mon, 6 Mar 2000 15:17:21
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: W97WQ6xzxc6Uf+TOdyVmmQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003062317.PAA19676@nasnfs.eng.sun.com>
Date:         Mon, 6 Mar 2000 15:18:54 -0800
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] charter update
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I wanted to post a few thoughts on the discussion about charter update,
beyond the cryptic email I sent last week, for which I apologize. I
should know better than to comment on complex technical subjects
the morning after a 14 hour plane trip. :-) The following is somewhat
long and maybe repetitious to some people, but hopefully presents
a worthwhile perspective.

IMHO, the issue with micromobility (as it's being called) is not so much
L2 dependence as whether the IP subnet model is accurate for
the particular application. If the IP subnet model is accurate, then
the mobile IP architecture in its current form, with perhaps a few
tweaks for performance, is an acceptable solution. If the subnet model
is not accurate, then mobile IP might not be the best solution.

An example of a wireless network architecture where the subnet model breaks
down entirely is mobile, ad hoc networks. The MANET group is working
on this problem, and the solutions that are being offered are
independent of any particular radio technology or link layer, and are
therefore general.

An example of an L2 technology that fits well with the subnet model
is IEEE 802.11 wireless LAN. If the wireless nodes are on a separate
subnet or the access points are performing L2 bridging, then L2 mobility can
take care of fast, on-subnet handoff and mobile IP can take care of handoff
between subnets. There is still an issue here of whether between-subnet handoff
is fast enough for multimedia applications but, in principle, the general mobile
IP framework seems capable of handling the situation.

The example of CDMA networks is somewhat unclear, and seems to lay between
these two cases. These networks typically have a requirement for very
fast handoff and stringent QoS guarantees because they are primarily voice. They
also don't obey the subnet model very well, because there can be multiple
physical packet streams coming from/going to a mobile node through individual
radio access points that logically correspond to a single packet stream outgoing
from the mobile node or incoming from the corresponding node.
The multiple streams get combined in the radio access network into a single
packet stream or on entrance to the radio access network are generated by
splitting the single stream coming from the corresponding node.

The mobile IP framework doesn't handle this case very well. Logically,
one would like to have the freedom to design the network so that
each individual transmitter is on a separate subnet, but because the
packet streams moving through the different transmitters don't correspond
to logically separate streams, the subnet model doesn't seem like the
correct one. The situation is more like multicast, at least in the
incoming direction, but the streams must be highly synchronized and
reliably delivered.

For now, economic necessity is driving the radio access network design
to use IP in whatever way it can independent of whether micromobility
can be handled by mobile IP. I've been working with the Mobile
Wireless Internet Forum on this, and at a meeting last week we
discussed how to get IP into the radio access network. The solution
for now is to have the IP radio access network in a logically separate address
space from the IP address space of the mobile node, so the mobile node's address
is not used while routing in the radio access network, a form of tunnelling.
This allows the traffic on the radio access network to be primarily
shaped radio packet payloads in IP packets, with some control traffic
as necessary. At some point in the radio access network, the combination
of the outgoing packets occurs, and a physical VoIP packet or an IP data packet
as generated by an application on the mobile node is generated (or vice versa,
incoming).

Actual packet datagram service to the mobile node is
handled by an overlay network, the design of which is already complete
in both European and North American standards. Mobile IP is used
in the North American standard for packet data service mobility between domains
and is being considered in the European standard, although the European
standard currently uses a different mechanism. In the North American
design, the FA is outside the radio access network. For now, this is enough
because nobody is proposing VoIP over the radio network anytime soon, due to the
lack of a spectrally efficient representation of VoIP on the air in comparison
with traditional packetized cellular voice.

But the cellular operators would like to have the mobile node's address
be logically in the access network's address space if technically possible,
because it would improve the end-to-end properties of the network
connection, and may also result in a somewhat more efficient use of
network bandwidth, especially if the mobile node is a fully Internet
capable cell phone and is using VoIP instead of traditional cellular
voice protocols. This is clearly a direction in which there is some
desire among a variety of groups to see the radio access network
of CDMA systems evolve.

On QoS and mobile IP, I think there is an issue, at least as far as
CDMA radio access networks are concerned. Currently, these networks
tend to be point-to-point between a centralized controller and
a collection of radio access points, so routing isn't a big issue,
but some cellular operators are looking at switched and (potentially)
routed networks down the line. If these networks are routed, then
MPLS becomes an interesting option for QoS, and the question comes
up about where to put the FA in relation to the MPLS tunnel. If the
FA is at the downstream end of the tunnel, then there is an extra level of MPLS
encapsulation. If the FA is at the upstream end of the tunnel, then there is a
question about how to handle mobility with MPLS. I don't claim to
know enough about MPLS to suggest any solutions, but it seems like
there are potential issues that need examining. The same issues come up
if MPLS is used in the core network as well.

Maybe the CDMA example is too specific for including in the mobile IP charter,
and perhaps it should be a separate working group, or perhaps it should
be left outside the IETF's purview entirely and up to the telephony
standards groups. I know of no other radio networking technology that has the
same peculiar properties. On the other hand, it is clear (at least to me)
the the expertiese to provide possible solutions lies with the IETF. I
have not had a chance to read all of the micro-mobility drafts, but the
ones I've looked at have some ideas that need consideration. I think
that some group in the IETF, whether it is the mobile IP group or
a separate group, like MANET, should be chartered to look at these
issues, with the CDMA network in mind as the model.

Comments?

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 18:40:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29268
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 18:40:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4CC2610@standards.nortelnetworks.com>; Mon, 6 Mar 2000 18:35:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76635 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 18:34:20 -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.306F9BB0@standards.nortelnetworks.com>; Mon, 6 Mar 2000
          18:24:20 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          RAA19854; Mon, 6 Mar 2000 17:27:55 -0600 (CST)
X-Sender: "Vincent Magret" <magrvi@eagle.aud.alcatel.com>
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <45AFD48D077ED211BB4700A0C9DCE8FD15AF42@monza.broadswitch.com>
Content-Type: multipart/mixed; boundary="------------F62D0F499BB558B5798080F5"
Message-ID:  <38C43E5B.21E92600@usa.alcatel.com>
Date:         Mon, 6 Mar 2000 17:25:15 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Re: [MOBILE-IP] Terminology (was: [MOBILE-IP] charter update?)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------F62D0F499BB558B5798080F5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I agree that it is necessary to take advantage of the underlying technology
used. The principle I'm thinking of is to define a protocol to support
micro-mobility and to define "mapping" to specific wireless technology. I don't
see how a protocol without tuning (i.e. link to  LL 2) could provide an
acceptable level of services (i.e. fast handoff).

Vincent.

Thomas Eklund wrote:

> > >A spinoff of the MIP WG, say  MIPSAT WG
> > >(IP mobility support over Specific Access Technologies)
> > >would probably be a good thing, accommodating
> > >any need to address specific problems that
> > >MIP is considered not sufficient to address over
> > >specific access Technologies. Also this would
> > >come with the benefit of providing a well defined
> > >scope for each new proposal coming in.
> > >
> >
> > Mobile IP's access independence characteristic makes it so viable.
> > So there's not much to be said for IP mobility support over specific
> > access technologies as you propose.
>
> I definitatly not agree here.. It is very important to optimize the IP
> transport (doen in Robust Header Compression WG), mobility management over
> specific link layers, especially over different radio link layers because
> they have very special charateristics that needs to be adapted to in order
> to make it efficient...
>
> I would say that this is very important and judging from the interest of
> trying to solve the micro mobility shows that people are not satisfied with
> just running mobile ip over radio....
>
> Important thing to include for instance is more states in the radio like
> idle, active mode in order to define location managemnt protocols...
>
> We are speaking about IP based mobility here not mobile IP... But mobile IP
> will be the base for all work of course...
>
> >
> > >There may be another approach (AKA "the tail that
> > >wags the dog") that is defining a new access network
> > >based on newly IETF specified access protocols, but this
> IETF dont specify access technologies, this is layer 1 and 2 stuff... When
> we want to run IP over them, then of course it should be as smooth as
> possible this is why we need  clear interfaces that people have been
> discussing so when a new acces technology comes you can very easy integrate
> it with your ISP backbone...
>
> /Thomas

--------------F62D0F499BB558B5798080F5
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincent.magret.vcf"
Content-Description: Card for Vincent Magret
Content-Disposition: attachment;
 filename="vincent.magret.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Magret;Vincent
tel;fax:+1 972 996 5902
tel;work:+1 972 996 2625
x-mozilla-html:FALSE
org:;Network Strategy Group
version:2.1
email;internet:vincent.magret@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA
fn:Vincent Magret
end:vcard

--------------F62D0F499BB558B5798080F5--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 19:29:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07797
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 19:29:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A1670170@standards.nortelnetworks.com>; Mon, 6 Mar 2000 19:24:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76726 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 19:23:27 -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0CEB5650@standards.nortelnetworks.com>; Mon, 6 Mar 2000 19:13:27
          -0500
Received: from mail.inter-partner.de ([195.126.47.122]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id SAA09818 for
          <mobile-ip@smallworks.com>; Mon, 6 Mar 2000 18:17:11 -0600 (CST)
Received: from gorvhow (ABD681A9.ipt.aol.com [171.214.129.169]) by
          mail.inter-partner.de with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2232.9) id G2MF5J09; Mon, 6 Mar 2000 05:28:29
          +0100
Message-ID:  <200003070017.SAA09818@hosaka.smallworks.com>
Date:         Mon, 6 Mar 2000 18:17:11 -0600
Reply-To: info103@CCNMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: info103@CCNMAIL.COM
Subject:      [MOBILE-IP] Great work at home opportunity
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

If You Want To Make $1,000 - $2,000 Per Week Helping Car Dealerships,
Then You'll Definitely Be Interested In The Following!


You Can Make Big Profits Helping Used Car Dealerships!

Here's How It Works:

You help them with a product for each of the used cars on their lot. This
concept has been accepted by every factory certified program in the
country. Every new car manufacturer has been using this concept for the
past 65 years! It's PROVEN.

This product will generate between $5.00 and $10.00 income for EACH car
on the dealership's lot. Making arrangements to help just one 100-car
dealership can result in $6000 to $12,000 a year income! That's ONE
dealership! How many dealerships are there within 30 minutes of where
you live? Do the math!

Ok, About This Product...

Put Simply.. They are Stickers.  "What kind of stickers?"  They are placed
on used cars so that the customer gets the information they need. These
stickers are similar to the new car factory stickers except these are for
USED cars. They describe the features, options, equipment, mileage, price
and warranty for the customer. They are a 24-hour salesman that never takes
a coffee break!

When the customer is given information, they appreciate the VALUE of the
vehicle more, they are more satisfied and the dealership makes more
PROFIT. The used car salesman even becomes more knowledgeable about his
products.  EVERYONE WINS!

This great system also makes it easy for you to display the dealerships'
vehicles and photos on the Internet for even more VALUE and more income.

Did you know that the used car market is 3 times larger than the new car
market?

OK, this is a GREAT opportunity but how much does it cost to get started?

Good news there too.  There is a new low cost package to make it easier
for you to get started..

If you're interested in more details on this opportunity,
Please send your

Name:
Address (USA Only):
Address (cont'd):
City:
State:
Zip:
Phone:
Email:

To mailto:autoprofits15@newmail.net

Thank you for your time.  Have a great day.

PS As a bonus, if you respond now, you'll get a FREE monthly
Bizop E-zine and postings with important messages to the home-based
entrepreneur!


To be removed, mailto:unsubscribe305@newmail.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar  6 19:29:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07799
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 6 Mar 2000 19:29:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A1A9AFC0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 19:24:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 76737 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 19:23:56 -0500
Received: from emrys.qualcomm.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.83EF5D90@standards.nortelnetworks.com>; Mon, 6 Mar 2000 19:23:56
          -0500
Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by
          emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id QAA18977; Mon,
          6 Mar 2000 16:27:41 -0800 (PST)
X-Sender: jwillkie@mail1.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000306153509.00d4a850@mail1.qualcomm.com>
Date:         Mon, 6 Mar 2000 16:27:03 -0800
Reply-To: Jim Willkie <jwillkie@QUALCOMM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jim Willkie <jwillkie@QUALCOMM.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         James Kempf <James.Kempf@Eng.Sun.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003062317.PAA19676@nasnfs.eng.sun.com>

At 03:18 PM 3/6/00 -0800, James Kempf wrote:
>I wanted to post a few thoughts on the discussion about charter update,
>beyond the cryptic email I sent last week, for which I apologize. I
>should know better than to comment on complex technical subjects
>the morning after a 14 hour plane trip. :-) The following is somewhat
>long and maybe repetitious to some people, but hopefully presents
>a worthwhile perspective.
--cut--

The CDMA example below is a bit misleading. Please allow me to clarify...

>The example of CDMA networks is somewhat unclear, and seems to lay between
>these two cases. These networks typically have a requirement for very
>fast handoff and stringent QoS guarantees because they are primarily voice.

It is true re: fast handoff and QoS but these aspects occur at the physical
layer. A packet data stream over CDMA would not be subject to either of
these conditions as they occur below L2. Packet mobility-related handoff
occurs at IWF (or PDSN) boundaries and only occur at boundaries.

>They
>also don't obey the subnet model very well, because there can be multiple
>physical packet streams coming from/going to a mobile node through individual
>radio access points that logically correspond to a single packet stream
>outgoing
>from the mobile node or incoming from the corresponding node.

This statement is not accurate. Now it is true that at the physical layer
CDMA when a user on a traffic channel is in a soft or softer handoff
condition (ie. connected to multiple BTSs) that traffic channel frames are
moving between the mobile and multiple BTSs, BUT these are in fact the same
frames coming from multiple sites. For voice they are the same voice
frames, for data they are the same packets. In either case the the CDMA
physical layer 'merges' them together. In summary this situation should not
be considered multiple packets coming/going because they are not.

>The multiple streams get combined in the radio access network into a single
>packet stream or on entrance to the radio access network are generated by
>splitting the single stream coming from the corresponding node.

Ahh, this is true.

>The mobile IP framework doesn't handle this case very well.

This is where I do not agree. MobileIP has no idea the combining/separating
has even occured. So mobileIP has no problem with this as soft/softer
handoff would only occur within a single operators equipment (so a single
PDSN would be the case for all soft/softer handoff situations).

So in summary the CDMA network does NOT introduce additional complexity for
network layer mobility.

Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 00:50:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07495
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 00:50:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.887E3B10@standards.nortelnetworks.com>; Tue, 7 Mar 2000 0:46:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77039 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 00:45:07 -0500
Received: from telecom.samsung.co.kr (165.213.221.4) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FBE61020@standards.nortelnetworks.com>; Tue, 7 Mar 2000 0:35:05
          -0500
Received: from keg ( [165.213.177.180] (may be forged)) by
          telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id OAA12304; Tue, 7 Mar
          2000 14:38:14 +0900 (KST)
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Message-ID:  <005a01bf87f6$9c4c1680$b4b1d5a5@keg.telecom.samsung.co.kr>
Date:         Tue, 7 Mar 2000 14:32:53 +0900
Reply-To: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Subject:      [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id AAA07495

Hi All,

I've been looking at the challeng/response (v09) draft and I noticed that it seems to imply that the Mobile-Home authentication extension is optional. It says 

"..........
   Since the Challenge extension, and the authentication extension that
   is used by the Mobile Node to satisfy the challenge, both follow
   the Mobile-Home Authentication extension whenever the latter is
   present, the Foreign Agent MAY remove the Challenge Extension and
   the applicable authentication from the Registration Request without
   disturbing the authentication value computed by the Mobile Node for
   use by the Home Agent.
........"

i.e. "whenever the latter is pressent", where latter is the MN-HA authentication.

but in the rfc2002 (and its later version rfc2002-bis) it says

"....
3.2. Authentication

   Each mobile node, foreign agent, and home agent MUST be able to
   support a mobility security association for mobile entities, indexed
   by their SPI and IP address.  In the case of the mobile node, this
   must be its Home Address.  See Section 5.1 for requirements for
   support of authentication algorithms.  Registration messages between
   a mobile node and its home agent MUST be authenticated with the
   Mobile-Home Authentication Extension (Section 3.5.2).  This Extension
   immediately follows all non-authentication Extensions, except those
   foreign agent-specific Extensions which may be added to the message
   after the mobile node computes the authentication.....
"

Could someone point out which is the correct one. 

To me even if FAC is used, I don't quite see how it nullfies the need for the MN-HA authentication field.

cheers

Woojune Kim,
Senior Engineer
Samsung Electronics Ltd. 
tel : +82-342-779-8526
hp : +82-11-368-7480
e-mail : keg@telecom.samsung.co.kr



From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 01:06:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11147
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 01:06:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6FF9850@standards.nortelnetworks.com>; Tue, 7 Mar 2000 1:02:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77095 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 01:00:24 -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.8511D930@standards.nortelnetworks.com>; Tue, 7 Mar 2000 1:00:24
          -0500
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 WAA15092;
          Mon, 6 Mar 2000 22:03:27 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id VAA07358; Mon, 6 Mar 2000 21:59:32 -0800
X-Virus-Scanned:  Mon, 6 Mar 2000 21:59:32 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma007228; Mon, 6 Mar 00 21:59:29 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <005a01bf87f6$9c4c1680$b4b1d5a5@keg.telecom.samsung.co.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C49BA7.2652F7EA@iprg.nokia.com>
Date:         Mon, 6 Mar 2000 22:03:19 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         Woo-June Kim <keg@telecom.samsung.co.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

Woo-June Kim wrote:

> To me even if FAC is used, I don't quite see how it nullfies the need for
> the MN-HA authentication field.

The Challenge specification was written after the MN-NAI specification,
and the MN-NAI specification allows a MN-AAA authentication extension
to take the place of the MN-HA authentication extension.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 03:16:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21699
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 03:16:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1150E80@standards.nortelnetworks.com>; Tue, 7 Mar 2000 3:11:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77184 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 03:09:48 -0500
Received: from telecom.samsung.co.kr (165.213.221.4) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.32455860@standards.nortelnetworks.com>; Tue, 7 Mar 2000 2:59:47
          -0500
Received: from keg ( [165.213.177.180] (may be forged)) by
          telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id RAA32534; Tue, 7 Mar
          2000 17:03:12 +0900 (KST)
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Message-ID:  <008601bf880a$d9e55880$b4b1d5a5@keg.telecom.samsung.co.kr>
Date:         Tue, 7 Mar 2000 16:57:50 +0900
Reply-To: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         "Charles E. Perkins" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id DAA21699

Charles

Thanks. I guess I should read more carefully ! But, as I suggested in my other e-mail, maybe the draft rfc2002-bis wording needs to be changed to reflect the fact that MN-HA authentication is not a MUST now. (of course some sort of authentication is still needed... see below)

Anyway your answer brings more questions to my mind.

The challenge/response draft says the MN-AAA authentication extension can be removed by the FA after authentication is carried out by some means at the FA. (by an AAA infra etc.)

If the MN-AAA authentication is removed, and there is no MN-HA authentication, by what means will the HA be able to authenticate the message ? Are you not assuming that in such a case the MN-HA authentication is used ? 

My understanding leads me to assume that in case either an MN-AAA authentication or MN-HA authentication extension will always be in a registration request received by the Home Agent. But the current wording of the document seems to able to lead to cases where the FA implementation could remove an MN-AAA authentication extension even when an MN-HA authentication does not exist.

Please correct me if I'm wrong again.
(by the way then I believe the wording of 

"..........
   Since the Challenge extension, and the authentication extension that
   is used by the Mobile Node to satisfy the challenge, both follow
   the Mobile-Home Authentication extension whenever the latter is
   present, the Foreign Agent MAY remove the Challenge Extension and
   the applicable authentication from the Registration Request without
   disturbing the authentication value computed by the Mobile Node for
   use by the Home Agent.
........"

should be changed (Is the first sentence grammatically correct ?)
to reflect the fact that the MN-AAA authentication can only be removed if there is a MN-HA authentication extension.
)

cheers

Woojune Kim,
Senior Engineer
Samsung Electronics Ltd. 
tel : +82-342-779-8526
hp : +82-11-368-7480
e-mail : keg@telecom.samsung.co.kr


>
>Hello,
>
>Woo-June Kim wrote:
>
>> To me even if FAC is used, I don't quite see how it nullfies the need for
>> the MN-HA authentication field.
>
>The Challenge specification was written after the MN-NAI specification,
>and the MN-NAI specification allows a MN-AAA authentication extension
>to take the place of the MN-HA authentication extension.
>
>Regards,
>Charlie P.
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 08:21:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23672
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 08:21:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81421FD0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 8:16:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77531 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 08:14:58 -0500
Received: from gwu.ericy.com (208.196.3.162) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.D48FB9B0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 8:04:58
          -0500
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by
          gwu.ericy.com (8.9.3/8.9.3) with ESMTP id HAA04961 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar 2000 07:07:07
          -0600 (CST)
Received: from lmc.ericsson.se ([142.133.1.1]) by mr3.exu.ericsson.se
          (8.9.3/8.9.3) with ESMTP id HAA15650 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar 2000 07:07:06
          -0600 (CST)
Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175])
          by lmc.ericsson.se (8.9.2/8.9.2) with ESMTP id IAA21561 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar 2000 08:07:00
          -0500 (EST)
Received: by lmc35.lmc.ericsson.se with Internet Mail Service (5.5.2650.21) id
          <F4T4ZKVD>; Tue, 7 Mar 2000 08:06:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <7E67DE81C0B6D311B30500805FFEBAAE02769D58@lmc35.lmc.ericsson.se>
Date:         Tue, 7 Mar 2000 08:06:38 -0500
Reply-To: "Lila Madour (LMC)" <lmclima@LMC.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Lila Madour (LMC)" <lmclima@LMC.ERICSSON.SE>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Charles,

  In the case the MN has security association with the FA ( MN-FA
authentication extension used instead of MN-AAA),  I assume, MN-HA extension
must be included in the message.
   Regards
    /Lila
> -----Original Message-----
> From: Woo-June Kim [SMTP:keg@TELECOM.SAMSUNG.CO.KR]
> Sent: Tuesday, March 07, 2000 02:58
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
>
> Charles
>
> Thanks. I guess I should read more carefully ! But, as I suggested in my
> other e-mail, maybe the draft rfc2002-bis wording needs to be changed to
> reflect the fact that MN-HA authentication is not a MUST now. (of course
> some sort of authentication is still needed... see below)
>
> Anyway your answer brings more questions to my mind.
>
> The challenge/response draft says the MN-AAA authentication extension can
> be removed by the FA after authentication is carried out by some means at
> the FA. (by an AAA infra etc.)
>
> If the MN-AAA authentication is removed, and there is no MN-HA
> authentication, by what means will the HA be able to authenticate the
> message ? Are you not assuming that in such a case the MN-HA
> authentication is used ?
>
> My understanding leads me to assume that in case either an MN-AAA
> authentication or MN-HA authentication extension will always be in a
> registration request received by the Home Agent. But the current wording
> of the document seems to able to lead to cases where the FA implementation
> could remove an MN-AAA authentication extension even when an MN-HA
> authentication does not exist.
>
> Please correct me if I'm wrong again.
> (by the way then I believe the wording of
>
> "..........
>    Since the Challenge extension, and the authentication extension that
>    is used by the Mobile Node to satisfy the challenge, both follow
>    the Mobile-Home Authentication extension whenever the latter is
>    present, the Foreign Agent MAY remove the Challenge Extension and
>    the applicable authentication from the Registration Request without
>    disturbing the authentication value computed by the Mobile Node for
>    use by the Home Agent.
> ........"
>
> should be changed (Is the first sentence grammatically correct ?)
> to reflect the fact that the MN-AAA authentication can only be removed if
> there is a MN-HA authentication extension.
> )
>
> cheers
>
> Woojune Kim,
> Senior Engineer
> Samsung Electronics Ltd.
> tel : +82-342-779-8526
> hp : +82-11-368-7480
> e-mail : keg@telecom.samsung.co.kr
>
>
> >
> >Hello,
> >
> >Woo-June Kim wrote:
> >
> >> To me even if FAC is used, I don't quite see how it nullfies the need
> for
> >> the MN-HA authentication field.
> >
> >The Challenge specification was written after the MN-NAI specification,
> >and the MN-NAI specification allows a MN-AAA authentication extension
> >to take the place of the MN-HA authentication extension.
> >
> >Regards,
> >Charlie P.
> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 11:47:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07199
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 11:47:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38F138C0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:42:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77978 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:41:34 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.166624A0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:41:33
          -0500
Received: from gdommety-pc2 (dhcp-171-69-71-251.cisco.com [171.69.71.251]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          IAA21104; Tue, 7 Mar 2000 08:44:41 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003071644.IAA21104@omega.cisco.com>
Date:         Tue, 7 Mar 2000 08:57:05 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <008601bf880a$d9e55880$b4b1d5a5@keg.telecom.samsung.co.kr>

>
>Anyway your answer brings more questions to my mind.
>
>The challenge/response draft says the MN-AAA authentication extension can be removed by the FA after authentication is carried out by some means at the FA. (by an AAA infra etc.)
>

Woo, I agree with you.

Charlie,

To add even if the MN-AAA is not removed, since the HA will not authenticate based of HA-AAA, how will the
HA authenticate the MN? Is the assumption that HA will be instructed to by the HAAA to accept the MN? (Note: I am not
sure if this is good or bad.  I would like to understand the motivation for the Statement about HA-MN being optional).

Thanks
Gopal


>If the MN-AAA authentication is removed, and there is no MN-HA authentication, by what means will the HA be able to authenticate the message ? Are you not assuming that in such a case the MN-HA authentication is used ?
>
>My understanding leads me to assume that in case either an MN-AAA authentication or MN-HA authentication extension will always be in a registration request received by the Home Agent. But the current wording of the document seems to able to lead to cases where the FA implementation could remove an MN-AAA authentication extension even when an MN-HA authentication does not exist.
>
>Please correct me if I'm wrong again.
>(by the way then I believe the wording of
>
>"..........
>   Since the Challenge extension, and the authentication extension that
>   is used by the Mobile Node to satisfy the challenge, both follow
>   the Mobile-Home Authentication extension whenever the latter is
>   present, the Foreign Agent MAY remove the Challenge Extension and
>   the applicable authentication from the Registration Request without
>   disturbing the authentication value computed by the Mobile Node for
>   use by the Home Agent.
>........"
>
>should be changed (Is the first sentence grammatically correct ?)
>to reflect the fact that the MN-AAA authentication can only be removed if there is a MN-HA authentication extension.
>)
>
>cheers
>
>Woojune Kim,
>Senior Engineer
>Samsung Electronics Ltd.
>tel : +82-342-779-8526
>hp : +82-11-368-7480
>e-mail : keg@telecom.samsung.co.kr
>
>
>>
>>Hello,
>>
>>Woo-June Kim wrote:
>>
>>> To me even if FAC is used, I don't quite see how it nullfies the need for
>>> the MN-HA authentication field.
>>
>>The Challenge specification was written after the MN-NAI specification,
>>and the MN-NAI specification allows a MN-AAA authentication extension
>>to take the place of the MN-HA authentication extension.
>>
>>Regards,
>>Charlie P.
>>
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 11:51:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07988
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 11:51:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.811C4220@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:44:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 77992 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:43:19 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5596E6A0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:43:19
          -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA03771; Tue, 7 Mar 2000 08:47:06
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          IAA08855; Tue, 7 Mar 2000 08:47:04 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA07529; Tue,
          7 Mar 2000 08:46:44 -0800 (PST)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-ID:  <200003071646.IAA07529@nasnfs.eng.sun.com>
Date:         Tue, 7 Mar 2000 08:47:10 -0800
Reply-To: pcalhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         "Lila Madour (LMC)" <lmclima@LMC.ERICSSON.SE>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

One of the motivator, and features that AAA provides, is dynamic Home Agent
assignment. Further, the Home Agent can reside in the Foreign Domain.

So, MN-AAA can be seen as a replacement for MN-HA, when there is no static
security association between the MN and it's/an HA.

PatC
>Charles,
>
>  In the case the MN has security association with the FA ( MN-FA
>authentication extension used instead of MN-AAA),  I assume, MN-HA extension
>must be included in the message.
>   Regards
>    /Lila
>> -----Original Message-----
>> From: Woo-June Kim [SMTP:keg@TELECOM.SAMSUNG.CO.KR]
>> Sent: Tuesday, March 07, 2000 02:58
>> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>> Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
>>
>> Charles
>>
>> Thanks. I guess I should read more carefully ! But, as I suggested in my
>> other e-mail, maybe the draft rfc2002-bis wording needs to be changed to
>> reflect the fact that MN-HA authentication is not a MUST now. (of course
>> some sort of authentication is still needed... see below)
>>
>> Anyway your answer brings more questions to my mind.
>>
>> The challenge/response draft says the MN-AAA authentication extension can
>> be removed by the FA after authentication is carried out by some means at
>> the FA. (by an AAA infra etc.)
>>
>> If the MN-AAA authentication is removed, and there is no MN-HA
>> authentication, by what means will the HA be able to authenticate the
>> message ? Are you not assuming that in such a case the MN-HA
>> authentication is used ?
>>
>> My understanding leads me to assume that in case either an MN-AAA
>> authentication or MN-HA authentication extension will always be in a
>> registration request received by the Home Agent. But the current wording
>> of the document seems to able to lead to cases where the FA implementation
>> could remove an MN-AAA authentication extension even when an MN-HA
>> authentication does not exist.
>>
>> Please correct me if I'm wrong again.
>> (by the way then I believe the wording of
>>
>> "..........
>>    Since the Challenge extension, and the authentication extension that
>>    is used by the Mobile Node to satisfy the challenge, both follow
>>    the Mobile-Home Authentication extension whenever the latter is
>>    present, the Foreign Agent MAY remove the Challenge Extension and
>>    the applicable authentication from the Registration Request without
>>    disturbing the authentication value computed by the Mobile Node for
>>    use by the Home Agent.
>> ........"
>>
>> should be changed (Is the first sentence grammatically correct ?)
>> to reflect the fact that the MN-AAA authentication can only be removed if
>> there is a MN-HA authentication extension.
>> )
>>
>> cheers
>>
>> Woojune Kim,
>> Senior Engineer
>> Samsung Electronics Ltd.
>> tel : +82-342-779-8526
>> hp : +82-11-368-7480
>> e-mail : keg@telecom.samsung.co.kr
>>
>>
>> >
>> >Hello,
>> >
>> >Woo-June Kim wrote:
>> >
>> >> To me even if FAC is used, I don't quite see how it nullfies the need
>> for
>> >> the MN-HA authentication field.
>> >
>> >The Challenge specification was written after the MN-NAI specification,
>> >and the MN-NAI specification allows a MN-AAA authentication extension
>> >to take the place of the MN-HA authentication extension.
>> >
>> >Regards,
>> >Charlie P.
>> >


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 11:53:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08578
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 11:53:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.123A86E0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:48:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78035 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:48:26 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0C52FDC0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:48:26
          -0500
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA06748; Tue, 7 Mar 2000 08:52:13
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          IAA09987; Tue, 7 Mar 2000 08:52:12 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA07658; Tue,
          7 Mar 2000 08:51:57 -0800 (PST)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-ID:  <200003071651.IAA07658@nasnfs.eng.sun.com>
Date:         Tue, 7 Mar 2000 08:52:17 -0800
Reply-To: pcalhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         Gopal Dommety <gdommety@CISCO.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Since the HA inherently trusts its AAA server (and if it doesn't then we have
a problem), if the AAAH states that the Mobile Node was authenticated, why
does the HA have to also authenticate the user?

Further, if we mandate MN-HA, then we need to push the Mobile Node's secret to
the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
domain), why would you want to provide the MN's password to it?

PatC
>>
>>Anyway your answer brings more questions to my mind.
>>
>>The challenge/response draft says the MN-AAA authentication extension can be
>removed by the FA after authentication is carried out by some means at the FA.
>(by an AAA infra etc.)
>>
>
>Woo, I agree with you.
>
>Charlie,
>
>To add even if the MN-AAA is not removed, since the HA will not authenticate
>based of HA-AAA, how will the
>HA authenticate the MN? Is the assumption that HA will be instructed to by the
>HAAA to accept the MN? (Note: I am not
>sure if this is good or bad.  I would like to understand the motivation for the
>Statement about HA-MN being optional).
>
>Thanks
>Gopal
>
>
>>If the MN-AAA authentication is removed, and there is no MN-HA authentication,
>by what means will the HA be able to authenticate the message ? Are you not
>assuming that in such a case the MN-HA authentication is used ?
>>
>>My understanding leads me to assume that in case either an MN-AAA
>authentication or MN-HA authentication extension will always be in a
>registration request received by the Home Agent. But the current wording of the
>document seems to able to lead to cases where the FA implementation could remove
>an MN-AAA authentication extension even when an MN-HA authentication does not
>exist.
>>
>>Please correct me if I'm wrong again.
>>(by the way then I believe the wording of
>>
>>"..........
>>   Since the Challenge extension, and the authentication extension that
>>   is used by the Mobile Node to satisfy the challenge, both follow
>>   the Mobile-Home Authentication extension whenever the latter is
>>   present, the Foreign Agent MAY remove the Challenge Extension and
>>   the applicable authentication from the Registration Request without
>>   disturbing the authentication value computed by the Mobile Node for
>>   use by the Home Agent.
>>........"
>>
>>should be changed (Is the first sentence grammatically correct ?)
>>to reflect the fact that the MN-AAA authentication can only be removed if there
>is a MN-HA authentication extension.
>>)
>>
>>cheers
>>
>>Woojune Kim,
>>Senior Engineer
>>Samsung Electronics Ltd.
>>tel : +82-342-779-8526
>>hp : +82-11-368-7480
>>e-mail : keg@telecom.samsung.co.kr
>>
>>
>>>
>>>Hello,
>>>
>>>Woo-June Kim wrote:
>>>
>>>> To me even if FAC is used, I don't quite see how it nullfies the need for
>>>> the MN-HA authentication field.
>>>
>>>The Challenge specification was written after the MN-NAI specification,
>>>and the MN-NAI specification allows a MN-AAA authentication extension
>>>to take the place of the MN-HA authentication extension.
>>>
>>>Regards,
>>>Charlie P.
>>>
>>
>Thank You.
>Regards,
>Gopal
>-------------------------------------------------------------------------------------------------------------
>
>Gopal Dommety
>408 525 1404
>gdommety@cisco.com
>Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 12:21:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14766
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 12:21:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0028D660@standards.nortelnetworks.com>; Tue, 7 Mar 2000 12:16:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78129 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 12:15:38 -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.736CF6D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000
          12:05:38 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          LAA27113; Tue, 7 Mar 2000 11:09:05 -0600 (CST)
X-Sender: "Vincent Magret" <magrvi@eagle.aud.alcatel.com>
X-Mailer: Mozilla 4.5 [en]C-CCK-MCD ANS2.00  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003071646.IAA07529@nasnfs.eng.sun.com>
Content-Type: multipart/mixed; boundary="------------690BA0CFD2857A476D950271"
Message-ID:  <38C53718.A1AB3194@usa.alcatel.com>
Date:         Tue, 7 Mar 2000 11:06:32 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Organization: Alcatel USA, Inc.
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------690BA0CFD2857A476D950271
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:

> One of the motivator, and features that AAA provides, is dynamic Home Agent
> assignment. Further, the Home Agent can reside in the Foreign Domain.

Isn't this feature already available with Mobile IP?

>
>
> So, MN-AAA can be seen as a replacement for MN-HA, when there is no static
> security association between the MN and it's/an HA.
>
> PatC
> >Charles,
> >
> >  In the case the MN has security association with the FA ( MN-FA
> >authentication extension used instead of MN-AAA),  I assume, MN-HA extension
> >must be included in the message.
> >   Regards
> >    /Lila
> >> -----Original Message-----
> >> From: Woo-June Kim [SMTP:keg@TELECOM.SAMSUNG.CO.KR]
> >> Sent: Tuesday, March 07, 2000 02:58
> >> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> >> Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
> >>
> >> Charles
> >>
> >> Thanks. I guess I should read more carefully ! But, as I suggested in my
> >> other e-mail, maybe the draft rfc2002-bis wording needs to be changed to
> >> reflect the fact that MN-HA authentication is not a MUST now. (of course
> >> some sort of authentication is still needed... see below)
> >>
> >> Anyway your answer brings more questions to my mind.
> >>
> >> The challenge/response draft says the MN-AAA authentication extension can
> >> be removed by the FA after authentication is carried out by some means at
> >> the FA. (by an AAA infra etc.)
> >>
> >> If the MN-AAA authentication is removed, and there is no MN-HA
> >> authentication, by what means will the HA be able to authenticate the
> >> message ? Are you not assuming that in such a case the MN-HA
> >> authentication is used ?
> >>
> >> My understanding leads me to assume that in case either an MN-AAA
> >> authentication or MN-HA authentication extension will always be in a
> >> registration request received by the Home Agent. But the current wording
> >> of the document seems to able to lead to cases where the FA implementation
> >> could remove an MN-AAA authentication extension even when an MN-HA
> >> authentication does not exist.
> >>
> >> Please correct me if I'm wrong again.
> >> (by the way then I believe the wording of
> >>
> >> "..........
> >>    Since the Challenge extension, and the authentication extension that
> >>    is used by the Mobile Node to satisfy the challenge, both follow
> >>    the Mobile-Home Authentication extension whenever the latter is
> >>    present, the Foreign Agent MAY remove the Challenge Extension and
> >>    the applicable authentication from the Registration Request without
> >>    disturbing the authentication value computed by the Mobile Node for
> >>    use by the Home Agent.
> >> ........"
> >>
> >> should be changed (Is the first sentence grammatically correct ?)
> >> to reflect the fact that the MN-AAA authentication can only be removed if
> >> there is a MN-HA authentication extension.
> >> )
> >>
> >> cheers
> >>
> >> Woojune Kim,
> >> Senior Engineer
> >> Samsung Electronics Ltd.
> >> tel : +82-342-779-8526
> >> hp : +82-11-368-7480
> >> e-mail : keg@telecom.samsung.co.kr
> >>
> >>
> >> >
> >> >Hello,
> >> >
> >> >Woo-June Kim wrote:
> >> >
> >> >> To me even if FAC is used, I don't quite see how it nullfies the need
> >> for
> >> >> the MN-HA authentication field.
> >> >
> >> >The Challenge specification was written after the MN-NAI specification,
> >> >and the MN-NAI specification allows a MN-AAA authentication extension
> >> >to take the place of the MN-HA authentication extension.
> >> >
> >> >Regards,
> >> >Charlie P.
> >> >

--------------690BA0CFD2857A476D950271
Content-Type: text/x-vcard; charset=us-ascii;
 name="vincent.magret.vcf"
Content-Description: Card for Vincent Magret
Content-Disposition: attachment;
 filename="vincent.magret.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Magret;Vincent
tel;fax:+1 972 996 5902
tel;work:+1 972 996 2625
x-mozilla-html:FALSE
org:;Network Strategy Group
version:2.1
email;internet:vincent.magret@usa.alcatel.com
adr;quoted-printable:;;1201 E. Campbell rd=0D=0AM-S 446-310;Ricahrdson;Texas;75081;USA
fn:Vincent Magret
end:vcard

--------------690BA0CFD2857A476D950271--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 15:15:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27835
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 15:15:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5AFDEEF0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 15:11:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78355 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 15:09:37 -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C199DB30@standards.nortelnetworks.com>; Tue, 7 Mar 2000 14:59:37
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate.mot.com (motgate 2.1) with ESMTP id NAA22221 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar 2000 13:03:26
          -0700 (MST)]
Received: [from ilms06.cig.mot.com (ilms06.cig.mot.com [136.182.15.18]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA23882 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar 2000 13:03:24
          -0700 (MST)]
Received: from email.mot.com ([160.44.110.59]) by ilms06.cig.mot.com (Netscape
          Messaging Server 3.01)  with ESMTP id AAA28477; Tue, 7 Mar 2000
          13:19:45 -0600
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C54C26.A52CE421@email.mot.com>
Date:         Tue, 7 Mar 2000 12:36:22 -0600
Reply-To: Ajoy Singh <ASINGH1@EMAIL.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <ASINGH1@EMAIL.MOT.COM>
Organization: Motorola
Subject:      [MOBILE-IP] Flow control for R-P interface
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello All,

I have some concern regarding the R-P interface protocol that is being
proposed to tunnel PPP traffic from RNN to PDSN and vice versa for CDMA
2000 type of wireless network.

Current proposal for R-P interface does not talk about any flow control
scheme between RNN and PDSN. This kind of makes me nervous because in
the current situation,  RNN will end of doing buffering when it is
unable to send traffic to mobile node due to unavailability of radio
interfaces. In this model a RNN has to discard PPP traffic when buffer
overflows for a particular session.  As PPP framing is done between MS
and PDSN, so this type of approach will end of dropping fractions of
multiple frames by RNN unless HDLC framing is done by RNN, which is not
likely to happen.  Moreover in case of wireless network, we are talking
about using various header/payload compression schemes which is known to
degrade the performance in a lossy network. Is it not possible to
implement some type of flow control scheme between RNN and PDSN ?  I
think,  PDSN can use  that information to discard IP packets before
performing any header/payload compression ?  I know the flow control
scheme is removed from L2TP,  but i think it might be worth to discuss
the problem in case of R-P interface, as we are talking about shared
channel being used by different mobiles which is not true in current
L2TP implementations.  Moreover  in  case of L2TP framing is done by
LAC, so it is not possible that unframed data will be discarded between
LAC to LNS.

I am working on a draft that talks about flow control mechanism which
can be implemented between RNN and PDSN. I would like to find out view
of mobile ip working group members, whether they perceive this as a
problem or not.

regards,
ajoy


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 16:44:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23081
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 16:44:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0661F80@standards.nortelnetworks.com>; Tue, 7 Mar 2000 16:40:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78496 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 16:38:23 -0500
Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.27DD65E0@standards.nortelnetworks.com>;
          Tue, 7 Mar 2000 16:28:22 -0500
Received: from cc.hut.fi (root@gamma.hut.fi [130.233.224.52]) by smtp-2.hut.fi
          (8.9.3/8.9.3) with ESMTP id XAA96543; Tue, 7 Mar 2000 23:32:08 +0200
          (EET)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: fi,sv,de
MIME-Version: 1.0
References: <200003071651.IAA07658@nasnfs.eng.sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38C57555.9E442209@cc.hut.fi>
Date:         Tue, 7 Mar 2000 23:32:05 +0200
Reply-To: Tom =?iso-8859-1?Q?Weckstr=F6m?= <tweckstr@CC.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Tom =?iso-8859-1?Q?Weckstr=F6m?= <tweckstr@CC.HUT.FI>
Organization: HUT/TKK
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         pcalhoun@Eng.Sun.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Pat,

This is just nitpicking about your trust statement...

80% - or even 90% of security attacks tend to come from inside. I would
not state that HA trusts AAAH inherently without any security
associations (i.e. shared secrets, public key systems, certificates,...)
It would be far too easy to play HA or AAAH inside the Home Network, if
no verification mechanism for the trust relationship existed.

Regards,
         Tom


Patrice Calhoun wrote:
>
> Since the HA inherently trusts its AAA server (and if it doesn't then we have
> a problem), if the AAAH states that the Mobile Node was authenticated, why
> does the HA have to also authenticate the user?
>
> Further, if we mandate MN-HA, then we need to push the Mobile Node's secret to
> the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
> domain), why would you want to provide the MN's password to it?
>
> PatC
> >>
> >>Anyway your answer brings more questions to my mind.
> >>
> >>The challenge/response draft says the MN-AAA authentication extension can be
> >removed by the FA after authentication is carried out by some means at the FA.
> >(by an AAA infra etc.)
> >>
> >
> >Woo, I agree with you.
> >
> >Charlie,
> >
> >To add even if the MN-AAA is not removed, since the HA will not authenticate
> >based of HA-AAA, how will the
> >HA authenticate the MN? Is the assumption that HA will be instructed to by the
> >HAAA to accept the MN? (Note: I am not
> >sure if this is good or bad.  I would like to understand the motivation for the
> >Statement about HA-MN being optional).
> >
> >Thanks
> >Gopal
> >
> >
> >>If the MN-AAA authentication is removed, and there is no MN-HA authentication,
> >by what means will the HA be able to authenticate the message ? Are you not
> >assuming that in such a case the MN-HA authentication is used ?
> >>
> >>My understanding leads me to assume that in case either an MN-AAA
> >authentication or MN-HA authentication extension will always be in a
> >registration request received by the Home Agent. But the current wording of the
> >document seems to able to lead to cases where the FA implementation could remove
> >an MN-AAA authentication extension even when an MN-HA authentication does not
> >exist.
> >>
> >>Please correct me if I'm wrong again.
> >>(by the way then I believe the wording of
> >>
> >>"..........
> >>   Since the Challenge extension, and the authentication extension that
> >>   is used by the Mobile Node to satisfy the challenge, both follow
> >>   the Mobile-Home Authentication extension whenever the latter is
> >>   present, the Foreign Agent MAY remove the Challenge Extension and
> >>   the applicable authentication from the Registration Request without
> >>   disturbing the authentication value computed by the Mobile Node for
> >>   use by the Home Agent.
> >>........"
> >>
> >>should be changed (Is the first sentence grammatically correct ?)
> >>to reflect the fact that the MN-AAA authentication can only be removed if there
> >is a MN-HA authentication extension.
> >>)
> >>
> >>cheers
> >>
> >>Woojune Kim,
> >>Senior Engineer
> >>Samsung Electronics Ltd.
> >>tel : +82-342-779-8526
> >>hp : +82-11-368-7480
> >>e-mail : keg@telecom.samsung.co.kr
> >>
> >>
> >>>
> >>>Hello,
> >>>
> >>>Woo-June Kim wrote:
> >>>
> >>>> To me even if FAC is used, I don't quite see how it nullfies the need for
> >>>> the MN-HA authentication field.
> >>>
> >>>The Challenge specification was written after the MN-NAI specification,
> >>>and the MN-NAI specification allows a MN-AAA authentication extension
> >>>to take the place of the MN-HA authentication extension.
> >>>
> >>>Regards,
> >>>Charlie P.
> >>>
> >>
> >Thank You.
> >Regards,
> >Gopal
> >-------------------------------------------------------------------------------------------------------------
> >
> >Gopal Dommety
> >408 525 1404
> >gdommety@cisco.com
> >Cisco Systems, San Jose, CA, 95051

--
        Tom Weckström           tweckstr@cc.hut.fi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 17:40:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10287
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 17:40:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8ED2AE0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:36:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78607 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 17:35:24 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8480AC90@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:35:23
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id OAA10713; Tue, 7 Mar 2000 14:39:04
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          OAA01274; Tue, 7 Mar 2000 14:39:03 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id OAA15712; Tue, 7 Mar 2000 14:39:02
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3I9Rg8KO0DP/TMKpYsjlWg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003072239.OAA15712@nasnfs.eng.sun.com>
Date:         Tue, 7 Mar 2000 14:40:36 -0800
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@eng.sun.com>
Subject:      Re: [MOBILE-IP] charter update
X-To:         jwillkie@qualcomm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Jim,

Thanx for your reply.

>>The example of CDMA networks is somewhat unclear, and seems to lay between
>>these two cases. These networks typically have a requirement for very
>>fast handoff and stringent QoS guarantees because they are primarily voice.
>
>It is true re: fast handoff and QoS but these aspects occur at the physical
>layer. A packet data stream over CDMA would not be subject to either of
>these conditions as they occur below L2. Packet mobility-related handoff
>occurs at IWF (or PDSN) boundaries and only occur at boundaries.
>

I was speaking about packetized voice in the RAN, not strictly packet
data bound for the Internet. What I was trying to describe was a RAN in which
the transmitters are sending a stream of packets back through the RAN to a
controller that selects one for the core network and, conversely, in which a
controller is splitting packets as they come off the core network and sending
multiple streams into the RAN to the transmitters. The packets can be either
AAL2/ATM (as in the release 99 3GPP network) or, hypothetically, IP. I was not
speaking about what happens after the packets go on the air.

>>They
>>also don't obey the subnet model very well, because there can be multiple
>>physical packet streams coming from/going to a mobile node through individual
>>radio access points that logically correspond to a single packet stream
>>outgoing
>>from the mobile node or incoming from the corresponding node.
>
>This statement is not accurate. Now it is true that at the physical layer
>CDMA when a user on a traffic channel is in a soft or softer handoff
>condition (ie. connected to multiple BTSs) that traffic channel frames are
>moving between the mobile and multiple BTSs, BUT these are in fact the same
>frames coming from multiple sites. For voice they are the same voice
>frames, for data they are the same packets. In either case the the CDMA
>physical layer 'merges' them together. In summary this situation should not
>be considered multiple packets coming/going because they are not.
>

My understanding is that a CDMA mobile terminal can be receiving up
to 6 streams at once, and, as you say, uses an L1 algorithm to
combine these streams into a single voice or data packet that the
upper layers see.

But as far as the network is concerned, these multiple streams need to
be generated from a single stream incoming from the core network. Conversely,
the outgoing streams received by the transmitters need to be combined
at the controller into a single stream which the core network sees.

Since the RAN is running a standard, wired L1/L2 (and potentially L3) the
splitting and combining must be done on top of a standard, wired protocol, no?

Similarly, when soft handoff occurs, the RAN must arrange for the
incoming and outgoing streams to follow the mobile. My understanding
is that this is currently done with proprietary RAN protocols that
each individual radio vendor supplies.

>>The multiple streams get combined in the radio access network into a single
>>packet stream or on entrance to the radio access network are generated by
>>splitting the single stream coming from the corresponding node.
>
>Ahh, this is true.
>
>>The mobile IP framework doesn't handle this case very well.
>
>This is where I do not agree. MobileIP has no idea the combining/separating
>has even occured. So mobileIP has no problem with this as soft/softer
>handoff would only occur within a single operators equipment (so a single
>PDSN would be the case for all soft/softer handoff situations).
>

Agreeed, that is the case for packet data generated in user applications
on the mobile terminal that is bound for the Internet. But consider somewhat
lower down, where what's flowing over the wire is not the packets generated
by the user's application on the mobile terminal, but rather shaped
radio packets generated by the controller. These radio
shaped packets are unpacked and transmitted and reassembled at the
mobile terminal by the L1 process you describe above to generate
either packet data or voice packets. Similarly in the opposite direction.

The upshot of this is that the RAN considered as a separate network (i.e.
not as an addressable part of the global Internet) has multiple data
streams that physically get combined at L1 in the mobile terminal
into a single logical data stream. And these multiple streams move as the
mobile terminal moves. The issue I've been trying to present is that
the movement of these multiple streams in the RAN are not well
modelled by the current mobile IP architecture.

>So in summary the CDMA network does NOT introduce additional complexity for
>network layer mobility.
>

I agree if you consider the PDSN (or SGSN and GGSN in GPRS) and
connectivity to the Internet. But if you look at the RAN as a self contained
network, and consider soft handoff for mobility, then I would maintain that it
does introduce more complexity, due to the multiple incoming and
outgoing streams (macrodiversity in the cellular jargon).

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 18:16:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22495
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 18:16:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B72F94D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 18:12:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78713 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 18:11:05 -0500
Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1B396480@standards.nortelnetworks.com>; Tue, 7 Mar 2000 18:01:04
          -0500
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id
          RAA05177 for <mobile-ip@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar
          2000 17:59:29 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76),
          claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by
          ns01.newbridge.com, id smtpdAAA0HE5.Q; Tue Mar  7 17:59:22 2000
Received: from [138.120.49.10] by kanata-mh1.ca.newbridge.com with ESMTP for
          mobile-ip@standards.nortelnetworks.com; Tue, 7 Mar 2000 18:04:44 -0500
Received: (from smap@localhost) by affserver.ca.newbridge.com. (8.8.5/8.8.5) id
          SAA21834 for <mobile-ip@standards.nortelnetworks.com>; Tue, 7 Mar
          2000 18:05:03 -0500 (EST)
Received: from mail-router.bridgewatersys.com(192.168.150.1) by affserver via
          smap (V1.3) id sma021829; Tue Mar  7 18:04:57 2000
Received: from mjones by bridgewatersys.com (SMI-8.6/SMI-SVR4) id SAA17467;
          Tue, 7 Mar 2000 18:03:09 -0500
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-Type: multipart/signed; micalg=SHA1;
              protocol="application/x-pkcs7-signature";
              boundary="----=_NextPart_000_0182_01BF885F.DF5E40B0"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <018c01bf8889$c9367670$2096a8c0@bridgewatersys.com>
Date:         Tue, 7 Mar 2000 18:06:35 -0500
Reply-To: Mark Jones <mjones@BRIDGEWATERSYS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Mark Jones <mjones@BRIDGEWATERSYS.COM>
Subject:      [MOBILE-IP] Question on Mobile IP NAI format
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0182_01BF885F.DF5E40B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have a question on the 'Mobile IP Network Access Identifier for IPv4'
draft.

Section 2 of draft-ietf-mobileip-mn-nai-07.txt contains the following
statement:

   The Mobile Node NAI extension, shown in figure 1, contains the user
   and/or host name following the format defined in [1].

where reference [1] is to RFC2486: The Network Access Identifier.

However, an NAI of 'user and/or host name' is not consistent with the
definition for the NAI format in RFC2486 which defines the NAI as either
username or username@realm.

I assume that the Mobile Node NAI is still intended to uniquely identify
the user and not a host. Is this correct?

Regards,
       Mark

------=_NextPart_000_0182_01BF885F.DF5E40B0
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRjCCAtQw
ggI9oAMCAQICAwEsXTANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0
aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMt
VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MB4XDTk5MDcyOTE1
MTYyM1oXDTAwMDcyODE1MTYyM1owSzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEo
MCYGCSqGSIb3DQEJARYZbWpvbmVzQGJyaWRnZXdhdGVyc3lzLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAoD3PY7pGnUQm7j+OlCUQ3lSQJ9Hdv3olY7BEBzN8NT+Izgw9DmFuXNqTzRyE
Dtu4l5tRvOtw/E24eQv1+BRE4674gC30jVy1ayPUh+0tZ2OGc0Umhck1biI+0q1xrIeOVgCvV5YO
A3oNkOSrU9VKs+NVZWDxh1OFz2E71emkQEMCAwEAAaNXMFUwJAYDVR0RBB0wG4EZbWpvbmVzQGJy
aWRnZXdhdGVyc3lzLmNvbTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFP4+YJxrjA+w2DPGysYe
WLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAGUvTC9Jm888K6SzsyCH6WE5EMWusohcqq97dKlhsVeA
Bc0tl6E7zGK9wDA2U2bEDVWSMnk1kf4Z8jxuPvZCYmDigP7ImNzoi6l4APemjq+aoz5hFwbqGc4P
yF29Ca3QfAXdqsF1VjwImAAL/WcNvL0v/ZpQ5+moXmZCFpcYBtOqMIIDLTCCApagAwIBAgIBADAN
BgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy
dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X
DTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp
bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG2
6nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDim
AKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkC
AwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk
8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBH
H7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRznei
gTCCAzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYxNzU1MzRaFw0wMDA5MTUxNzU1MzRaMIG5MQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45
LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAx
OTk4LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSl5dTU0F8IAu4HIX0kv6trjh7r
IAcCFYRrj9CTJB8bne5osrksT+mTZxcQFx6h+UNBI7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQe
lx6w4ribwQSaMtA8CWxP5DVP8Ha/ABMDT0UIYPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGj
NzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4w
DQYJKoZIhvcNAQEEBQADgYEALMeCHwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB
4VWCeasKKabVDOFXKD6P+bvV3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IGjtKN
VruV3tsMZQXelZ4C3VMXvr78a8MaInoUK2G9wp9eeloxggL4MIIC9AIBATCBwTCBuTELMAkGA1UE
BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNV
BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4x
NiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2AgMBLF0wCQYFKw4DAhoFAKCCAYwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDAwMzA3MjMwNjM0WjAjBgkqhkiG9w0BCQQxFgQUGNDWXP0XnSAjPJKex1Y9
sTUj+xYwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgdIGCSsGAQQBgjcQBDGBxDCB
wTCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFu
dmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNB
IElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJT
QSBJc3N1ZXIgMTk5OC45LjE2AgMBLF0wDQYJKoZIhvcNAQEBBQAEgYBAZCptyiOGtBAMsBQiF4H1
iny4fIXHwRVBgE/VMpnTO4dkLtm4bG1Fwh+XEAAXJiv3Va24Sf+Kp13zfsYImR0pLCet523RGN55
MPtwnJuP6bw5rTuu/HeZGLi5eXpvfnr90X8BhxBDcqRdrlivS+CJgLZM+oBXckbhbjaMBOdtGQAA
AAAAAA==

------=_NextPart_000_0182_01BF885F.DF5E40B0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 19:33:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12445
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 19:33:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59D06110@standards.nortelnetworks.com>; Tue, 7 Mar 2000 19:28:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78851 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 19:28:07 -0500
Received: from telecom.samsung.co.kr (165.213.221.4) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DD3D02D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000
          19:18:05 -0500
Received: from keg ( [165.213.177.180] (may be forged)) by
          telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id JAA02913 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Mar 2000 09:21:36
          +0900 (KST)
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Message-ID:  <00ed01bf8893$67296780$b4b1d5a5@keg.telecom.samsung.co.kr>
Date:         Wed, 8 Mar 2000 09:15:22 +0900
Reply-To: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
Subject:      Re: [MOBILE-IP] MOBILE-IP] Are Mobile-Home Authentication's
              optional ?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA12445

Pat, 

From your answer I can see that you are considering a wider possibility - the chance that even the HA may not be trusted by the MN. A case that becomes possible when dynamic HA allocation becomes available (and not according to the scheme of using the subnet broadcast address as originally mentioned in RFC2002 as that case could assume a trust relationship between the HA and the MN).

But as Gopal mentioned in the earlier attached e-mail, how is the information that the MN's registration request trustworthy going to be conveyed to the HA in the absence of a

1) MN-HAAA authentication
2) MN-HA authentication.

It seems to me the HAAA would have to tell the HA by some means that "in the future you will receive a registration request from MN and it has already been authenticated at the FA". Which raises the question of identifying the message securely. i.e. When the request is received how can the HA be sure it is the request the HAAA was talking about ? What if there was an imposter in the middle ? 

It seems to me the only reasonable answer would be to include the MN-HAAA authentication extension in the registration request to the HA. Then for such cases as you mention where the HA is assigned dynamically (including cases where the HA is now in a domain with no trust relationship with the MN) then the MN may be authenticated by the MN-HAAA authentication. For cases where there is a preexisting trust relationship, the MN-HA authentication field would/could be used. 

If this scenario is followed, under what conditions can the MN-HAAA authentication extension be removed by the FA ? It seems to me, only when there is a MN-HA authentiation extentsion, implying the MN has a trust relationship with the HA. If there is no MN-HA authentication extension, the MN-HAAA authentication must be left in the message for the HA to use for verification. If the HAAA can somehow instruct the HA to except messages (as mentioned by Gopal) fine, but if not, the HA goes through the whole authentication routine again with the MN-HAAA authentication extension.

Of course if a framework like DIAMETER  was used, whereby the AAA will relay the registration messages itself, your statements above are fundamentally correct. But if we stay with the model where the path of the registraion request/reply messages is different from the AAA authentication path, we end up with the problem that both Gopal and I have raised.

cheers

Woojune Kim



>Since the HA inherently trusts its AAA server (and if it doesn't then we have
>a problem), if the AAAH states that the Mobile Node was authenticated, why
>does the HA have to also authenticate the user?
>
>Further, if we mandate MN-HA, then we need to push the Mobile Node's secret to
>the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
>domain), why would you want to provide the MN's password to it?
>
>PatC
>>>
>>>Anyway your answer brings more questions to my mind.
>>>
>>>The challenge/response draft says the MN-AAA authentication extension can be
>>removed by the FA after authentication is carried out by some means at the FA.
>>(by an AAA infra etc.)
>>>
>>
>>Woo, I agree with you.
>>
>>Charlie,
>>
>>To add even if the MN-AAA is not removed, since the HA will not authenticate
>>based of HA-AAA, how will the
>>HA authenticate the MN? Is the assumption that HA will be instructed to by the
>>HAAA to accept the MN? (Note: I am not
>>sure if this is good or bad.  I would like to understand the motivation for the
>>Statement about HA-MN being optional).
>>
>>Thanks
>>Gopal
>>
>>
>>>If the MN-AAA authentication is removed, and there is no MN-HA authentication,
>>by what means will the HA be able to authenticate the message ? Are you not
>>assuming that in such a case the MN-HA authentication is used ?
>>>
>>>My understanding leads me to assume that in case either an MN-AAA
>>authentication or MN-HA authentication extension will always be in a
>>registration request received by the Home Agent. But the current wording of the
>>document seems to able to lead to cases where the FA implementation could remove
>>an MN-AAA authentication extension even when an MN-HA authentication does not
>>exist.
>>>
>>>Please correct me if I'm wrong again.
>>>(by the way then I believe the wording of
>>>
>>>"..........
>>>   Since the Challenge extension, and the authentication extension that
>>>   is used by the Mobile Node to satisfy the challenge, both follow
>>>   the Mobile-Home Authentication extension whenever the latter is
>>>   present, the Foreign Agent MAY remove the Challenge Extension and
>>>   the applicable authentication from the Registration Request without
>>>   disturbing the authentication value computed by the Mobile Node for
>>>   use by the Home Agent.
>>>........"
>>>
>>>should be changed (Is the first sentence grammatically correct ?)
>>>to reflect the fact that the MN-AAA authentication can only be removed if there
>>is a MN-HA authentication extension.
>>>)
>>>
>>>cheers
>>>
>>>Woojune Kim,
>>>Senior Engineer
>>>Samsung Electronics Ltd.
>>>tel : +82-342-779-8526
>>>hp : +82-11-368-7480
>>>e-mail : keg@telecom.samsung.co.kr
>>>
>>>
>>>>
>>>>Hello,
>>>>
>>>>Woo-June Kim wrote:
>>>>
>>>>> To me even if FAC is used, I don't quite see how it nullfies the need for
>>>>> the MN-HA authentication field.
>>>>
>>>>The Challenge specification was written after the MN-NAI specification,
>>>>and the MN-NAI specification allows a MN-AAA authentication extension
>>>>to take the place of the MN-HA authentication extension.
>>>>
>>>>Regards,
>>>>Charlie P.
>>>>
>>>
>>Thank You.
>>Regards,
>>Gopal
>>-------------------------------------------------------------------------------------------------------------
>>
>>Gopal Dommety
>>408 525 1404
>>gdommety@cisco.com
>>Cisco Systems, San Jose, CA, 95051
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar  7 19:36:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13420
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 7 Mar 2000 19:36:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A17AA1B0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 19:30:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 78857 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 19:28:47 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5BC50520@standards.nortelnetworks.com>; Tue, 7 Mar 2000 19:28:47
          -0500
Received: from gdommety-pc2 (dhcp-sjc9-233-208.cisco.com [171.71.233.208]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          QAA14737 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 7 Mar
          2000 16:32:36 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003080032.QAA14737@omega.cisco.com>
Date:         Tue, 7 Mar 2000 16:44:59 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      [MOBILE-IP] GRE Addendum
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello:

        As requested  by IESG, I  written up a preliminary  version of
 the GRE addendum.  Please provide your comments.  As you go through the
 draft   at   places  identified   by   #   there   are  request   for
 comments. please give your opinion.

Thanks
Gopal




Network Working Group                                      Gopal Dommety
INTERNET DRAFT                                             cisco Systems
February 2000

Expires September 2000

                Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-00.txt

All comments/discussion of this draft should be directed to gre@ops.ietf.org


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 working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol.

Dommety                                                           [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the
   requirements of the specification.

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    The proposed GRE header will have the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible
      with RFC 1701 [2].

2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel.

2.2. Sequence Number (4 octets)

    The Sequence Number  field is divided into two  sub-fields (Tx and
    Rx sequence number). These subfields are inserted by the encapsulator
    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
    be used by the receiver to establish the  order in which  packets
    have been  transmitted from the  encapsulator  to  the  receiver.
    The intended  use  of  the Tx Sequence  Field is  to provide
    unreliable and in-order delivery.   If the Key  present bit (bit 2)
    is set, the sequence number is specific to the sub-tunnel identified
    by the Key field.

    The Tx sequence number  value ranges from 1 to  65535. The first
    datagram is sent with a Tx sequence number of 1. The Tx sequence
    number is thus a free running counter represented modulo 65536,
    with the exception that 1 is used when modulo 65536 results in 0
    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.

#Q The Rx can be the Tx  sequence number of the last successfully decap
  pack.  And  say  that  how  you  use  this  info  is  implementation
  dependent. To avoid controversy I am currently saying Rx sequence no
  is set to 0. Comments?


    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering
    schemes are outside the scope
    of  this  document. Note that the  Tx sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the Tx sequence
   number  of  the  received packet  is  lesser than or equal to  the Tx
   sequence  number   of last  successfully  decapsulated
   packet. The  Tx sequence number  of a received message is considered
   less than or equal to the last successfully received Tx sequence number
   if its value lies in the range of the last received Tx sequence number
   and the preceding 32766 values, inclusive.  For example, if the last
   successfully received Tx sequence number was 15, then messages with Tx
   sequence numbers 1 through 15, as well as 32784 through 65535, would be
   considered less than or equal. Such a message would be considered an
   out-of-sequence packet and  ignored from processing.

    If the received packet is an in-sequence packet, it is successfully
    de capsulated. Note that  the TX sequence number is  used to detect
    lost packets and/or restore the original sequence of packets (with
    buffering) that may have been reordered during transport.

#C I have considered  trying to have a different  starting point for TX
sequence nos  during rollover and initial starting  point.  This would
let a node  identify if the other end  reset (like agent advertisement
sequence no to identify reboot and normal rollover). This is useful if
we keep turning on and off sequence nos option in a tunnel. Comments?


3. IANA Considerations

4. Acknowledgments

   The author  would like to thank  .......................  for their
   useful discussions.

5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
   October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.


Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: gdommety@cisco.com

Dommety





Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 00:55:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14404
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 00:55:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6840D8B0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 0:51:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79255 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 00:50:37 -0500
Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.519837C0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 0:50:37
          -0500
Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List
          Logging/8.8.8) id VAA25162 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 21:54:27
          -0800 (PST)
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003080554.VAA25162@sigma.cisco.com>
Date:         Tue, 7 Mar 2000 21:54:27 -0800
Reply-To: "Kent K. Leung" <kleung@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Kent K. Leung" <kleung@CISCO.COM>
Subject:      Re: [MOBILE-IP] RFC2002 bis
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <51F347B016ADD011963200805FC1456204BCBF5F@email1.wes.mot.com>
              from "Roberts Phil-QA3445" at Feb 08, 2000 03:15:57 PM
Content-Transfer-Encoding: 7bit

One area that's not covered by RFC2002bis is how Mobile Node
as well as Foreign Agent should deal with Mobile-Home Authentication
Extension (MHAE) when FA replies with error code.  There are 2 scenarios
when FA rejects registration: 1) FA denies registration request
(ie requested lifetime greater than advertised) and 2) FA sends
rejection when HA reply is bad (ie Foreign-Home Authentication
Extension check fails).  In either case, the authenticator in
Mobile-Home Authentication Extension is invalid when received by
MN.

So when registration is rejected by FA, the MN will silently
discard reply because authenticator is invalid.

Seems like some MN implementation skips MHAE if the error code
is from FA.  But then this can lead to bad guy sending rejections
even when registration being accepted by HA, maybe a little later.
One possible solution is that MN can believe rejection reply if
MFAE exists or after it allows enough time for reply from HA to arrive.

We need some more information in section 3.6.2.3 "Registration Request
Denied" in how Mobile Node handle denials from FA, section 3.7.2.3
"Denying Invalid Requests" and section 3.7.3 "Receiving Registration
Replies" in how FA deal with MHAE when generating a rejection reply.

-- Kent --

>
> It's important to turn this around quickly if we want it to replace 2002 and
> then move this from proposed standard to draft standard.  We discussed in
> Washington about the amount of work that will be involved from moving to
> proposed to draft and agreed that we should update 2002 while working on
> getting enough implementations to move to draft standard.  Getting the
> replacement done quickly would allow us to get to draft standard this year,
> hopefully.
>
> Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 07:15:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11915
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 07:15:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6714C1B0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 7:10:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79533 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 07:08:43 -0500
Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.22DEE750@standards.nortelnetworks.com>; Wed, 8 Mar 2000 7:08:42
          -0500
Received: from mpsr015.sbell.com.cn (mpsr015.sbell.com.cn [138.203.222.240]) by
          mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id UAA09598 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Mar 2000 20:05:06
          +0800 (CST)
Received: from xstation ([172.16.200.222]) by mpsr015.sbell.com.cn
          (8.8.8+Sun/8.8.8) with SMTP id UAA05973 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Mar 2000 20:05:57
          +0800 (CST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0031_01BF893A.F6FE1B60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <003401bf88f7$e9bb7760$0501a8c0@sbell.com.cn>
Date:         Wed, 8 Mar 2000 20:14:53 +0800
Reply-To: Xu Song <SRDXS@SBELL.COM.CN>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Xu Song <SRDXS@SBELL.COM.CN>
Subject:      [MOBILE-IP] Test
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01BF893A.F6FE1B60
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0031_01BF893A.F6FE1B60--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 09:10:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20785
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 09:10:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88957770@standards.nortelnetworks.com>; Wed, 8 Mar 2000 9:06:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79801 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 09:04:19 -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.49862020@standards.nortelnetworks.com>;
          Wed, 8 Mar 2000 9:04:19 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id HAA23583 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Mar 2000 07:08:08
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          GAA18749; Wed, 8 Mar 2000 06:08:07 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id GAA29507; Wed,
          8 Mar 2000 06:07:46 -0800 (PST)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID:  <200003081407.GAA29507@nasnfs.eng.sun.com>
Date:         Wed, 8 Mar 2000 06:03:11 -0800
Reply-To: pcalhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Are Mobile-Home Authentication's optional ?
X-To:         Tom =?iso-8859-1?Q?Weckstr=F6m?= <tweckstr@cc.hut.fi>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

My appologies, inherently trusts in no way meant, at least to me, that no
security associations are needed between two nodes. I believe, and the AAA
protocol that I have in mind, that AAA does require security (even within a
network).

What I meant, however, was that a HOme Agent can trust that if it's AAAH
server states that a Mobile Node is authenticated, it doesn't have to
worry about the AAAH performing fraud.

PatC
>Pat,
>
>This is just nitpicking about your trust statement...
>
>80% - or even 90% of security attacks tend to come from inside. I would
>not state that HA trusts AAAH inherently without any security
>associations (i.e. shared secrets, public key systems, certificates,...)
>It would be far too easy to play HA or AAAH inside the Home Network, if
>no verification mechanism for the trust relationship existed.
>
>Regards,
>         Tom
>
>
>Patrice Calhoun wrote:
>>
>> Since the HA inherently trusts its AAA server (and if it doesn't then we have
>> a problem), if the AAAH states that the Mobile Node was authenticated, why
>> does the HA have to also authenticate the user?
>>
>> Further, if we mandate MN-HA, then we need to push the Mobile Node's secret
>to
>> the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
>> domain), why would you want to provide the MN's password to it?
>>
>> PatC
>> >>
>> >>Anyway your answer brings more questions to my mind.
>> >>
>> >>The challenge/response draft says the MN-AAA authentication extension can
>be
>> >removed by the FA after authentication is carried out by some means at the
>FA.
>> >(by an AAA infra etc.)
>> >>
>> >
>> >Woo, I agree with you.
>> >
>> >Charlie,
>> >
>> >To add even if the MN-AAA is not removed, since the HA will not authenticate
>> >based of HA-AAA, how will the
>> >HA authenticate the MN? Is the assumption that HA will be instructed to by
>the
>> >HAAA to accept the MN? (Note: I am not
>> >sure if this is good or bad.  I would like to understand the motivation for
>the
>> >Statement about HA-MN being optional).
>> >
>> >Thanks
>> >Gopal
>> >
>> >
>> >>If the MN-AAA authentication is removed, and there is no MN-HA
>authentication,
>> >by what means will the HA be able to authenticate the message ? Are you not
>> >assuming that in such a case the MN-HA authentication is used ?
>> >>
>> >>My understanding leads me to assume that in case either an MN-AAA
>> >authentication or MN-HA authentication extension will always be in a
>> >registration request received by the Home Agent. But the current wording of
>the
>> >document seems to able to lead to cases where the FA implementation could
>remove
>> >an MN-AAA authentication extension even when an MN-HA authentication does
>not
>> >exist.
>> >>
>> >>Please correct me if I'm wrong again.
>> >>(by the way then I believe the wording of
>> >>
>> >>"..........
>> >>   Since the Challenge extension, and the authentication extension that
>> >>   is used by the Mobile Node to satisfy the challenge, both follow
>> >>   the Mobile-Home Authentication extension whenever the latter is
>> >>   present, the Foreign Agent MAY remove the Challenge Extension and
>> >>   the applicable authentication from the Registration Request without
>> >>   disturbing the authentication value computed by the Mobile Node for
>> >>   use by the Home Agent.
>> >>........"
>> >>
>> >>should be changed (Is the first sentence grammatically correct ?)
>> >>to reflect the fact that the MN-AAA authentication can only be removed if
>there
>> >is a MN-HA authentication extension.
>> >>)
>> >>
>> >>cheers
>> >>
>> >>Woojune Kim,
>> >>Senior Engineer
>> >>Samsung Electronics Ltd.
>> >>tel : +82-342-779-8526
>> >>hp : +82-11-368-7480
>> >>e-mail : keg@telecom.samsung.co.kr
>> >>
>> >>
>> >>>
>> >>>Hello,
>> >>>
>> >>>Woo-June Kim wrote:
>> >>>
>> >>>> To me even if FAC is used, I don't quite see how it nullfies the need
>for
>> >>>> the MN-HA authentication field.
>> >>>
>> >>>The Challenge specification was written after the MN-NAI specification,
>> >>>and the MN-NAI specification allows a MN-AAA authentication extension
>> >>>to take the place of the MN-HA authentication extension.
>> >>>
>> >>>Regards,
>> >>>Charlie P.
>> >>>
>> >>
>> >Thank You.
>> >Regards,
>> >Gopal
>>
>>-------------------------------------------------------------------------------------------------------------
>> >
>> >Gopal Dommety
>> >408 525 1404
>> >gdommety@cisco.com
>> >Cisco Systems, San Jose, CA, 95051
>
>--
>        Tom Weckström           tweckstr@cc.hut.fi


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 11:02:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01411
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 11:02:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36637E60@standards.nortelnetworks.com>; Wed, 8 Mar 2000 10:58:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79948 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 10:56:42 -0500
Received: from emrys.qualcomm.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FC69E140@standards.nortelnetworks.com>; Wed, 8 Mar 2000 10:56:41
          -0500
Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by
          emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id IAA21057; Wed,
          8 Mar 2000 08:00:30 -0800 (PST)
X-Sender: jwillkie@mail1.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000307150344.00d76660@mail1.qualcomm.com>
Date:         Wed, 8 Mar 2000 07:59:51 -0800
Reply-To: Jim Willkie <jwillkie@QUALCOMM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jim Willkie <jwillkie@QUALCOMM.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         James Kempf <James.Kempf@eng.sun.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003072239.OAA15712@nasnfs.eng.sun.com>

At 02:40 PM 3/7/00 -0800, James Kempf wrote:
>I agree if you consider the PDSN (or SGSN and GGSN in GPRS) and
>connectivity to the Internet. But if you look at the RAN as a self contained
>network, and consider soft handoff for mobility, then I would maintain
that it
>does introduce more complexity, due to the multiple incoming and
>outgoing streams (macrodiversity in the cellular jargon).

James:

A CDMA network handles soft handoff within the RAN, so network components
outside the RAN should not be involved in soft handoff issues. Now an all
IP network in the RAN would introduce some hassles. I would think that this
is a shortcoming of 'all IP' within a RAN and not a complexity of CDMA.
Perhaps people that are on the 'all IP' bandwagon should consider that and
weigh the benefits versus the hassles of 'all IP'.

Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 11:33:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12896
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 11:33:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CBFA910@standards.nortelnetworks.com>; Wed, 8 Mar 2000 11:29:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 79985 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 11:28:20 -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.67D26200@standards.nortelnetworks.com>; Wed, 8 Mar 2000 11:28:20
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id KAA01917; Wed, 8 Mar 2000 10:32:03 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          8625689C.005AF389 ; Wed, 8 Mar 2000 10:33:25 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <8625689C.005AEF0A.00@mwgate02.mw.3com.com>
Date:         Wed, 8 Mar 2000 10:33:59 -0600
Reply-To: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Jim Willkie <jwillkie@QUALCOMM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Jim,
Depending on which all IP you are talking about, it is not true that all all IP
schemes will introduce the hassles.

--Yingchun.




Jim Willkie <jwillkie@QUALCOMM.COM> on 03/08/2000 09:59:51 AM

Please respond to Jim Willkie <jwillkie@QUALCOMM.COM>

Sent by:  Jim Willkie <jwillkie@QUALCOMM.COM>


To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] charter update



At 02:40 PM 3/7/00 -0800, James Kempf wrote:
>I agree if you consider the PDSN (or SGSN and GGSN in GPRS) and
>connectivity to the Internet. But if you look at the RAN as a self contained
>network, and consider soft handoff for mobility, then I would maintain
that it
>does introduce more complexity, due to the multiple incoming and
>outgoing streams (macrodiversity in the cellular jargon).

James:

A CDMA network handles soft handoff within the RAN, so network components
outside the RAN should not be involved in soft handoff issues. Now an all
IP network in the RAN would introduce some hassles. I would think that this
is a shortcoming of 'all IP' within a RAN and not a complexity of CDMA.
Perhaps people that are on the 'all IP' bandwagon should consider that and
weigh the benefits versus the hassles of 'all IP'.

Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 12:03:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23526
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 12:03:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C354E8B0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 11:59:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80108 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 11:58:29 -0500
Received: from emrys.qualcomm.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9E713E90@standards.nortelnetworks.com>; Wed, 8 Mar 2000 11:58:29
          -0500
Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by
          emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id JAA01663; Wed,
          8 Mar 2000 09:02:18 -0800 (PST)
X-Sender: jwillkie@mail1.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000308090021.00d9ab60@mail1.qualcomm.com>
Date:         Wed, 8 Mar 2000 09:01:39 -0800
Reply-To: Jim Willkie <jwillkie@QUALCOMM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Jim Willkie <jwillkie@QUALCOMM.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <8625689C.005AEF0A.00@mwgate02.mw.3com.com>

At 10:33 AM 3/8/00 -0600, Yingchun Xu wrote:
>Jim,
>Depending on which all IP you are talking about, it is not true that all
all IP
>schemes will introduce the hassles.

Good. Thanks for the clarification, because the concept of 'all IP' is
good. Perhaps the ''all IP' schemes that introduce hassle are deficient?

Jim W

>Jim Willkie <jwillkie@QUALCOMM.COM> on 03/08/2000 09:59:51 AM
>
>Please respond to Jim Willkie <jwillkie@QUALCOMM.COM>
>
>Sent by:  Jim Willkie <jwillkie@QUALCOMM.COM>
>
>
>To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>cc:    (Yingchun Xu/MW/US/3Com)
>Subject:  Re: [MOBILE-IP] charter update
>
>
>
>At 02:40 PM 3/7/00 -0800, James Kempf wrote:
>>I agree if you consider the PDSN (or SGSN and GGSN in GPRS) and
>>connectivity to the Internet. But if you look at the RAN as a self contained
>>network, and consider soft handoff for mobility, then I would maintain
>that it
>>does introduce more complexity, due to the multiple incoming and
>>outgoing streams (macrodiversity in the cellular jargon).
>
>James:
>
>A CDMA network handles soft handoff within the RAN, so network components
>outside the RAN should not be involved in soft handoff issues. Now an all
>IP network in the RAN would introduce some hassles. I would think that this
>is a shortcoming of 'all IP' within a RAN and not a complexity of CDMA.
>Perhaps people that are on the 'all IP' bandwagon should consider that and
>weigh the benefits versus the hassles of 'all IP'.
>
>Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 12:43:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07748
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 12:43:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39C25870@standards.nortelnetworks.com>; Wed, 8 Mar 2000 12:38:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80186 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 12:37:16 -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0930DFB0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 12:37:16
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id LAA08535; Wed, 8 Mar 2000 11:41:01 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          8625689C.006144DD ; Wed, 8 Mar 2000 11:42:26 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <8625689C.006142E5.00@mwgate02.mw.3com.com>
Date:         Wed, 8 Mar 2000 11:43:07 -0600
Reply-To: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Jim Willkie <jwillkie@QUALCOMM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Jim,
Give you another update. As I know upto today, there are three groups (MWIF, 3G
IP, TSG-ALL IP) working on "all IP" solution and every one of them has different
vision (or purpose). I heard another  one is coming in pipe (scary).  Sooner, we
need another one to unify all of them.

--Yingchun.




Jim Willkie <jwillkie@QUALCOMM.COM> on 03/08/2000 11:01:39 AM

Please respond to Jim Willkie <jwillkie@QUALCOMM.COM>

Sent by:  Jim Willkie <jwillkie@QUALCOMM.COM>


To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] charter update



At 10:33 AM 3/8/00 -0600, Yingchun Xu wrote:
>Jim,
>Depending on which all IP you are talking about, it is not true that all
all IP
>schemes will introduce the hassles.

Good. Thanks for the clarification, because the concept of 'all IP' is
good. Perhaps the ''all IP' schemes that introduce hassle are deficient?

Jim W

>Jim Willkie <jwillkie@QUALCOMM.COM> on 03/08/2000 09:59:51 AM
>
>Please respond to Jim Willkie <jwillkie@QUALCOMM.COM>
>
>Sent by:  Jim Willkie <jwillkie@QUALCOMM.COM>
>
>
>To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>cc:    (Yingchun Xu/MW/US/3Com)
>Subject:  Re: [MOBILE-IP] charter update
>
>
>
>At 02:40 PM 3/7/00 -0800, James Kempf wrote:
>>I agree if you consider the PDSN (or SGSN and GGSN in GPRS) and
>>connectivity to the Internet. But if you look at the RAN as a self contained
>>network, and consider soft handoff for mobility, then I would maintain
>that it
>>does introduce more complexity, due to the multiple incoming and
>>outgoing streams (macrodiversity in the cellular jargon).
>
>James:
>
>A CDMA network handles soft handoff within the RAN, so network components
>outside the RAN should not be involved in soft handoff issues. Now an all
>IP network in the RAN would introduce some hassles. I would think that this
>is a shortcoming of 'all IP' within a RAN and not a complexity of CDMA.
>Perhaps people that are on the 'all IP' bandwagon should consider that and
>weigh the benefits versus the hassles of 'all IP'.
>
>Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 15:17:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22062
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 15:17:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C77B6CA0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 15:12:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80396 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 15:11:47 -0500
Received: from alemail1.firewall.lucent.com (192.11.221.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9F233530@standards.nortelnetworks.com>; Wed, 8 Mar 2000
          15:11:47 -0500
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA15756
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 8 Mar 2000
          15:15:33 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id PAA15745 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Wed, 8 Mar 2000 15:15:33 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <1P822648>; Wed, 8 Mar 2000 20:15:32 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876A31@en0060exch001u.uk.lucent.com>
Date:         Wed, 8 Mar 2000 20:15:31 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Jim,
> Give you another update. As I know upto today, there are three groups
> (MWIF, 3G
> IP, TSG-ALL IP) working on "all IP" solution and every one of them has
> different
> vision (or purpose). I heard another  one is coming in pipe (scary).
> Sooner, we
> need another one to unify all of them.
>
> --Yingchun.
>
>
>
Yeah, and probably this is not the place where to update Jim
on this, I guess.

Alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 15:28:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25818
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 15:28:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.521A3890@standards.nortelnetworks.com>; Wed, 8 Mar 2000 15:23:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80399 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 15:22:37 -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BCCF2F80@standards.nortelnetworks.com>; Wed, 8 Mar 2000 15:12:36
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id OAA21326; Wed, 8 Mar 2000 14:16:21 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          8625689C.006F7F33 ; Wed, 8 Mar 2000 14:17:50 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <8625689C.006F7D2E.00@mwgate02.mw.3com.com>
Date:         Wed, 8 Mar 2000 14:18:03 -0600
Reply-To: Umamaheswar Achari Kakinada
              <Umamaheswar_Achari_Kakinada@MW.3COM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Umamaheswar Achari Kakinada
              <Umamaheswar_Achari_Kakinada@MW.3COM.COM>
Subject:      Re: [MOBILE-IP] GRE Addendum
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,
  I was looking at PPTP draft, which also uses the GRE  like encapsulation for
the PPP frames.
  Can the same mechanism be used here.  There the Key field is further devided
in to sub-fields to
  indicate  pay load length, etc. I also noticed your draft uses 2 bytes for
transmission and
  acknowledgement  sequence numbers,  where as in pptp these are 4 byte fields.

    I was wondering if having them consistent across two standards would help if
the PPTP
clients/servers also act as mobility agents.

Thanks

Achari





Gopal Dommety <gdommety@CISCO.COM> on 03/07/2000 06:44:59 PM

Please respond to Gopal Dommety <gdommety@CISCO.COM>

Sent by:  Gopal Dommety <gdommety@CISCO.COM>


To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (Umamaheswar Achari Kakinada/MW/US/3Com)
Subject:  [MOBILE-IP] GRE Addendum



Hello:

        As requested  by IESG, I  written up a preliminary  version of
 the GRE addendum.  Please provide your comments.  As you go through the
 draft   at   places  identified   by   #   there   are  request   for
 comments. please give your opinion.

Thanks
Gopal




Network Working Group                                      Gopal Dommety
INTERNET DRAFT                                             cisco Systems
February 2000

Expires September 2000

                Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-00.txt

All comments/discussion of this draft should be directed to gre@ops.ietf.org


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 working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol.

Dommety                                                           [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the
   requirements of the specification.

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    The proposed GRE header will have the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible
      with RFC 1701 [2].

2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel.

2.2. Sequence Number (4 octets)

    The Sequence Number  field is divided into two  sub-fields (Tx and
    Rx sequence number). These subfields are inserted by the encapsulator
    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
    be used by the receiver to establish the  order in which  packets
    have been  transmitted from the  encapsulator  to  the  receiver.
    The intended  use  of  the Tx Sequence  Field is  to provide
    unreliable and in-order delivery.   If the Key  present bit (bit 2)
    is set, the sequence number is specific to the sub-tunnel identified
    by the Key field.

    The Tx sequence number  value ranges from 1 to  65535. The first
    datagram is sent with a Tx sequence number of 1. The Tx sequence
    number is thus a free running counter represented modulo 65536,
    with the exception that 1 is used when modulo 65536 results in 0
    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.

#Q The Rx can be the Tx  sequence number of the last successfully decap
  pack.  And  say  that  how  you  use  this  info  is  implementation
  dependent. To avoid controversy I am currently saying Rx sequence no
  is set to 0. Comments?


    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering
    schemes are outside the scope
    of  this  document. Note that the  Tx sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the Tx sequence
   number  of  the  received packet  is  lesser than or equal to  the Tx
   sequence  number   of last  successfully  decapsulated
   packet. The  Tx sequence number  of a received message is considered
   less than or equal to the last successfully received Tx sequence number
   if its value lies in the range of the last received Tx sequence number
   and the preceding 32766 values, inclusive.  For example, if the last
   successfully received Tx sequence number was 15, then messages with Tx
   sequence numbers 1 through 15, as well as 32784 through 65535, would be
   considered less than or equal. Such a message would be considered an
   out-of-sequence packet and  ignored from processing.

    If the received packet is an in-sequence packet, it is successfully
    de capsulated. Note that  the TX sequence number is  used to detect
    lost packets and/or restore the original sequence of packets (with
    buffering) that may have been reordered during transport.

#C I have considered  trying to have a different  starting point for TX
sequence nos  during rollover and initial starting  point.  This would
let a node  identify if the other end  reset (like agent advertisement
sequence no to identify reboot and normal rollover). This is useful if
we keep turning on and off sequence nos option in a tunnel. Comments?


3. IANA Considerations

4. Acknowledgments

   The author  would like to thank  .......................  for their
   useful discussions.

5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
   October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.


Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: gdommety@cisco.com

Dommety





Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------


Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 16:02:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05773
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 16:02:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14E7C550@standards.nortelnetworks.com>; Wed, 8 Mar 2000 15:58:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80488 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 15:56:18 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D7408980@standards.nortelnetworks.com>; Wed, 8 Mar 2000 15:56:18
          -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA15038; Wed, 8 Mar 2000 13:00:08
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          MAA27014; Wed, 8 Mar 2000 12:59:49 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id MAA08810; Wed,
          8 Mar 2000 12:59:25 -0800 (PST)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-ID:  <200003082059.MAA08810@nasnfs.eng.sun.com>
Date:         Wed, 8 Mar 2000 13:04:29 -0800
Reply-To: pcalhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Question on Mobile IP NAI format
X-To:         Mark Jones <mjones@BRIDGEWATERSYS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Yes that is correct. Substitute the username for hostname.

PatC
>I have a question on the 'Mobile IP Network Access Identifier for IPv4'
>draft.
>
>Section 2 of draft-ietf-mobileip-mn-nai-07.txt contains the following
>statement:
>
>   The Mobile Node NAI extension, shown in figure 1, contains the user
>   and/or host name following the format defined in [1].
>
>where reference [1] is to RFC2486: The Network Access Identifier.
>
>However, an NAI of 'user and/or host name' is not consistent with the
>definition for the NAI format in RFC2486 which defines the NAI as either
>username or username@realm.
>
>I assume that the Mobile Node NAI is still intended to uniquely identify
>the user and not a host. Is this correct?
>
>Regards,
>       Mark


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 16:06:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07016
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 16:06:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A50981A0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 16:02:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80509 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 16:00:16 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6544E410@standards.nortelnetworks.com>; Wed, 8 Mar 2000 16:00:16
          -0500
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id NAA16850; Wed, 8 Mar 2000 13:04:03
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          NAA27920; Wed, 8 Mar 2000 13:03:46 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61])
          by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id NAA08916; Wed,
          8 Mar 2000 13:03:37 -0800 (PST)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-ID:  <200003082103.NAA08916@nasnfs.eng.sun.com>
Date:         Wed, 8 Mar 2000 13:08:27 -0800
Reply-To: pcalhoun@Eng.Sun.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Patrice Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] MOBILE-IP] Are Mobile-Home Authentication's
              optional ?
X-To:         Woo-June Kim <keg@TELECOM.SAMSUNG.CO.KR>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

One more time.....

I never stated the Mobile was inherently trusted. Yes, if the MN-HA is not
present, then the MN-AAA MUST be present (which is what started this whole
thread to begin with, I believe).

PatC
>Pat,
>
>From your answer I can see that you are considering a wider possibility - the
>chance that even the HA may not be trusted by the MN. A case that becomes
>possible when dynamic HA allocation becomes available (and not according to the
>scheme of using the subnet broadcast address as originally mentioned in RFC2002
>as that case could assume a trust relationship between the HA and the MN).
>
>But as Gopal mentioned in the earlier attached e-mail, how is the information
>that the MN's registration request trustworthy going to be conveyed to the HA in
>the absence of a
>
>1) MN-HAAA authentication
>2) MN-HA authentication.
>
>It seems to me the HAAA would have to tell the HA by some means that "in the
>future you will receive a registration request from MN and it has already been
>authenticated at the FA". Which raises the question of identifying the message
>securely. i.e. When the request is received how can the HA be sure it is the
>request the HAAA was talking about ? What if there was an imposter in the middle
>?
>
>It seems to me the only reasonable answer would be to include the MN-HAAA
>authentication extension in the registration request to the HA. Then for such
>cases as you mention where the HA is assigned dynamically (including cases where
>the HA is now in a domain with no trust relationship with the MN) then the MN
>may be authenticated by the MN-HAAA authentication. For cases where there is a
>preexisting trust relationship, the MN-HA authentication field would/could be
>used.
>
>If this scenario is followed, under what conditions can the MN-HAAA
>authentication extension be removed by the FA ? It seems to me, only when there
>is a MN-HA authentiation extentsion, implying the MN has a trust relationship
>with the HA. If there is no MN-HA authentication extension, the MN-HAAA
>authentication must be left in the message for the HA to use for verification.
>If the HAAA can somehow instruct the HA to except messages (as mentioned by
>Gopal) fine, but if not, the HA goes through the whole authentication routine
>again with the MN-HAAA authentication extension.
>
>Of course if a framework like DIAMETER  was used, whereby the AAA will relay the
>registration messages itself, your statements above are fundamentally correct.
>But if we stay with the model where the path of the registraion request/reply
>messages is different from the AAA authentication path, we end up with the
>problem that both Gopal and I have raised.
>
>cheers
>
>Woojune Kim
>
>
>
>>Since the HA inherently trusts its AAA server (and if it doesn't then we have
>>a problem), if the AAAH states that the Mobile Node was authenticated, why
>>does the HA have to also authenticate the user?
>>
>>Further, if we mandate MN-HA, then we need to push the Mobile Node's secret to
>>the HA, and if the HA lives in a non-trusted domain (e.g. HA in foreign
>>domain), why would you want to provide the MN's password to it?
>>
>>PatC
>>>>
>>>>Anyway your answer brings more questions to my mind.
>>>>
>>>>The challenge/response draft says the MN-AAA authentication extension can be
>>>removed by the FA after authentication is carried out by some means at the
>FA.
>>>(by an AAA infra etc.)
>>>>
>>>
>>>Woo, I agree with you.
>>>
>>>Charlie,
>>>
>>>To add even if the MN-AAA is not removed, since the HA will not authenticate
>>>based of HA-AAA, how will the
>>>HA authenticate the MN? Is the assumption that HA will be instructed to by
>the
>>>HAAA to accept the MN? (Note: I am not
>>>sure if this is good or bad.  I would like to understand the motivation for
>the
>>>Statement about HA-MN being optional).
>>>
>>>Thanks
>>>Gopal
>>>
>>>
>>>>If the MN-AAA authentication is removed, and there is no MN-HA
>authentication,
>>>by what means will the HA be able to authenticate the message ? Are you not
>>>assuming that in such a case the MN-HA authentication is used ?
>>>>
>>>>My understanding leads me to assume that in case either an MN-AAA
>>>authentication or MN-HA authentication extension will always be in a
>>>registration request received by the Home Agent. But the current wording of
>the
>>>document seems to able to lead to cases where the FA implementation could
>remove
>>>an MN-AAA authentication extension even when an MN-HA authentication does not
>>>exist.
>>>>
>>>>Please correct me if I'm wrong again.
>>>>(by the way then I believe the wording of
>>>>
>>>>"..........
>>>>   Since the Challenge extension, and the authentication extension that
>>>>   is used by the Mobile Node to satisfy the challenge, both follow
>>>>   the Mobile-Home Authentication extension whenever the latter is
>>>>   present, the Foreign Agent MAY remove the Challenge Extension and
>>>>   the applicable authentication from the Registration Request without
>>>>   disturbing the authentication value computed by the Mobile Node for
>>>>   use by the Home Agent.
>>>>........"
>>>>
>>>>should be changed (Is the first sentence grammatically correct ?)
>>>>to reflect the fact that the MN-AAA authentication can only be removed if
>there
>>>is a MN-HA authentication extension.
>>>>)
>>>>
>>>>cheers
>>>>
>>>>Woojune Kim,
>>>>Senior Engineer
>>>>Samsung Electronics Ltd.
>>>>tel : +82-342-779-8526
>>>>hp : +82-11-368-7480
>>>>e-mail : keg@telecom.samsung.co.kr
>>>>
>>>>
>>>>>
>>>>>Hello,
>>>>>
>>>>>Woo-June Kim wrote:
>>>>>
>>>>>> To me even if FAC is used, I don't quite see how it nullfies the need for
>>>>>> the MN-HA authentication field.
>>>>>
>>>>>The Challenge specification was written after the MN-NAI specification,
>>>>>and the MN-NAI specification allows a MN-AAA authentication extension
>>>>>to take the place of the MN-HA authentication extension.
>>>>>
>>>>>Regards,
>>>>>Charlie P.
>>>>>
>>>>
>>>Thank You.
>>>Regards,
>>>Gopal
>>>-------------------------------------------------------------------------------------------------------------
>>>
>>>Gopal Dommety
>>>408 525 1404
>>>gdommety@cisco.com
>>>Cisco Systems, San Jose, CA, 95051
>>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar  8 17:54:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06437
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 8 Mar 2000 17:54:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C79BEAF0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 17:50:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 80769 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 17:49:07 -0500
Received: from mail.ee.gatech.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.341F6050@standards.nortelnetworks.com>; Wed, 8 Mar 2000 17:39:07
          -0500
Received: from ece.gatech.edu (anik.ece.gatech.edu [199.77.145.182]) by
          mail.ee.gatech.edu (8.9.3/8.9.3) with ESMTP id RAA13705 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 8 Mar 2000 17:42:59
          -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------59077A190996B96B02945FCF"
Message-ID:  <38C6D6CF.D230693C@ece.gatech.edu>
Date:         Wed, 8 Mar 2000 14:40:15 -0800
Reply-To: MMT2000@ece.gatech.edu
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: MMT2000 <MMT2000@ece.gatech.edu>
Subject:      [MOBILE-IP] CALL FOR PAPERS (IEEE MMT'2000)
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------59077A190996B96B02945FCF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------59077A190996B96B02945FCF
Content-Type: text/plain; charset=us-ascii;
 name="cfp"
Content-Disposition: inline;
 filename="cfp"
Content-Transfer-Encoding: 7bit

                           CALL FOR PAPERS



                          IEEE  MMT'2000

                 MULTIACCESS, MOBILITY AND TELETRAFFIC
                      FOR WIRELESS COMMUNICATIONS


                        December 3-6, 2000


                       Hawk's Cay Resort
                     Duck Key, Florida, USA


               Sponsored by IEEE Communications Society




Workshop Co-Chairs:

Gordon L. Stuber and Ian F. Akyildiz

Georgia Institute of Technology
{stuber,ian}@ece.gatech.edu


Advisory Board:

Norman Abramson, ALOHA Networks, USA
Hamid Aghvami, King's College, UK
Donald Cox, Stanford Univ., USA
Anthony Ephremides, UMD, USA
David Everitt, Univ. of Melbourne, AU
Robert Gallager, MIT, USA
Philippe Godlewski, ENST, France
Bijan Jabbari, GMU, USA
Jim Massey, ETH, Switzerland
Raj Pandya, BNR, Canada
Raymond Pickholtz, GWU, USA
Stephen Rappaport, SUNY-Stony Brook, USA
Raymond Steele, MAC Ltd., UK
Andrew Viterbi, Qualcomm, USA


The focus of this workshop is to identify, present and discuss the
theoretical and implementation issues critical to the design of land
and satellite-based mobile cellular and microcellular, wireless personal
communications as well as wireless local area networks. Topics of
interest include but are not limited to:

 * Third Generation Wireless Systems
 * Multiaccess Methods and their Performance Analysis
 * Error Control Protocols
 * Teletraffic Issues
 * Mobility Management and Call Control
 * Handoff Strategies and Implementation
 * Power Control Algorithms and Implementations
 * Universal Personal Telecommunications Issues
 * Mobile Computing
 * Internet Access in Wireless Networks
 * Satellite Networks
 * Wireless Internet

The workshop will feature distinguished speakers and a number of high
quality technical presentations.

Submit your papers (in PS, PDF or DOC form) to

                MMT2000@ece.gatech.edu

Important Dates:

        Deadline for Paper Submission:                  June 1, 2000
        Notification of Acceptance:                     August 1, 2000
        Final Manuscript for Workshop Proceedings:      September 1, 2000

MMT'2000
Attention: Gordon L. Stuber and Ian F. Akyildiz
Tel: (404) 894-2923,  Fax: (404) 894-7883
Email: MMT2000@ece.gatech.edu
http://www.ece.gatech.edu/users/stuber/MMT2000



--------------59077A190996B96B02945FCF--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 11:19:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25409
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 11:19:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F9ABFD0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 11:14:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82147 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 11:13:30 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7FC0E900@standards.nortelnetworks.com>; Thu, 9 Mar 2000 11:13:30
          -0500
Received: from gdommety-pc2 (gdommety-dsl4.cisco.com [10.19.17.141]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          IAA02780; Thu, 9 Mar 2000 08:16:51 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003091616.IAA02780@omega.cisco.com>
Date:         Thu, 9 Mar 2000 08:29:24 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] GRE Addendum
X-To:         Umamaheswar Achari Kakinada
              <Umamaheswar_Achari_Kakinada@MW.3COM.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <8625689C.006F7D2E.00@mwgate02.mw.3com.com>

Hello:

PPTP uses their own version of GRE (ver 1). Alok also made the same suggestion as you did.

I am not sure if we want to support a seperate Acknowlegement at the present time, since we are not specifing
the semantics of it.  If most of you prefer, I can actually make the TX sequence no the whole sequence no
(4 bytes). That way in the future if we want to define acknowledgement type of feild we can be consistant. Let me know.

As for splitting the Key feild into two as PPTP, you can still do that if both the ends agree on it via a
signalling mechanisim. If we specify that them we are actually introducing 2 new feilds instead of one in the
GRE specification (Payload lenght and Key).

Thanks
Gopal





At 02:18 PM 08/03/00 -0600, Umamaheswar Achari Kakinada wrote:
>Hi,
>  I was looking at PPTP draft, which also uses the GRE  like encapsulation for
>the PPP frames.
>  Can the same mechanism be used here.  There the Key field is further devided
>in to sub-fields to
>  indicate  pay load length, etc. I also noticed your draft uses 2 bytes for
>transmission and
>  acknowledgement  sequence numbers,  where as in pptp these are 4 byte fields.
>
>    I was wondering if having them consistent across two standards would help if
>the PPTP
>clients/servers also act as mobility agents.
>
>Thanks
>
>Achari
>
>
>
>
>
>Gopal Dommety <gdommety@CISCO.COM> on 03/07/2000 06:44:59 PM
>
>Please respond to Gopal Dommety <gdommety@CISCO.COM>
>
>Sent by:  Gopal Dommety <gdommety@CISCO.COM>
>
>
>To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>cc:    (Umamaheswar Achari Kakinada/MW/US/3Com)
>Subject:  [MOBILE-IP] GRE Addendum
>
>
>
>Hello:
>
>        As requested  by IESG, I  written up a preliminary  version of
> the GRE addendum.  Please provide your comments.  As you go through the
> draft   at   places  identified   by   #   there   are  request   for
> comments. please give your opinion.
>
>Thanks
>Gopal
>
>
>
>
>Network Working Group                                      Gopal Dommety
>INTERNET DRAFT                                             cisco Systems
>February 2000
>
>Expires September 2000
>
>                Key and Sequence Number Extensions to GRE
>                    draft-dommety-gre-ext-00.txt
>
>All comments/discussion of this draft should be directed to gre@ops.ietf.org
>
>
>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 working groups. Note that other groups may also distribute
>   working documents as Internet Drafts.
>
>   Internet Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time. It is inappropriate to use Internet Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/ietf/1id-abstracts.txt.
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html.
>
>Abstract
>
>   This  document describes extensions  by which  two fields,  Key and
>Sequence Number, can be optionally carried in the GRE (Generic Routing
>Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
>of an arbitrary network  layer protocol over another arbitrary network
>layer  protocol.
>
>Dommety                                                           [Page 1]
>
>Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>
>1. Introduction
>
>   Current specification of Generic Routing Encapsulation [1] specifies
>a protocol  for encapsulation of  an arbitrary network  layer protocol
>over another arbitrary network layer protocol. This document describes
>enhancements  by which  two fields,  Key and  Sequence Number,  can be
>optionally carried  in the GRE  Header [1]. The  Key field is  used to
>create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
>is used to maintain sequence of packets within a GRE Tunnel.
>
>1.1. Specification Language
>
>   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>   this document are to be interpreted as described in RFC 2119 [3].
>
>   In addition, the following words are used to signify the
>   requirements of the specification.
>
>   Silently discard
>              The implementation discards the datagram without
>              further processing, and without indicating an error
>              to the sender.  The implementation SHOULD provide the
>              capability of logging the error, including the contents
>              of the discarded datagram, and SHOULD record the event
>              in a statistics counter.
>
>2. Extensions to GRE Header
>
>   The GRE packet header[1] has the following format:
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C|       Reserved0       | Ver |         Protocol Type         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    The proposed GRE header will have the following format:
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Key (optional)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>      Key Present (bit 2)
>
>      If the Key Present bit is set to 1, then it indicates that the Key
>      field is present in the GRE header.  Otherwise, the Key field is
>      not present in the GRE header.
>
>      Sequence Number Present (bit 3)
>
>      If the Sequence Number Present bit is set to 1, then it indicates
>      that the Sequence Number field is present.  Otherwise, the
>      Sequence Number field is not present in the GRE header.
>
>      The  Key and Sequence Present bits are chosen to be  compatible
>      with RFC 1701 [2].
>
>2.1. Key Field (4 octets)
>
>     The Key field contains a  four octet number which was inserted by
>     the encapsulator. The actual method by which this Key is obtained
>     is beyond the scope of this document.  Key field is intended to be
>     used for  creating separate sub-tunnels within a  GRE Tunnel and the
>     Key field identifies the sub-tunnel.
>
>2.2. Sequence Number (4 octets)
>
>    The Sequence Number  field is divided into two  sub-fields (Tx and
>    Rx sequence number). These subfields are inserted by the encapsulator
>    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
>    be used by the receiver to establish the  order in which  packets
>    have been  transmitted from the  encapsulator  to  the  receiver.
>    The intended  use  of  the Tx Sequence  Field is  to provide
>    unreliable and in-order delivery.   If the Key  present bit (bit 2)
>    is set, the sequence number is specific to the sub-tunnel identified
>    by the Key field.
>
>    The Tx sequence number  value ranges from 1 to  65535. The first
>    datagram is sent with a Tx sequence number of 1. The Tx sequence
>    number is thus a free running counter represented modulo 65536,
>    with the exception that 1 is used when modulo 65536 results in 0
>    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
>
>#Q The Rx can be the Tx  sequence number of the last successfully decap
>  pack.  And  say  that  how  you  use  this  info  is  implementation
>  dependent. To avoid controversy I am currently saying Rx sequence no
>  is set to 0. Comments?
>
>
>    When the decapsulator receives an out-of sequence packet it SHOULD
>    be silently discarded. Additionally, reordering of out-of sequence
>    packets  MAY  be  performed   by  the  decapsulator  for  improved
>    performance and  tolerance to reordering in the  network (since the
>    state of the stateful compression or encryption is reset by packet
>    loss, it  might help the  performance to tolerate some  amount of
>    packet reordering in the network by buffering). Exact buffering
>    schemes are outside the scope
>    of  this  document. Note that the  Tx sequence number is used to detect
>    lost packets and/or restore  the original sequence of packets that
>    may have been reordered during transport.
>
>   A packet  is considered an out-of-sequence packet  if the Tx sequence
>   number  of  the  received packet  is  lesser than or equal to  the Tx
>   sequence  number   of last  successfully  decapsulated
>   packet. The  Tx sequence number  of a received message is considered
>   less than or equal to the last successfully received Tx sequence number
>   if its value lies in the range of the last received Tx sequence number
>   and the preceding 32766 values, inclusive.  For example, if the last
>   successfully received Tx sequence number was 15, then messages with Tx
>   sequence numbers 1 through 15, as well as 32784 through 65535, would be
>   considered less than or equal. Such a message would be considered an
>   out-of-sequence packet and  ignored from processing.
>
>    If the received packet is an in-sequence packet, it is successfully
>    de capsulated. Note that  the TX sequence number is  used to detect
>    lost packets and/or restore the original sequence of packets (with
>    buffering) that may have been reordered during transport.
>
>#C I have considered  trying to have a different  starting point for TX
>sequence nos  during rollover and initial starting  point.  This would
>let a node  identify if the other end  reset (like agent advertisement
>sequence no to identify reboot and normal rollover). This is useful if
>we keep turning on and off sequence nos option in a tunnel. Comments?
>
>
>3. IANA Considerations
>
>4. Acknowledgments
>
>   The author  would like to thank  .......................  for their
>   useful discussions.
>
>5. References
>
>   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>   "Generic           Routing           Encapsulation          (GRE),"
>   draft-meyer-gre-update-03.txt, January 2000.
>
>   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>   October 1994.
>
>   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>       Levels", RFC 2119, March 1997.
>
>
>Dommety                                                 [Page 4]
>
>Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>
>Author Information
>
>   Gopal Dommety
>   Cisco Systems, Inc.
>   170 West Tasman Drive
>   San Jose, CA 95134
>   e-mail: gdommety@cisco.com
>
>Dommety
>
>
>
>
>
>Thank You.
>Regards,
>Gopal
>-------------------------------------------------------------------------------------------------------------
>
>
>Gopal Dommety
>408 525 1404
>gdommety@cisco.com
>Cisco Systems, San Jose, CA, 95051
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 12:00:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08629
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 12:00:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E35A9F0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 11:55:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82231 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 11:53:47 -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.20682170@standards.nortelnetworks.com>; Thu, 9 Mar 2000 11:53:47
          -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id IAA17510; Thu, 9 Mar 2000 08:57:41
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          IAA10028; Thu, 9 Mar 2000 08:57:40 -0800 (PST)
Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id IAA00656; Thu, 9 Mar 2000 08:57:39
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: iYaCX3zB9v+GiHz1eCAenA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
Message-ID:  <200003091657.IAA00656@nasnfs.eng.sun.com>
Date:         Thu, 9 Mar 2000 08:59:15 -0800
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] charter update
X-To:         Yingchun_Xu@MW.3COM.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>Give you another update. As I know upto today, there are three groups (MWIF, 3G
>IP, TSG-ALL IP) working on "all IP" solution and every one of them has
>different
>vision (or purpose). I heard another  one is coming in pipe (scary).  Sooner,
>we
>need another one to unify all of them.

Actually, the goal of MWIF is to have 3GPP and 3GPP2 have the same "all IP"
solution for both the core network and the RAN.

                jak


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 12:26:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16636
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 12:26:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA0B2810@standards.nortelnetworks.com>; Thu, 9 Mar 2000 12:19:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82258 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 12:18:46 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9DD0BF20@standards.nortelnetworks.com>; Thu, 9 Mar 2000 12:18:45
          -0500
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id TAA10158; Thu, 9 Mar
          2000 19:22:29 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          TAA22886; Thu, 9 Mar 2000 19:22:28 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <GT3L731K>;
          Thu, 9 Mar 2000 11:22:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B92977D@daeis07nok>
Date:         Thu, 9 Mar 2000 11:21:27 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      Re: [MOBILE-IP] charter update
X-cc:         James.Kempf@Eng.Sun.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>>Give you another update. As I know upto today, there are three groups
>>(MWIF, 3G IP, TSG-ALL IP) working on "all IP" solution and every one
>>of them has different vision (or purpose). I heard another  one is
>>coming in pipe (scary).  Sooner, we need another one to unify all of
>>them.
>
>Actually, the goal of MWIF is to have 3GPP and 3GPP2 have the same "all IP"
>solution for both the core network and the RAN.
>
>                jak

Looks like the discussion on this list is degenerating into what MWIF
or 3G.IP are doing and their objectives. Let's try to keep it focused
on Mobile IP. I do not intend to discourage discussion on topics that
are closely intertwined between Mobile IP and the work being done in
these forums, but we need to keep it relevant to the charter of this
WG. If the outcome of the work in these forums has a positive impact
on Mobile IP (getting it deployed) then we MUST look at how we can
assist in that effort.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 14:13:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20791
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 14:13:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBDC87C0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 14:08:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82428 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 14:07:31 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CEFB1EB0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 14:07:30
          -0500
Received: from gdommety-pc2 (dhcp-sjc9-233-161.cisco.com [171.71.233.161]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          LAA03821 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 9 Mar
          2000 11:11:24 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <8625689C.006F7D2E.00@mwgate02.mw.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003091911.LAA03821@omega.cisco.com>
Date:         Thu, 9 Mar 2000 11:23:57 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      [MOBILE-IP] GRE Addendum
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003091616.IAA02780@omega.cisco.com>

Hello:

Please subscribe to gre@ops.ietf.org by sending email to
gre-request@ops.ietf.org. Please send (or cc) all discussion
to this mailing list.

thanks
Gopal



>>
>>
>>Network Working Group                                      Gopal Dommety
>>INTERNET DRAFT                                             cisco Systems
>>February 2000
>>
>>Expires September 2000
>>
>>                Key and Sequence Number Extensions to GRE
>>                    draft-dommety-gre-ext-00.txt
>>
>>All comments/discussion of this draft should be directed to gre@ops.ietf.org
>>
>>
>>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 working groups. Note that other groups may also distribute
>>   working documents as Internet Drafts.
>>
>>   Internet Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time. It is inappropriate to use Internet Drafts as reference
>>   material or to cite them other than as "work in progress."
>>
>>   The list of current Internet-Drafts can be accessed at
>>   http://www.ietf.org/ietf/1id-abstracts.txt.
>>
>>   The list of Internet-Draft Shadow Directories can be accessed at
>>   http://www.ietf.org/shadow.html.
>>
>>Abstract
>>
>>   This  document describes extensions  by which  two fields,  Key and
>>Sequence Number, can be optionally carried in the GRE (Generic Routing
>>Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
>>of an arbitrary network  layer protocol over another arbitrary network
>>layer  protocol.
>>
>>Dommety                                                           [Page 1]
>>
>>Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>>
>>1. Introduction
>>
>>   Current specification of Generic Routing Encapsulation [1] specifies
>>a protocol  for encapsulation of  an arbitrary network  layer protocol
>>over another arbitrary network layer protocol. This document describes
>>enhancements  by which  two fields,  Key and  Sequence Number,  can be
>>optionally carried  in the GRE  Header [1]. The  Key field is  used to
>>create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
>>is used to maintain sequence of packets within a GRE Tunnel.
>>
>>1.1. Specification Language
>>
>>   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>   this document are to be interpreted as described in RFC 2119 [3].
>>
>>   In addition, the following words are used to signify the
>>   requirements of the specification.
>>
>>   Silently discard
>>              The implementation discards the datagram without
>>              further processing, and without indicating an error
>>              to the sender.  The implementation SHOULD provide the
>>              capability of logging the error, including the contents
>>              of the discarded datagram, and SHOULD record the event
>>              in a statistics counter.
>>
>>2. Extensions to GRE Header
>>
>>   The GRE packet header[1] has the following format:
>>
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |C|       Reserved0       | Ver |         Protocol Type         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>    The proposed GRE header will have the following format:
>>
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                         Key (optional)                        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>      Key Present (bit 2)
>>
>>      If the Key Present bit is set to 1, then it indicates that the Key
>>      field is present in the GRE header.  Otherwise, the Key field is
>>      not present in the GRE header.
>>
>>      Sequence Number Present (bit 3)
>>
>>      If the Sequence Number Present bit is set to 1, then it indicates
>>      that the Sequence Number field is present.  Otherwise, the
>>      Sequence Number field is not present in the GRE header.
>>
>>      The  Key and Sequence Present bits are chosen to be  compatible
>>      with RFC 1701 [2].
>>
>>2.1. Key Field (4 octets)
>>
>>     The Key field contains a  four octet number which was inserted by
>>     the encapsulator. The actual method by which this Key is obtained
>>     is beyond the scope of this document.  Key field is intended to be
>>     used for  creating separate sub-tunnels within a  GRE Tunnel and the
>>     Key field identifies the sub-tunnel.
>>
>>2.2. Sequence Number (4 octets)
>>
>>    The Sequence Number  field is divided into two  sub-fields (Tx and
>>    Rx sequence number). These subfields are inserted by the encapsulator
>>    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
>>    be used by the receiver to establish the  order in which  packets
>>    have been  transmitted from the  encapsulator  to  the  receiver.
>>    The intended  use  of  the Tx Sequence  Field is  to provide
>>    unreliable and in-order delivery.   If the Key  present bit (bit 2)
>>    is set, the sequence number is specific to the sub-tunnel identified
>>    by the Key field.
>>
>>    The Tx sequence number  value ranges from 1 to  65535. The first
>>    datagram is sent with a Tx sequence number of 1. The Tx sequence
>>    number is thus a free running counter represented modulo 65536,
>>    with the exception that 1 is used when modulo 65536 results in 0
>>    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
>>
>>#Q The Rx can be the Tx  sequence number of the last successfully decap
>>  pack.  And  say  that  how  you  use  this  info  is  implementation
>>  dependent. To avoid controversy I am currently saying Rx sequence no
>>  is set to 0. Comments?
>>
>>
>>    When the decapsulator receives an out-of sequence packet it SHOULD
>>    be silently discarded. Additionally, reordering of out-of sequence
>>    packets  MAY  be  performed   by  the  decapsulator  for  improved
>>    performance and  tolerance to reordering in the  network (since the
>>    state of the stateful compression or encryption is reset by packet
>>    loss, it  might help the  performance to tolerate some  amount of
>>    packet reordering in the network by buffering). Exact buffering
>>    schemes are outside the scope
>>    of  this  document. Note that the  Tx sequence number is used to detect
>>    lost packets and/or restore  the original sequence of packets that
>>    may have been reordered during transport.
>>
>>   A packet  is considered an out-of-sequence packet  if the Tx sequence
>>   number  of  the  received packet  is  lesser than or equal to  the Tx
>>   sequence  number   of last  successfully  decapsulated
>>   packet. The  Tx sequence number  of a received message is considered
>>   less than or equal to the last successfully received Tx sequence number
>>   if its value lies in the range of the last received Tx sequence number
>>   and the preceding 32766 values, inclusive.  For example, if the last
>>   successfully received Tx sequence number was 15, then messages with Tx
>>   sequence numbers 1 through 15, as well as 32784 through 65535, would be
>>   considered less than or equal. Such a message would be considered an
>>   out-of-sequence packet and  ignored from processing.
>>
>>    If the received packet is an in-sequence packet, it is successfully
>>    de capsulated. Note that  the TX sequence number is  used to detect
>>    lost packets and/or restore the original sequence of packets (with
>>    buffering) that may have been reordered during transport.
>>
>>#C I have considered  trying to have a different  starting point for TX
>>sequence nos  during rollover and initial starting  point.  This would
>>let a node  identify if the other end  reset (like agent advertisement
>>sequence no to identify reboot and normal rollover). This is useful if
>>we keep turning on and off sequence nos option in a tunnel. Comments?
>>
>>
>>3. IANA Considerations
>>
>>4. Acknowledgments
>>
>>   The author  would like to thank  .......................  for their
>>   useful discussions.
>>
>>5. References
>>
>>   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>>   "Generic           Routing           Encapsulation          (GRE),"
>>   draft-meyer-gre-update-03.txt, January 2000.
>>
>>   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>>   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>>   October 1994.
>>
>>   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>>       Levels", RFC 2119, March 1997.
>>
>>
>>Dommety                                                 [Page 4]
>>
>>Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>>
>>Author Information
>>
>>   Gopal Dommety
>>   Cisco Systems, Inc.
>>   170 West Tasman Drive
>>   San Jose, CA 95134
>>   e-mail: gdommety@cisco.com
>>
>>Dommety
>>
>>
>>
>>
>>
>>Thank You.
>>Regards,
>>Gopal
>>-------------------------------------------------------------------------------------------------------------
>>
>>
>>Gopal Dommety
>>408 525 1404
>>gdommety@cisco.com
>>Cisco Systems, San Jose, CA, 95051
>>
>Thank You.
>Regards,
>Gopal
>-------------------------------------------------------------------------------------------------------------
>
>Gopal Dommety
>408 525 1404
>gdommety@cisco.com
>Cisco Systems, San Jose, CA, 95051
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 15:22:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11390
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 15:22:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84969480@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:17:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82610 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 15:15:59 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5FDB59F0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:15:59
          -0500
Received: from gdommety-pc2 (dhcp-sjc9-233-161.cisco.com [171.71.233.161]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          MAA17086; Thu, 9 Mar 2000 12:18:47 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003092018.MAA17086@omega.cisco.com>
Date:         Thu, 9 Mar 2000 12:31:14 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      [MOBILE-IP] New GRE Draft  Extensions
X-To:         ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org
X-cc:         dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com,
              udlr@sophia.inria.fr, narten@raleigh.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello:

I am  attaching the  GRE addendum/extensions.  As  you go  through the
 draft at places identified by # there are request for comments. I have
split the sequence no into two subfeilds (the other option is to define an
acknowledgement like PPTP WHEN such a need it felt).

Please send  your comments to  gre@ops.ietf.org mailing list.  you can
subscribe   to   this   mailing   list   by  sending   an   email   to
request-gre@ops.ietf.org


Thanks
Gopal




Network Working Group                                      Gopal Dommety
INTERNET DRAFT                                             cisco Systems
March 2000

Expires October 2000

                Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-00.txt

Status of this Memo

   This document is a submission by the Network Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the gre@ops.ietf.org mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol.

Dommety                                                           [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the
   requirements of the specification.

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    The proposed GRE header will have the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible
      with RFC 1701 [2].

2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel.

2.2. Sequence Number (4 octets)

    The Sequence Number  field is divided into two  sub-fields (Tx and
    Rx sequence number). These subfields are inserted by the encapsulator
    when Sequence Number Present Bit is set . Tx Sequence Number  MUST
    be used by the receiver to establish the  order in which  packets
    have been  transmitted from the  encapsulator  to  the  receiver.
    The intended  use  of  the Tx Sequence  Field is  to provide
    unreliable and in-order delivery.   If the Key  present bit (bit 2)
    is set, the sequence number is specific to the sub-tunnel identified
    by the Key field.

    The Tx sequence number  value ranges from 1 to  65535. The first
    datagram is sent with a Tx sequence number of 1. The Tx sequence
    number is thus a free running counter represented modulo 65536,
    with the exception that 1 is used when modulo 65536 results in 0
    (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.

#Q The Rx can be the Tx  sequence number of the last successfully decap
  pack.  And  say  that  how  you  use  this  info  is  implementation
  dependent.  I am currently saying Rx sequence no
  is set to 0. Comments?


    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering
    schemes are outside the scope
    of  this  document. Note that the  Tx sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the Tx sequence
   number  of  the  received packet  is  lesser than or equal to  the Tx
   sequence  number   of last  successfully  decapsulated
   packet. The  Tx sequence number  of a received message is considered
   less than or equal to the last successfully received Tx sequence number
   if its value lies in the range of the last received Tx sequence number
   and the preceding 32766 values, inclusive.  For example, if the last
   successfully received Tx sequence number was 15, then messages with Tx
   sequence numbers 1 through 15, as well as 32784 through 65535, would be
   considered less than or equal. Such a message would be considered an
   out-of-sequence packet and  ignored from processing.

    If the received packet is an in-sequence packet, it is successfully
    de capsulated. Note that  the TX sequence number is  used to detect
    lost packets and/or restore the original sequence of packets (with
    buffering) that may have been reordered during transport.

#C I have considered trying to  have a different starting point for TX
sequence nos  during rollover and initial starting  point.  This would
let a node  identify if the other end  reset (like agent advertisement
sequence no to identify reboot and normal rollover). This is useful if
we keep  turning on  and off  sequence nos option  in a  tunnel. Since
there  is no  security it  is easy  for others  to reset  the sequence
also. Comments?


3. IANA Considerations

4. Acknowledgments


5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
   October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.


Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: gdommety@cisco.com

Dommety





Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar  9 15:49:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18048
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 9 Mar 2000 15:49:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.716DCEB0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:45:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 82687 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 15:43:35 -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3A8716E0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:43:34
          -0500
Received: from gdommety-pc2 (dhcp-sjc9-233-161.cisco.com [171.71.233.161]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          MAA21507; Thu, 9 Mar 2000 12:46:21 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003092046.MAA21507@omega.cisco.com>
Date:         Thu, 9 Mar 2000 12:58:46 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org
X-cc:         dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com,
              udlr@sophia.inria.fr, narten@raleigh.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003092018.MAA17086@omega.cisco.com>

>Please send  your comments to  gre@ops.ietf.org mailing list.  you can
>subscribe   to   this   mailing   list   by  sending   an   email   to
>request-gre@ops.ietf.org

Sorry, you need to send the email to gre-request@ops.ietf.org

-Gopal


Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 11:03:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01168
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 11:03:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A30B1F0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 10:58:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83556 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 10:57:09
          -0500
Received: from tech.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FC2BB090@standards.nortelnetworks.com>; Fri, 10 Mar 2000 10:47:09
          -0500
Received: from ORANLT ([171.69.210.5]) by tech.cisco.com (Netscape Messaging
          Server 3.61)  with SMTP id AAAE76; Fri, 10 Mar 2000 10:51:52 -0500
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID:  <NDBBKHCGKKIOOIJEGCOEOENODCAA.oran@cisco.com>
Date:         Fri, 10 Mar 2000 10:51:00 -0500
Reply-To: Dave Oran <oran@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Dave Oran <oran@CISCO.COM>
Subject:      [MOBILE-IP] GRE mailing list
X-To:         msdp@antc.uoregon.edu, udlr@sophia.inria.fr
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

In case any of you have missed it, there is now a dedicated mailing list to
discuss possbile future enhancements to and progression beyond proposed
standard for GRE.

The list is
        gre@ops.ietf.org

subscribe via mail to gre-request@ops.ietf.org

Please join in there so that we can get all the various Working Group
requirements and interests exposed in one place.

Thanks, Dave Oran


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 11:15:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05120
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 11:15:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.398F7360@standards.nortelnetworks.com>; Fri, 10 Mar 2000 11:10:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83610 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 11:09:51
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.279120A0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 11:09:50
          -0500
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 IAA04728;
          Fri, 10 Mar 2000 08:13:48 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id IAA26195; Fri, 10 Mar 2000 08:11:10 -0800
X-Virus-Scanned:  Fri, 10 Mar 2000 08:11:10 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma025824; Fri, 10 Mar 00 08:11:04 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <NDBBKHCGKKIOOIJEGCOEOENODCAA.oran@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C91F36.EBDCD275@iprg.nokia.com>
Date:         Fri, 10 Mar 2000 08:13:42 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] GRE mailing list
X-cc:         Dave Oran <oran@CISCO.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

My experience with GRE is that it has a lot of features that
would not be needed for Mobile IP.  While I have not followed
the recent discussion, I note that existing GRE deployments
would probably _not_ handle any extensions.

Thus, if needed functionality is going to be acquired by
new extensions, new GRE deployments would be needed.  So,
why shouldn't Mobile IP define the necessary tunneling
protocol that we need?

I also note that the existing Minimal Encapsulation protocol
(RFC 2004) is a likely candidate revision to suit any additional
tunneling needs for Mobile IP.  There are reserved bits we
could use to control new features, and the existing deployment
of RFC 2004 is so small that obviously people don't like it
much anyway -- so it needs to be changed to be useful.

I would rather implement a small tunneling protocol that does
exactly what Mobile IP needs, instead of a new protocol from
a big specification.  Is GREng likely to be a big one, or a
small one?

Regards,
Charlie P.


Dave Oran wrote:
>
> In case any of you have missed it, there is now a dedicated mailing list to
> discuss possbile future enhancements to and progression beyond proposed
> standard for GRE.
>
> The list is
>         gre@ops.ietf.org
>
> subscribe via mail to gre-request@ops.ietf.org
>
> Please join in there so that we can get all the various Working Group
> requirements and interests exposed in one place.
>
> Thanks, Dave Oran


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 11:22:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07085
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 11:22:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3550C2D0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 11:17:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83644 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 11:15:43
          -0500
Received: from tech.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F95DC6B0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 11:15:42
          -0500
Received: from ORANLT ([171.69.210.5]) by tech.cisco.com (Netscape Messaging
          Server 3.61)  with SMTP id AAA1296; Fri, 10 Mar 2000 11:20:30 -0500
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID:  <NDBBKHCGKKIOOIJEGCOEKEOBDCAA.oran@cisco.com>
Date:         Fri, 10 Mar 2000 11:19:39 -0500
Reply-To: Dave Oran <oran@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Dave Oran <oran@CISCO.COM>
Subject:      Re: [MOBILE-IP] GRE mailing list
X-To:         charliep@iprg.nokia.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C91F36.EBDCD275@iprg.nokia.com>
Content-Transfer-Encoding: 7bit

This is exactly the kind of message that ought to get posted to the gre
mailing list (as well as the mobileip mailing list).

The reason we set up the gre list was so that mobileip, udlr, msdp, etc.
etc. don't all have separate non-intersecting discussions of what usage they
plan to make of GRE (if any) and what features may or may not be needed.

I would encourage you to repost your message including the gre list.

Dave.


> -----Original Message-----
> From: charliep@iprg.nokia.com [mailto:charliep@iprg.nokia.com]
> Sent: Friday, March 10, 2000 11:14 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Cc: Dave Oran
> Subject: Re: [MOBILE-IP] GRE mailing list
>
>
>
> Hello folks,
>
> My experience with GRE is that it has a lot of features that
> would not be needed for Mobile IP.  While I have not followed
> the recent discussion, I note that existing GRE deployments
> would probably _not_ handle any extensions.
>
> Thus, if needed functionality is going to be acquired by
> new extensions, new GRE deployments would be needed.  So,
> why shouldn't Mobile IP define the necessary tunneling
> protocol that we need?
>
> I also note that the existing Minimal Encapsulation protocol
> (RFC 2004) is a likely candidate revision to suit any additional
> tunneling needs for Mobile IP.  There are reserved bits we
> could use to control new features, and the existing deployment
> of RFC 2004 is so small that obviously people don't like it
> much anyway -- so it needs to be changed to be useful.
>
> I would rather implement a small tunneling protocol that does
> exactly what Mobile IP needs, instead of a new protocol from
> a big specification.  Is GREng likely to be a big one, or a
> small one?
>
> Regards,
> Charlie P.
>
>
> Dave Oran wrote:
> >
> > In case any of you have missed it, there is now a dedicated
> mailing list to
> > discuss possbile future enhancements to and progression beyond proposed
> > standard for GRE.
> >
> > The list is
> >         gre@ops.ietf.org
> >
> > subscribe via mail to gre-request@ops.ietf.org
> >
> > Please join in there so that we can get all the various Working Group
> > requirements and interests exposed in one place.
> >
> > Thanks, Dave Oran
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 12:31:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00502
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 12:31:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E20997F0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 12:26:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83774 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 12:25:06
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AB1B8D20@standards.nortelnetworks.com>; Fri, 10 Mar 2000 12:25:06
          -0500
Received: from gdommety-pc2 (gdommety-dsl4.cisco.com [10.19.17.141]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          JAA03275; Fri, 10 Mar 2000 09:28:33 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <NDBBKHCGKKIOOIJEGCOEOENODCAA.oran@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003101728.JAA03275@omega.cisco.com>
Date:         Fri, 10 Mar 2000 09:41:14 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] GRE mailing list
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C91F36.EBDCD275@iprg.nokia.com>

Charlie,

As far as base RFC2002 goes. The new GRE looks pretty much like the
old one.

-Gopal


At 08:13 AM 10/03/00 -0800, Charles E. Perkins wrote:
>Hello folks,
>
>My experience with GRE is that it has a lot of features that
>would not be needed for Mobile IP.  While I have not followed
>the recent discussion, I note that existing GRE deployments
>would probably _not_ handle any extensions.
>
>Thus, if needed functionality is going to be acquired by
>new extensions, new GRE deployments would be needed.  So,
>why shouldn't Mobile IP define the necessary tunneling
>protocol that we need?
>
>I also note that the existing Minimal Encapsulation protocol
>(RFC 2004) is a likely candidate revision to suit any additional
>tunneling needs for Mobile IP.  There are reserved bits we
>could use to control new features, and the existing deployment
>of RFC 2004 is so small that obviously people don't like it
>much anyway -- so it needs to be changed to be useful.
>
>I would rather implement a small tunneling protocol that does
>exactly what Mobile IP needs, instead of a new protocol from
>a big specification.  Is GREng likely to be a big one, or a
>small one?
>
>Regards,
>Charlie P.
>
>
>Dave Oran wrote:
>>
>> In case any of you have missed it, there is now a dedicated mailing list to
>> discuss possbile future enhancements to and progression beyond proposed
>> standard for GRE.
>>
>> The list is
>>         gre@ops.ietf.org
>>
>> subscribe via mail to gre-request@ops.ietf.org
>>
>> Please join in there so that we can get all the various Working Group
>> requirements and interests exposed in one place.
>>
>> Thanks, Dave Oran
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 13:11:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13852
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 13:11:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A647C40@standards.nortelnetworks.com>; Fri, 10 Mar 2000 13:06:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83812 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 13:05:04
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4076ED10@standards.nortelnetworks.com>; Fri, 10 Mar 2000 13:05:04
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id LAA22699 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 10 Mar 2000 11:09:02
          -0700 (MST)]
Received: [from ilms06.cig.mot.com (ilms06.cig.mot.com [136.182.15.18]) by
          mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA04740 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 10 Mar 2000 11:09:01
          -0700 (MST)]
Received: from email.mot.com ([160.44.110.59]) by ilms06.cig.mot.com (Netscape
          Messaging Server 3.01)  with ESMTP id AAA24248; Fri, 10 Mar 2000
          12:08:52 -0600
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003092018.MAA17086@omega.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C92FF2.1F789629@email.mot.com>
Date:         Fri, 10 Mar 2000 11:25:06 -0600
Reply-To: Ajoy Singh <ASINGH1@EMAIL.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <ASINGH1@EMAIL.MOT.COM>
Organization: Motorola
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Gopal Dommety <gdommety@CISCO.COM>
X-cc:         gre-request@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Gopal,

Here is couple of questions i have regarding the attached GRE draft.  I have not participated in previous
discussion of GRE, so i am
not aware of any decision made by IESG regarding this respect.

1. What is the Value of Version number field of  proposed GRE header ?  Is it 0 or something else ?  Does it mean
that all existing GRE implementations need to change to support this header format to be standard compliant?  I
was hoping that we can use different version number to support the new extensions and that way we do not require
to change existing deployment of GRE. This way any network element can discard right away the GRE packets which
it does not support ?
2. In GRE header format you have  specified RX Sequence number which seems to me same as ack sequence number of
PPTP GRE. Why we need similar thing represented in two different way in two different standards ?

thanks,
ajoy

Gopal Dommety wrote:

> Hello:
>
> I am  attaching the  GRE addendum/extensions.  As  you go  through the
>  draft at places identified by # there are request for comments. I have
> split the sequence no into two subfeilds (the other option is to define an
> acknowledgement like PPTP WHEN such a need it felt).
>
> Please send  your comments to  gre@ops.ietf.org mailing list.  you can
> subscribe   to   this   mailing   list   by  sending   an   email   to
> request-gre@ops.ietf.org
>
> Thanks
> Gopal
>
> Network Working Group                                      Gopal Dommety
> INTERNET DRAFT                                             cisco Systems
> March 2000
>
> Expires October 2000
>
>                 Key and Sequence Number Extensions to GRE
>                     draft-dommety-gre-ext-00.txt
>
> Status of this Memo
>
>    This document is a submission by the Network Working Group of the
>    Internet Engineering Task Force (IETF).  Comments should be submitted
>    to the gre@ops.ietf.org mailing list.
>
>    Distribution of this memo is unlimited.
>
>    This document is an Internet Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026. Internet Drafts are working
>    documents of the Internet Engineering Task Force (IETF), its areas,
>    and working groups. Note that other groups may also distribute
>    working documents as Internet Drafts.
>
>    Internet Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> Abstract
>
>    This  document describes extensions  by which  two fields,  Key and
> Sequence Number, can be optionally carried in the GRE (Generic Routing
> Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
> of an arbitrary network  layer protocol over another arbitrary network
> layer  protocol.
>
> Dommety                                                           [Page 1]
>
> Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>
> 1. Introduction
>
>    Current specification of Generic Routing Encapsulation [1] specifies
> a protocol  for encapsulation of  an arbitrary network  layer protocol
> over another arbitrary network layer protocol. This document describes
> enhancements  by which  two fields,  Key and  Sequence Number,  can be
> optionally carried  in the GRE  Header [1]. The  Key field is  used to
> create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
> is used to maintain sequence of packets within a GRE Tunnel.
>
> 1.1. Specification Language
>
>    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC 2119 [3].
>
>    In addition, the following words are used to signify the
>    requirements of the specification.
>
>    Silently discard
>               The implementation discards the datagram without
>               further processing, and without indicating an error
>               to the sender.  The implementation SHOULD provide the
>               capability of logging the error, including the contents
>               of the discarded datagram, and SHOULD record the event
>               in a statistics counter.
>
> 2. Extensions to GRE Header
>
>    The GRE packet header[1] has the following format:
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |C|       Reserved0       | Ver |         Protocol Type         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Checksum (optional)      |       Reserved1 (Optional)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     The proposed GRE header will have the following format:
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Checksum (optional)      |       Reserved1 (Optional)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Key (optional)                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       Key Present (bit 2)
>
>       If the Key Present bit is set to 1, then it indicates that the Key
>       field is present in the GRE header.  Otherwise, the Key field is
>       not present in the GRE header.
>
>       Sequence Number Present (bit 3)
>
>       If the Sequence Number Present bit is set to 1, then it indicates
>       that the Sequence Number field is present.  Otherwise, the
>       Sequence Number field is not present in the GRE header.
>
>       The  Key and Sequence Present bits are chosen to be  compatible
>       with RFC 1701 [2].
>
> 2.1. Key Field (4 octets)
>
>      The Key field contains a  four octet number which was inserted by
>      the encapsulator. The actual method by which this Key is obtained
>      is beyond the scope of this document.  Key field is intended to be
>      used for  creating separate sub-tunnels within a  GRE Tunnel and the
>      Key field identifies the sub-tunnel.
>
> 2.2. Sequence Number (4 octets)
>
>     The Sequence Number  field is divided into two  sub-fields (Tx and
>     Rx sequence number). These subfields are inserted by the encapsulator
>     when Sequence Number Present Bit is set . Tx Sequence Number  MUST
>     be used by the receiver to establish the  order in which  packets
>     have been  transmitted from the  encapsulator  to  the  receiver.
>     The intended  use  of  the Tx Sequence  Field is  to provide
>     unreliable and in-order delivery.   If the Key  present bit (bit 2)
>     is set, the sequence number is specific to the sub-tunnel identified
>     by the Key field.
>
>     The Tx sequence number  value ranges from 1 to  65535. The first
>     datagram is sent with a Tx sequence number of 1. The Tx sequence
>     number is thus a free running counter represented modulo 65536,
>     with the exception that 1 is used when modulo 65536 results in 0
>     (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
>
> #Q The Rx can be the Tx  sequence number of the last successfully decap
>   pack.  And  say  that  how  you  use  this  info  is  implementation
>   dependent.  I am currently saying Rx sequence no
>   is set to 0. Comments?

The only possible way this sequence number can be used to support some type of sliding window protocol either for

flow control or retransmission. I belive this does

>
>
>     When the decapsulator receives an out-of sequence packet it SHOULD
>     be silently discarded. Additionally, reordering of out-of sequence
>     packets  MAY  be  performed   by  the  decapsulator  for  improved
>     performance and  tolerance to reordering in the  network (since the
>     state of the stateful compression or encryption is reset by packet
>     loss, it  might help the  performance to tolerate some  amount of
>     packet reordering in the network by buffering). Exact buffering
>     schemes are outside the scope
>     of  this  document. Note that the  Tx sequence number is used to detect
>     lost packets and/or restore  the original sequence of packets that
>     may have been reordered during transport.
>
>    A packet  is considered an out-of-sequence packet  if the Tx sequence
>    number  of  the  received packet  is  lesser than or equal to  the Tx
>    sequence  number   of last  successfully  decapsulated
>    packet. The  Tx sequence number  of a received message is considered
>    less than or equal to the last successfully received Tx sequence number
>    if its value lies in the range of the last received Tx sequence number
>    and the preceding 32766 values, inclusive.  For example, if the last
>    successfully received Tx sequence number was 15, then messages with Tx
>    sequence numbers 1 through 15, as well as 32784 through 65535, would be
>    considered less than or equal. Such a message would be considered an
>    out-of-sequence packet and  ignored from processing.
>
>     If the received packet is an in-sequence packet, it is successfully
>     de capsulated. Note that  the TX sequence number is  used to detect
>     lost packets and/or restore the original sequence of packets (with
>     buffering) that may have been reordered during transport.
>
> #C I have considered trying to  have a different starting point for TX
> sequence nos  during rollover and initial starting  point.  This would
> let a node  identify if the other end  reset (like agent advertisement
> sequence no to identify reboot and normal rollover). This is useful if
> we keep  turning on  and off  sequence nos option  in a  tunnel. Since
> there  is no  security it  is easy  for others  to reset  the sequence
> also. Comments?
>
> 3. IANA Considerations
>
> 4. Acknowledgments
>
> 5. References
>
>    [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>    "Generic           Routing           Encapsulation          (GRE),"
>    draft-meyer-gre-update-03.txt, January 2000.
>
>    [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>    Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>    October 1994.
>
>    [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>        Levels", RFC 2119, March 1997.
>
> Dommety                                                 [Page 4]
>
> Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>
> Author Information
>
>    Gopal Dommety
>    Cisco Systems, Inc.
>    170 West Tasman Drive
>    San Jose, CA 95134
>    e-mail: gdommety@cisco.com
>
> Dommety
>
> Thank You.
> Regards,
> Gopal
> -------------------------------------------------------------------------------------------------------------
>
> Gopal Dommety
> 408 525 1404
> gdommety@cisco.com
> Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 14:07:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05653
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 14:07:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4FC0FBA0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 14:02:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83860 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 14:00:49
          -0500
Received: from smtpproxy1.mitre.org (129.83.20.100) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A4A16A80@standards.nortelnetworks.com>; Fri, 10 Mar 2000
          13:50:49 -0500
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by
          smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA17494; Fri, 10
          Mar 2000 13:54:31 -0500 (EST)
Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by
          smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA00349; Fri, 10 Mar
          2000 13:54:06 -0500 (EST)
Received: from mitre.org (fchase.mitre.org [129.83.114.44]) by linus.mitre.org
          (8.9.3/8.9.3) with ESMTP id NAA26751; Fri, 10 Mar 2000 13:54:24 -0500
          (EST)
X-Mailer: Mozilla 4.7 [en]C-19991010M  (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
References: <200003092046.MAA21507@omega.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38C94502.7D3D5026@mitre.org>
Date:         Fri, 10 Mar 2000 13:54:58 -0500
Reply-To: "Frederick N. Chase" <fnc@MITRE.ORG>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Frederick N. Chase" <fnc@MITRE.ORG>
Organization: The MITRE Corporation
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Gopal Dommety <gdommety@cisco.com>
X-cc:         ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org,
              dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com,
              udlr@sophia.inria.fr, narten@raleigh.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Re:  Key and Sequence Number Extensions to GRE



The proposed use of two previously-reserved header bits
in  draft-dommety-gre-ext-00.txt
differ in a fundamental way.

The proposed use of a reserved bit as a
"Sequence Number Present" bit is a
potentially-beneficial modifier
on encapsulator/decapsulator behavior and therefore
seems to me to be advisable or at least not inadvisable.

The proposed use of a reserved bit as a
"Key Present" bit does not affect (narrowly construed)
encapsulator/decapsulator behavior but rather
concerns the processor of the encapsulated or decapsulated
data.  This proposal seems to me to be inadvisable.

Acceptance of the "Key Present" proposal unnecessarily
encumbers some other
processor of encapsulated or decapsulated data
which might like to have an optional extra 32 bits for some purpose
where the terms "Key and "sub-tunnel" would be
confusing and inappropriate.


   -Fred Chase


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 14:20:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10539
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 14:20:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2296B7D0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 14:15:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83886 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 14:15:32
          -0500
Received: from wacko.redbacknetworks.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B2C0EA80@standards.nortelnetworks.com>; Fri, 10 Mar 2000 14:05:32
          -0500
Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com
          [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with
          ESMTP id LAA06922; Fri, 10 Mar 2000 11:08:27 -0800 (PST)
Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id
          LAA16962; Fri, 10 Mar 2000 11:08:26 -0800 (PST)
References: <200003092018.MAA17086@omega.cisco.com>
            <38C92FF2.1F789629@email.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Message-ID:  <20000310110826.B16343@redback.com>
Date:         Fri, 10 Mar 2000 11:08:26 -0800
Reply-To: Rene Tio <tor@REDBACK.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rene Tio <tor@REDBACK.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Ajoy Singh <ASINGH1@email.mot.com>
X-cc:         Gopal Dommety <gdommety@cisco.com>,
              gre-request@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C92FF2.1F789629@email.mot.com>; from ASINGH1@email.mot.com on
              Fri, Mar 10, 2000 at 11:25:06AM -0600

On Fri, Mar 10, 2000 at 11:25:06AM -0600, Ajoy Singh wrote:
> Hello Gopal,
>
> Here is couple of questions i have regarding the attached GRE draft.  I
> have not participated in previous discussion of GRE, so i am not aware of
> any decision made by IESG regarding this respect.

I do not know if the IESG figures into this since GRE is informational.
However I would like to know the reason behind the updates because
draft-meyer + draft-dommety looks pretty close to RFC 1701.  The changes
appear to be the semantics of the key field, which was somewhat semantic
free before since its use as an authenticator was always suspect, and the
split sequence number field.  What's the use of deprecating some fields in
one draft and extending it with the same deprecated fields in another draft?

> 1. What is the Value of Version number field of proposed GRE header ?  Is
> it 0 or something else ?  Does it mean that all existing GRE
> implementations need to change to support this header format to be
> standard compliant?

There is no change between draft-meyer-gre-update-03.txt and RFC 1701.  The
version field remains 0.

> I was hoping that we can use different version number to support the new
> extensions and that way we do not require to change existing deployment of
> GRE. This way any network element can discard right away the GRE packets
> which it does not support ?

Your point is well-taken.  Since the sequence number field is now split, RFC
1701 GRE will not understand draft-dommety GRE.  A new version number may be
required.  This is in contrast to draft-meyer, which is interoperable with
RFC 1701.

> 2. In GRE header format you have specified RX Sequence number which seems
> to me same as ack sequence number of PPTP GRE. Why we need similar thing
> represented in two different way in two different standards ?

Neither of them are "standards".  And not everyone uses GRE for PPTP.

R.

> thanks,
> ajoy
>
> Gopal Dommety wrote:
>
> > Hello:
> >
> > I am  attaching the  GRE addendum/extensions.  As  you go  through the
> >  draft at places identified by # there are request for comments. I have
> > split the sequence no into two subfeilds (the other option is to define an
> > acknowledgement like PPTP WHEN such a need it felt).
> >
> > Please send  your comments to  gre@ops.ietf.org mailing list.  you can
> > subscribe   to   this   mailing   list   by  sending   an   email   to
> > request-gre@ops.ietf.org
> >
> > Thanks
> > Gopal
> >
> > Network Working Group                                      Gopal Dommety
> > INTERNET DRAFT                                             cisco Systems
> > March 2000
> >
> > Expires October 2000
> >
> >                 Key and Sequence Number Extensions to GRE
> >                     draft-dommety-gre-ext-00.txt
> >
> > Status of this Memo
> >
> >    This document is a submission by the Network Working Group of the
> >    Internet Engineering Task Force (IETF).  Comments should be submitted
> >    to the gre@ops.ietf.org mailing list.
> >
> >    Distribution of this memo is unlimited.
> >
> >    This document is an Internet Draft and is in full conformance with
> >    all provisions of Section 10 of RFC2026. Internet Drafts are working
> >    documents of the Internet Engineering Task Force (IETF), its areas,
> >    and working groups. Note that other groups may also distribute
> >    working documents as Internet Drafts.
> >
> >    Internet Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at any
> >    time. It is inappropriate to use Internet Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt.
> >
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> > Abstract
> >
> >    This  document describes extensions  by which  two fields,  Key and
> > Sequence Number, can be optionally carried in the GRE (Generic Routing
> > Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
> > of an arbitrary network  layer protocol over another arbitrary network
> > layer  protocol.
> >
> > Dommety                                                           [Page 1]
> >
> > Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
> >
> > 1. Introduction
> >
> >    Current specification of Generic Routing Encapsulation [1] specifies
> > a protocol  for encapsulation of  an arbitrary network  layer protocol
> > over another arbitrary network layer protocol. This document describes
> > enhancements  by which  two fields,  Key and  Sequence Number,  can be
> > optionally carried  in the GRE  Header [1]. The  Key field is  used to
> > create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
> > is used to maintain sequence of packets within a GRE Tunnel.
> >
> > 1.1. Specification Language
> >
> >    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> >    this document are to be interpreted as described in RFC 2119 [3].
> >
> >    In addition, the following words are used to signify the
> >    requirements of the specification.
> >
> >    Silently discard
> >               The implementation discards the datagram without
> >               further processing, and without indicating an error
> >               to the sender.  The implementation SHOULD provide the
> >               capability of logging the error, including the contents
> >               of the discarded datagram, and SHOULD record the event
> >               in a statistics counter.
> >
> > 2. Extensions to GRE Header
> >
> >    The GRE packet header[1] has the following format:
> >
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |C|       Reserved0       | Ver |         Protocol Type         |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |      Checksum (optional)      |       Reserved1 (Optional)    |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >     The proposed GRE header will have the following format:
> >
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |C| |K|S| Reserved0       | Ver |         Protocol Type         |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |      Checksum (optional)      |       Reserved1 (Optional)    |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |                         Key (optional)                        |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >       Key Present (bit 2)
> >
> >       If the Key Present bit is set to 1, then it indicates that the Key
> >       field is present in the GRE header.  Otherwise, the Key field is
> >       not present in the GRE header.
> >
> >       Sequence Number Present (bit 3)
> >
> >       If the Sequence Number Present bit is set to 1, then it indicates
> >       that the Sequence Number field is present.  Otherwise, the
> >       Sequence Number field is not present in the GRE header.
> >
> >       The  Key and Sequence Present bits are chosen to be  compatible
> >       with RFC 1701 [2].
> >
> > 2.1. Key Field (4 octets)
> >
> >      The Key field contains a  four octet number which was inserted by
> >      the encapsulator. The actual method by which this Key is obtained
> >      is beyond the scope of this document.  Key field is intended to be
> >      used for  creating separate sub-tunnels within a  GRE Tunnel and the
> >      Key field identifies the sub-tunnel.
> >
> > 2.2. Sequence Number (4 octets)
> >
> >     The Sequence Number  field is divided into two  sub-fields (Tx and
> >     Rx sequence number). These subfields are inserted by the encapsulator
> >     when Sequence Number Present Bit is set . Tx Sequence Number  MUST
> >     be used by the receiver to establish the  order in which  packets
> >     have been  transmitted from the  encapsulator  to  the  receiver.
> >     The intended  use  of  the Tx Sequence  Field is  to provide
> >     unreliable and in-order delivery.   If the Key  present bit (bit 2)
> >     is set, the sequence number is specific to the sub-tunnel identified
> >     by the Key field.
> >
> >     The Tx sequence number  value ranges from 1 to  65535. The first
> >     datagram is sent with a Tx sequence number of 1. The Tx sequence
> >     number is thus a free running counter represented modulo 65536,
> >     with the exception that 1 is used when modulo 65536 results in 0
> >     (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
> >
> > #Q The Rx can be the Tx  sequence number of the last successfully decap
> >   pack.  And  say  that  how  you  use  this  info  is  implementation
> >   dependent.  I am currently saying Rx sequence no
> >   is set to 0. Comments?
>
> The only possible way this sequence number can be used to support some type of sliding window protocol either for
>
> flow control or retransmission. I belive this does
>
> >
> >
> >     When the decapsulator receives an out-of sequence packet it SHOULD
> >     be silently discarded. Additionally, reordering of out-of sequence
> >     packets  MAY  be  performed   by  the  decapsulator  for  improved
> >     performance and  tolerance to reordering in the  network (since the
> >     state of the stateful compression or encryption is reset by packet
> >     loss, it  might help the  performance to tolerate some  amount of
> >     packet reordering in the network by buffering). Exact buffering
> >     schemes are outside the scope
> >     of  this  document. Note that the  Tx sequence number is used to detect
> >     lost packets and/or restore  the original sequence of packets that
> >     may have been reordered during transport.
> >
> >    A packet  is considered an out-of-sequence packet  if the Tx sequence
> >    number  of  the  received packet  is  lesser than or equal to  the Tx
> >    sequence  number   of last  successfully  decapsulated
> >    packet. The  Tx sequence number  of a received message is considered
> >    less than or equal to the last successfully received Tx sequence number
> >    if its value lies in the range of the last received Tx sequence number
> >    and the preceding 32766 values, inclusive.  For example, if the last
> >    successfully received Tx sequence number was 15, then messages with Tx
> >    sequence numbers 1 through 15, as well as 32784 through 65535, would be
> >    considered less than or equal. Such a message would be considered an
> >    out-of-sequence packet and  ignored from processing.
> >
> >     If the received packet is an in-sequence packet, it is successfully
> >     de capsulated. Note that  the TX sequence number is  used to detect
> >     lost packets and/or restore the original sequence of packets (with
> >     buffering) that may have been reordered during transport.
> >
> > #C I have considered trying to  have a different starting point for TX
> > sequence nos  during rollover and initial starting  point.  This would
> > let a node  identify if the other end  reset (like agent advertisement
> > sequence no to identify reboot and normal rollover). This is useful if
> > we keep  turning on  and off  sequence nos option  in a  tunnel. Since
> > there  is no  security it  is easy  for others  to reset  the sequence
> > also. Comments?
> >
> > 3. IANA Considerations
> >
> > 4. Acknowledgments
> >
> > 5. References
> >
> >    [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
> >    "Generic           Routing           Encapsulation          (GRE),"
> >    draft-meyer-gre-update-03.txt, January 2000.
> >
> >    [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
> >    Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
> >    October 1994.
> >
> >    [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
> >        Levels", RFC 2119, March 1997.
> >
> > Dommety                                                 [Page 4]
> >
> > Internet Draft   Key and Sequence Number extensions to GRE   February 2000
> >
> > Author Information
> >
> >    Gopal Dommety
> >    Cisco Systems, Inc.
> >    170 West Tasman Drive
> >    San Jose, CA 95134
> >    e-mail: gdommety@cisco.com
> >
> > Dommety
> >
> > Thank You.
> > Regards,
> > Gopal
> > -------------------------------------------------------------------------------------------------------------
> >
> > Gopal Dommety
> > 408 525 1404
> > gdommety@cisco.com
> > Cisco Systems, San Jose, CA, 95051
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 14:27:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13290
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 14:27:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1E8ECEB0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 14:22:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 83899 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 14:22:47
          -0500
Received: from wacko.redbacknetworks.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B5D42880@standards.nortelnetworks.com>; Fri, 10 Mar 2000 14:12:46
          -0500
Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com
          [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with
          ESMTP id LAA08445; Fri, 10 Mar 2000 11:15:43 -0800 (PST)
Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id
          LAA17013; Fri, 10 Mar 2000 11:15:43 -0800 (PST)
References: <200003092018.MAA17086@omega.cisco.com>
            <38C92FF2.1F789629@email.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-Mailer: Mutt 1.0i
Message-ID:  <20000310110826.B16343@redback.com>
Date:         Fri, 10 Mar 2000 11:08:26 -0800
Reply-To: Rene Tio <tor@REDBACK.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rene Tio <tor@REDBACK.COM>
Subject:      [MOBILE-IP] RESEND: [MOBILE-IP] New GRE Draft Extensions
X-To:         Ajoy Singh <ASINGH1@email.mot.com>
X-cc:         Gopal Dommety <gdommety@cisco.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C92FF2.1F789629@email.mot.com>; from ASINGH1@email.mot.com on
              Fri, Mar 10, 2000 at 11:25:06AM -0600

Resending this to cover the GRE mailing list and to prevent others from
replying to the majordomo.

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

On Fri, Mar 10, 2000 at 11:25:06AM -0600, Ajoy Singh wrote:
> Hello Gopal,
>
> Here is couple of questions i have regarding the attached GRE draft.  I
> have not participated in previous discussion of GRE, so i am not aware of
> any decision made by IESG regarding this respect.

I do not know if the IESG figures into this since GRE is informational.
However I would like to know the reason behind the updates because
draft-meyer + draft-dommety looks pretty close to RFC 1701.  The changes
appear to be the semantics of the key field, which was somewhat semantic
free before since its use as an authenticator was always suspect, and the
split sequence number field.  What's the use of deprecating some fields in
one draft and extending it with the same deprecated fields in another draft?

> 1. What is the Value of Version number field of proposed GRE header ?  Is
> it 0 or something else ?  Does it mean that all existing GRE
> implementations need to change to support this header format to be
> standard compliant?

There is no change between draft-meyer-gre-update-03.txt and RFC 1701.  The
version field remains 0.

> I was hoping that we can use different version number to support the new
> extensions and that way we do not require to change existing deployment of
> GRE. This way any network element can discard right away the GRE packets
> which it does not support ?

Your point is well-taken.  Since the sequence number field is now split, RFC
1701 GRE will not understand draft-dommety GRE.  A new version number may be
required.  This is in contrast to draft-meyer, which is interoperable with
RFC 1701.

> 2. In GRE header format you have specified RX Sequence number which seems
> to me same as ack sequence number of PPTP GRE. Why we need similar thing
> represented in two different way in two different standards ?

Neither of them are "standards".  And not everyone uses GRE for PPTP.

R.

> thanks,
> ajoy
>
> Gopal Dommety wrote:
>
> > Hello:
> >
> > I am  attaching the  GRE addendum/extensions.  As  you go  through the
> >  draft at places identified by # there are request for comments. I have
> > split the sequence no into two subfeilds (the other option is to define an
> > acknowledgement like PPTP WHEN such a need it felt).
> >
> > Please send  your comments to  gre@ops.ietf.org mailing list.  you can
> > subscribe   to   this   mailing   list   by  sending   an   email   to
> > request-gre@ops.ietf.org
> >
> > Thanks
> > Gopal
> >
> > Network Working Group                                      Gopal Dommety
> > INTERNET DRAFT                                             cisco Systems
> > March 2000
> >
> > Expires October 2000
> >
> >                 Key and Sequence Number Extensions to GRE
> >                     draft-dommety-gre-ext-00.txt
> >
> > Status of this Memo
> >
> >    This document is a submission by the Network Working Group of the
> >    Internet Engineering Task Force (IETF).  Comments should be submitted
> >    to the gre@ops.ietf.org mailing list.
> >
> >    Distribution of this memo is unlimited.
> >
> >    This document is an Internet Draft and is in full conformance with
> >    all provisions of Section 10 of RFC2026. Internet Drafts are working
> >    documents of the Internet Engineering Task Force (IETF), its areas,
> >    and working groups. Note that other groups may also distribute
> >    working documents as Internet Drafts.
> >
> >    Internet Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at any
> >    time. It is inappropriate to use Internet Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt.
> >
> >    The list of Internet-Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> > Abstract
> >
> >    This  document describes extensions  by which  two fields,  Key and
> > Sequence Number, can be optionally carried in the GRE (Generic Routing
> > Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
> > of an arbitrary network  layer protocol over another arbitrary network
> > layer  protocol.
> >
> > Dommety                                                           [Page 1]
> >
> > Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
> >
> > 1. Introduction
> >
> >    Current specification of Generic Routing Encapsulation [1] specifies
> > a protocol  for encapsulation of  an arbitrary network  layer protocol
> > over another arbitrary network layer protocol. This document describes
> > enhancements  by which  two fields,  Key and  Sequence Number,  can be
> > optionally carried  in the GRE  Header [1]. The  Key field is  used to
> > create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
> > is used to maintain sequence of packets within a GRE Tunnel.
> >
> > 1.1. Specification Language
> >
> >    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> >    this document are to be interpreted as described in RFC 2119 [3].
> >
> >    In addition, the following words are used to signify the
> >    requirements of the specification.
> >
> >    Silently discard
> >               The implementation discards the datagram without
> >               further processing, and without indicating an error
> >               to the sender.  The implementation SHOULD provide the
> >               capability of logging the error, including the contents
> >               of the discarded datagram, and SHOULD record the event
> >               in a statistics counter.
> >
> > 2. Extensions to GRE Header
> >
> >    The GRE packet header[1] has the following format:
> >
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |C|       Reserved0       | Ver |         Protocol Type         |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |      Checksum (optional)      |       Reserved1 (Optional)    |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >     The proposed GRE header will have the following format:
> >
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |C| |K|S| Reserved0       | Ver |         Protocol Type         |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |      Checksum (optional)      |       Reserved1 (Optional)    |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |                         Key (optional)                        |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >       Key Present (bit 2)
> >
> >       If the Key Present bit is set to 1, then it indicates that the Key
> >       field is present in the GRE header.  Otherwise, the Key field is
> >       not present in the GRE header.
> >
> >       Sequence Number Present (bit 3)
> >
> >       If the Sequence Number Present bit is set to 1, then it indicates
> >       that the Sequence Number field is present.  Otherwise, the
> >       Sequence Number field is not present in the GRE header.
> >
> >       The  Key and Sequence Present bits are chosen to be  compatible
> >       with RFC 1701 [2].
> >
> > 2.1. Key Field (4 octets)
> >
> >      The Key field contains a  four octet number which was inserted by
> >      the encapsulator. The actual method by which this Key is obtained
> >      is beyond the scope of this document.  Key field is intended to be
> >      used for  creating separate sub-tunnels within a  GRE Tunnel and the
> >      Key field identifies the sub-tunnel.
> >
> > 2.2. Sequence Number (4 octets)
> >
> >     The Sequence Number  field is divided into two  sub-fields (Tx and
> >     Rx sequence number). These subfields are inserted by the encapsulator
> >     when Sequence Number Present Bit is set . Tx Sequence Number  MUST
> >     be used by the receiver to establish the  order in which  packets
> >     have been  transmitted from the  encapsulator  to  the  receiver.
> >     The intended  use  of  the Tx Sequence  Field is  to provide
> >     unreliable and in-order delivery.   If the Key  present bit (bit 2)
> >     is set, the sequence number is specific to the sub-tunnel identified
> >     by the Key field.
> >
> >     The Tx sequence number  value ranges from 1 to  65535. The first
> >     datagram is sent with a Tx sequence number of 1. The Tx sequence
> >     number is thus a free running counter represented modulo 65536,
> >     with the exception that 1 is used when modulo 65536 results in 0
> >     (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
> >
> > #Q The Rx can be the Tx  sequence number of the last successfully decap
> >   pack.  And  say  that  how  you  use  this  info  is  implementation
> >   dependent.  I am currently saying Rx sequence no
> >   is set to 0. Comments?
>
> The only possible way this sequence number can be used to support some type of sliding window protocol either for
>
> flow control or retransmission. I belive this does
>
> >
> >
> >     When the decapsulator receives an out-of sequence packet it SHOULD
> >     be silently discarded. Additionally, reordering of out-of sequence
> >     packets  MAY  be  performed   by  the  decapsulator  for  improved
> >     performance and  tolerance to reordering in the  network (since the
> >     state of the stateful compression or encryption is reset by packet
> >     loss, it  might help the  performance to tolerate some  amount of
> >     packet reordering in the network by buffering). Exact buffering
> >     schemes are outside the scope
> >     of  this  document. Note that the  Tx sequence number is used to detect
> >     lost packets and/or restore  the original sequence of packets that
> >     may have been reordered during transport.
> >
> >    A packet  is considered an out-of-sequence packet  if the Tx sequence
> >    number  of  the  received packet  is  lesser than or equal to  the Tx
> >    sequence  number   of last  successfully  decapsulated
> >    packet. The  Tx sequence number  of a received message is considered
> >    less than or equal to the last successfully received Tx sequence number
> >    if its value lies in the range of the last received Tx sequence number
> >    and the preceding 32766 values, inclusive.  For example, if the last
> >    successfully received Tx sequence number was 15, then messages with Tx
> >    sequence numbers 1 through 15, as well as 32784 through 65535, would be
> >    considered less than or equal. Such a message would be considered an
> >    out-of-sequence packet and  ignored from processing.
> >
> >     If the received packet is an in-sequence packet, it is successfully
> >     de capsulated. Note that  the TX sequence number is  used to detect
> >     lost packets and/or restore the original sequence of packets (with
> >     buffering) that may have been reordered during transport.
> >
> > #C I have considered trying to  have a different starting point for TX
> > sequence nos  during rollover and initial starting  point.  This would
> > let a node  identify if the other end  reset (like agent advertisement
> > sequence no to identify reboot and normal rollover). This is useful if
> > we keep  turning on  and off  sequence nos option  in a  tunnel. Since
> > there  is no  security it  is easy  for others  to reset  the sequence
> > also. Comments?
> >
> > 3. IANA Considerations
> >
> > 4. Acknowledgments
> >
> > 5. References
> >
> >    [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
> >    "Generic           Routing           Encapsulation          (GRE),"
> >    draft-meyer-gre-update-03.txt, January 2000.
> >
> >    [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
> >    Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
> >    October 1994.
> >
> >    [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
> >        Levels", RFC 2119, March 1997.
> >
> > Dommety                                                 [Page 4]
> >
> > Internet Draft   Key and Sequence Number extensions to GRE   February 2000
> >
> > Author Information
> >
> >    Gopal Dommety
> >    Cisco Systems, Inc.
> >    170 West Tasman Drive
> >    San Jose, CA 95134
> >    e-mail: gdommety@cisco.com
> >
> > Dommety
> >
> > Thank You.
> > Regards,
> > Gopal
> > -------------------------------------------------------------------------------------------------------------
> >
> > Gopal Dommety
> > 408 525 1404
> > gdommety@cisco.com
> > Cisco Systems, San Jose, CA, 95051
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 10 17:18:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13030
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 10 Mar 2000 17:18:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EEFC6280@standards.nortelnetworks.com>; Fri, 10 Mar 2000 17:13:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84270 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 17:11:24
          -0500
Received: from fwns2.raleigh.ibm.com (204.146.167.236) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.43F00B40@standards.nortelnetworks.com>; Fri, 10 Mar 2000
          17:01:23 -0500
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com
          [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with
          ESMTP id RAA31740; Fri, 10 Mar 2000 17:04:54 -0500
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by
          rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id
          RAA35136; Fri, 10 Mar 2000 17:04:57 -0500
Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by
          rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id
          RAA23668; Fri, 10 Mar 2000 17:04:39 -0500
Message-ID:  <200003102204.RAA23668@rotala.raleigh.ibm.com>
Date:         Fri, 10 Mar 2000 17:04:39 -0500
Reply-To: gre@ops.ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft Extensions
X-To:         Rene Tio <tor@redback.com>
X-cc:         Ajoy Singh <ASINGH1@email.mot.com>,
              Gopal Dommety <gdommety@cisco.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Message from Rene Tio <tor@redback.com> of "Fri, 10 Mar 2000
              11:08:26 PST." <20000310110826.B16343@redback.com>

Folks,

I'm redirecting followups to the gre list. To join:

    majordomo@ops.ietf.org
    subscribe gre

Note: there are folks interested in gre outside of mobile-ip. The UDLR
WG has also expressed an interest in this area.

> I do not know if the IESG figures into this since GRE is
> informational. However I would like to know the reason behind the
> updates because draft-meyer + draft-dommety looks pretty close to
> RFC 1701.  The changes appear to be the semantics of the key field,
> which was somewhat semantic free before since its use as an
> authenticator was always suspect, and the split sequence number
> field.  What's the use of deprecating some fields in one draft and
> extending it with the same deprecated fields in another draft?

RFC 1701 is informational. It cannot be referenced by standards track
documents in a normative way.

draft-meyer-gre-update-03.txt has been approved as a Proposed Standard
by the IESG an will be out as an RFC any day now. This document is
backwards compatable with 1701 in the sense that existing
implementations of 1701 are already compliant with the new
standard. However, draft-meyer-gre-update does not include some of the
more exotic extensions that 1701 has. Thus, the new GRE document isn't
for everyone, as it doesn't include the key and sequence
fields. meyer-gre-update is just the basics, no fluff.

The purpose of draft-dommety is to define some new options to GRE that
may in fact look suprisingly like some of the fields in 1701 that
don't appear in draft-meyer-gre-update. One problem with 1701's
definition of those fields is that they are underspecified (you can't
implement them from 1701) and its not even clear whether everyone
would agree on what semantics those fields should have. draft-dommety
is intended to find consensus on what those other fields should be (at
least from the perspectives of mobile IP).

Questions like should GRE extensions use a new version number, etc.,
need to hashed out on the gre list.

Thomas


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 11 02:26:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20670
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 11 Mar 2000 02:26:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F524E60@standards.nortelnetworks.com>; Sat, 11 Mar 2000 2:21:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 84641 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 11 Mar 2000 02:20:04
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E9C23B50@standards.nortelnetworks.com>; Sat, 11 Mar 2000 2:10:03
          -0500
Received: from dns.aiba.chuo.tokyo.jp (dns.aiba.chuo.tokyo.jp [210.232.66.210])
          by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA10355 for
          <mobile-ip@smallworks.com>; Sat, 11 Mar 2000 01:14:01 -0600 (CST)
Received: from gorvhow (98AC32E3.ipt.aol.com [152.172.50.227]) by
          dns.aiba.chuo.tokyo.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with
          SMTP id QAA01866; Sat, 11 Mar 2000 16:14:23 +0900
Message-ID:  <200003110714.QAA01866@dns.aiba.chuo.tokyo.jp>
Date:         Sat, 11 Mar 2000 16:14:23 +0900
Reply-To: incomenews@CCNMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: incomenews@CCNMAIL.COM
Subject:      [MOBILE-IP] How to make $100 - $500 a day
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

  If You Would Like To Earn $100 - $1,500 a Day,
  Then You'll Definitely Be Interested In The Free Info. Below!


Now You Can Sell an Intriguing Product For $100-$1,500
           and Pay Only $1 For The Product!

     You'll NEVER have more FUN than this,
         while making so much MONEY!

As You Can See With These Kinds of Profits, Your Income
Potential Is Unlimited!

All entrepreneurs want to either start or grow a successful home-based
business of their own.  Problem?  Capital.  It costs money to start a
business.

Before, home-based businesses were used to "make money on the side"
while still climbing the corporate ladder. But now, people are actually
working jobs *Only* to Make Money to start or grow their home-based
business.

Once the business takes off, they take off from their job.

This all leads up to why we're emailing you in the first place.  We
know you've been looking for opportunities.  We have come across an
exciting low-cost legitimate biz-op which you may have easily
overlooked.

You will see the shift from 'moonlighting' to 'daylighting' when you
check out the company.

The product offered is both unique and original: it's custom ceiling
murals that glow brilliantly in the dark!

It's an accurate three dimensional painting of the night sky
-- invisible during the day... but at night when the lights are off it
looks as though the ceiling has been removed and thousands of stars are
above you.

You'll see shooting stars, the majestic Milky Way galaxy and
constellations like the Big Dipper and Pegasus, The Princess Andromeda
and others. Planets like Mars, Jupiter, Venus, and even the Moon!

As you're looking up, you'll notice your stress disappearing.  It's
like having a 'convertible ceiling'! ... an incredible three dimensional
vista that you have to see to appreciate.

It's relaxing, stress relieving, romantic and educational for adults
and children -- at home or in hotels and motels (imagine you're driving
down the road looking for a motel and you see a sign that says "relax
under the stars"  -- wouldn't you pull in?)  Obviously your customers
are everyone with a bedroom at home plus all the hotels, motels, bed&
breakfasts, resorts, etc., -- everywhere.

I know you want to hear about How You Make Money.  Here it is!
Your product cost per room is only $1.  You get $100 to $500 per room!
And with the companies' secret methods, you'll easily create the
amazing mural in about one hour! The perfect part-time or full-time
money making opportunity for you. Why wish for the moon when you can
have the stars?

This business most likely has no competition.  You can start it for
pennies.  Your customers are both consumers and businesses (it's currently
found even in high-class 5-star hotels)!

To receive more FREE information on Your Perfect Home Business Opportunity,
Simply Email Us Back The Following Information To mailto:starbiz26@newmail.net

Name:
E-Mail:
Phone:
Street:
City:
State:
ZIP or Postal Code:
Country (available INTERNATIONALLY):

PS As a bonus, if you respond now, you'll get a FREE monthly
Bizop E-zine and postings with important messages to the home-based
entrepreneur!

mailto:starbiz26@newmail.net


To unsubscribe, mailto:unsubscribe310@newmail.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar 12 12:56:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25539
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 12 Mar 2000 12:56:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C360BE90@standards.nortelnetworks.com>; 12 Mar 2000 12:52:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 85524 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 12 Mar 2000 12:50:41
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.92795DA0@standards.nortelnetworks.com>; 12 Mar 2000 12:50:40 -0500
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 JAA09309;
          Sun, 12 Mar 2000 09:54:43 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id JAA23996; Sun, 12 Mar 2000 09:50:52 -0800
X-Virus-Scanned:  Sun, 12 Mar 2000 09:50:52 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from <charliep@iprg.nokia.com> (maxdialin33.iprg.nokia.com
          [205.226.20.227]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma023860; Sun, 12 Mar 00 09:50:48 -0800
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38CBD98A.D5079862@iprg.nokia.com>
Date:         Sun, 12 Mar 2000 09:53:14 -0800
Reply-To: charliep@iprg.nokia.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "C. Perkins/D. Reese" <charliep@iprg.nokia.com>
Subject:      [MOBILE-IP] Draft revisions
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

On behalf of several sets of authors, I have submitted new
revisions of several Internet Drafts, on the following subjects:
- Regional Registration
        www.iprg.nokia.com/~charliep/txt/mobiletun/regtun.txt
- Generalized AAA keys
        www.iprg.nokia.com/~charliep/txt/genkey/genkey.txt
- AAA requirements from Mobile IP
        www.iprg.nokia.com/~charliep/txt/aaareqs/aaa-reqs.txt
- AAA for IPv6 Network Access
        www.iprg.nokia.com/~charliep/txt/aaav6/aaav6.txt
- GTP
        www.iprg.nokia.com/~charliep/txt/gtp/gtp.txt
- Registration Keys for Route Optimization
        www.iprg.nokia.com/~charliep/txt/regkey/regkey.txt

They are available at the indicated URLs for those who
would like to make comments before the last-minute flood
of Internet Drafts works its way through IETF processing.
The last draft on Registration Keys, which incorporates
many excellent suggestions from N. Asokan, didn't make it
before the draft submission cutoff deadline.  The drafts on
GTP and AAAv6 should be considered highly preliminary,
and largely submitted to stimulate discussion.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar 12 15:00:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09551
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 12 Mar 2000 15:00:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17F27690@standards.nortelnetworks.com>; 12 Mar 2000 14:56:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 85564 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 12 Mar 2000 14:54:32
          -0500
Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DFC05300@standards.nortelnetworks.com>; 12 Mar 2000 14:54:31 -0500
Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu
          (8.9.3/8.9.3) with ESMTP id LAA86355 for
          <mobile-ip@standards.nortelnetworks.com>; Sun, 12 Mar 2000 11:59:02
          -0800 (PST)
Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with
          ESMTP id LAA90668 for <mobile-ip@standards.nortelnetworks.com>; Sun,
          12 Mar 2000 11:59:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.BSF.4.10.10003121156410.90608-100000@rumi.usc.edu>
Date:         Sun, 12 Mar 2000 11:59:24 -0800
Reply-To: Meeta Sharma <meeta@CATARINA.USC.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Meeta Sharma <meeta@CATARINA.USC.EDU>
Subject:      [MOBILE-IP] timer values!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,


I was doing some analysis of the mobile ip protocol (RFC2002). There are
various timers that are implemented, but the exact values have not been
sepcified.

Could you give me an idea about the range of the timers for the values are
quite important for my modeling.

Thanks,
Meeta


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 02:26:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22259
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 02:26:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DCC587F0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:21:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 85885 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 02:20:18
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ACE22980@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:20:18
          -0500
Received: from gdommety-pc2 (gdommety-dsl3.cisco.com [10.19.17.140]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          XAA13355; Sun, 12 Mar 2000 23:24:14 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <200003092018.MAA17086@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003130724.XAA13355@omega.cisco.com>
Date:         Sun, 12 Mar 2000 23:36:52 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Ajoy Singh <ASINGH1@email.mot.com>
X-cc:         gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C92FF2.1F789629@email.mot.com>

At 11:25 AM 10/03/00 -0600, Ajoy Singh wrote:
>Hello Gopal,
>
>Here is couple of questions i have regarding the attached GRE draft.  I have not participated in previous
>discussion of GRE, so i am
>not aware of any decision made by IESG regarding this respect.
>
>1. What is the Value of Version number field of  proposed GRE header ?  Is it 0 or something else ?  Does it mean

The Version is 0.

>that all existing GRE implementations need to change to support this header format to be standard compliant?  I
>was hoping that we can use different version number to support the new extensions and that way we do not require
>to change existing deployment of GRE. This way any network element can discard right away the GRE packets which
>it does not support ?

This is an addendum to the draft-meyers. Using a different version number will definetly make it easy. If the version number is
to be changed then we have to change it in  draft-meyers.

We should definetly not need to change all existing GRE implementations.

>2. In GRE header format you have  specified RX Sequence number which seems to me same as ack sequence number of
>PPTP GRE. Why we need similar thing represented in two different way in two different standards ?

We can  use the all the four octects for the Transmit sequence as in PPTP and if it is determined that we need an acknowledgement
feild, we can think about the acknowledgement extension. I will make that change.

BTW: PPTP uses the value of 1 for Version number.



>
>thanks,
>ajoy
>
>Gopal Dommety wrote:
>
>> Hello:
>>
>> I am  attaching the  GRE addendum/extensions.  As  you go  through the
>>  draft at places identified by # there are request for comments. I have
>> split the sequence no into two subfeilds (the other option is to define an
>> acknowledgement like PPTP WHEN such a need it felt).
>>
>> Please send  your comments to  gre@ops.ietf.org mailing list.  you can
>> subscribe   to   this   mailing   list   by  sending   an   email   to
>> request-gre@ops.ietf.org
>>
>> Thanks
>> Gopal
>>
>> Network Working Group                                      Gopal Dommety
>> INTERNET DRAFT                                             cisco Systems
>> March 2000
>>
>> Expires October 2000
>>
>>                 Key and Sequence Number Extensions to GRE
>>                     draft-dommety-gre-ext-00.txt
>>
>> Status of this Memo
>>
>>    This document is a submission by the Network Working Group of the
>>    Internet Engineering Task Force (IETF).  Comments should be submitted
>>    to the gre@ops.ietf.org mailing list.
>>
>>    Distribution of this memo is unlimited.
>>
>>    This document is an Internet Draft and is in full conformance with
>>    all provisions of Section 10 of RFC2026. Internet Drafts are working
>>    documents of the Internet Engineering Task Force (IETF), its areas,
>>    and working groups. Note that other groups may also distribute
>>    working documents as Internet Drafts.
>>
>>    Internet Drafts are draft documents valid for a maximum of six months
>>    and may be updated, replaced, or obsoleted by other documents at any
>>    time. It is inappropriate to use Internet Drafts as reference
>>    material or to cite them other than as "work in progress."
>>
>>    The list of current Internet-Drafts can be accessed at
>>    http://www.ietf.org/ietf/1id-abstracts.txt.
>>
>>    The list of Internet-Draft Shadow Directories can be accessed at
>>    http://www.ietf.org/shadow.html.
>>
>> Abstract
>>
>>    This  document describes extensions  by which  two fields,  Key and
>> Sequence Number, can be optionally carried in the GRE (Generic Routing
>> Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
>> of an arbitrary network  layer protocol over another arbitrary network
>> layer  protocol.
>>
>> Dommety                                                           [Page 1]
>>
>> Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>>
>> 1. Introduction
>>
>>    Current specification of Generic Routing Encapsulation [1] specifies
>> a protocol  for encapsulation of  an arbitrary network  layer protocol
>> over another arbitrary network layer protocol. This document describes
>> enhancements  by which  two fields,  Key and  Sequence Number,  can be
>> optionally carried  in the GRE  Header [1]. The  Key field is  used to
>> create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
>> is used to maintain sequence of packets within a GRE Tunnel.
>>
>> 1.1. Specification Language
>>
>>    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>    this document are to be interpreted as described in RFC 2119 [3].
>>
>>    In addition, the following words are used to signify the
>>    requirements of the specification.
>>
>>    Silently discard
>>               The implementation discards the datagram without
>>               further processing, and without indicating an error
>>               to the sender.  The implementation SHOULD provide the
>>               capability of logging the error, including the contents
>>               of the discarded datagram, and SHOULD record the event
>>               in a statistics counter.
>>
>> 2. Extensions to GRE Header
>>
>>    The GRE packet header[1] has the following format:
>>
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |C|       Reserved0       | Ver |         Protocol Type         |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |      Checksum (optional)      |       Reserved1 (Optional)    |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>     The proposed GRE header will have the following format:
>>
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |      Checksum (optional)      |       Reserved1 (Optional)    |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |                         Key (optional)                        |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |  Rx Sequence Number (Optional)| Tx Sequence Number (Optional) |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       Key Present (bit 2)
>>
>>       If the Key Present bit is set to 1, then it indicates that the Key
>>       field is present in the GRE header.  Otherwise, the Key field is
>>       not present in the GRE header.
>>
>>       Sequence Number Present (bit 3)
>>
>>       If the Sequence Number Present bit is set to 1, then it indicates
>>       that the Sequence Number field is present.  Otherwise, the
>>       Sequence Number field is not present in the GRE header.
>>
>>       The  Key and Sequence Present bits are chosen to be  compatible
>>       with RFC 1701 [2].
>>
>> 2.1. Key Field (4 octets)
>>
>>      The Key field contains a  four octet number which was inserted by
>>      the encapsulator. The actual method by which this Key is obtained
>>      is beyond the scope of this document.  Key field is intended to be
>>      used for  creating separate sub-tunnels within a  GRE Tunnel and the
>>      Key field identifies the sub-tunnel.
>>
>> 2.2. Sequence Number (4 octets)
>>
>>     The Sequence Number  field is divided into two  sub-fields (Tx and
>>     Rx sequence number). These subfields are inserted by the encapsulator
>>     when Sequence Number Present Bit is set . Tx Sequence Number  MUST
>>     be used by the receiver to establish the  order in which  packets
>>     have been  transmitted from the  encapsulator  to  the  receiver.
>>     The intended  use  of  the Tx Sequence  Field is  to provide
>>     unreliable and in-order delivery.   If the Key  present bit (bit 2)
>>     is set, the sequence number is specific to the sub-tunnel identified
>>     by the Key field.
>>
>>     The Tx sequence number  value ranges from 1 to  65535. The first
>>     datagram is sent with a Tx sequence number of 1. The Tx sequence
>>     number is thus a free running counter represented modulo 65536,
>>     with the exception that 1 is used when modulo 65536 results in 0
>>     (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
>>
>> #Q The Rx can be the Tx  sequence number of the last successfully decap
>>   pack.  And  say  that  how  you  use  this  info  is  implementation
>>   dependent.  I am currently saying Rx sequence no
>>   is set to 0. Comments?
>
>The only possible way this sequence number can be used to support some type of sliding window protocol either for
>
>flow control or retransmission. I belive this does
>
>>
>>
>>     When the decapsulator receives an out-of sequence packet it SHOULD
>>     be silently discarded. Additionally, reordering of out-of sequence
>>     packets  MAY  be  performed   by  the  decapsulator  for  improved
>>     performance and  tolerance to reordering in the  network (since the
>>     state of the stateful compression or encryption is reset by packet
>>     loss, it  might help the  performance to tolerate some  amount of
>>     packet reordering in the network by buffering). Exact buffering
>>     schemes are outside the scope
>>     of  this  document. Note that the  Tx sequence number is used to detect
>>     lost packets and/or restore  the original sequence of packets that
>>     may have been reordered during transport.
>>
>>    A packet  is considered an out-of-sequence packet  if the Tx sequence
>>    number  of  the  received packet  is  lesser than or equal to  the Tx
>>    sequence  number   of last  successfully  decapsulated
>>    packet. The  Tx sequence number  of a received message is considered
>>    less than or equal to the last successfully received Tx sequence number
>>    if its value lies in the range of the last received Tx sequence number
>>    and the preceding 32766 values, inclusive.  For example, if the last
>>    successfully received Tx sequence number was 15, then messages with Tx
>>    sequence numbers 1 through 15, as well as 32784 through 65535, would be
>>    considered less than or equal. Such a message would be considered an
>>    out-of-sequence packet and  ignored from processing.
>>
>>     If the received packet is an in-sequence packet, it is successfully
>>     de capsulated. Note that  the TX sequence number is  used to detect
>>     lost packets and/or restore the original sequence of packets (with
>>     buffering) that may have been reordered during transport.
>>
>> #C I have considered trying to  have a different starting point for TX
>> sequence nos  during rollover and initial starting  point.  This would
>> let a node  identify if the other end  reset (like agent advertisement
>> sequence no to identify reboot and normal rollover). This is useful if
>> we keep  turning on  and off  sequence nos option  in a  tunnel. Since
>> there  is no  security it  is easy  for others  to reset  the sequence
>> also. Comments?
>>
>> 3. IANA Considerations
>>
>> 4. Acknowledgments
>>
>> 5. References
>>
>>    [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>>    "Generic           Routing           Encapsulation          (GRE),"
>>    draft-meyer-gre-update-03.txt, January 2000.
>>
>>    [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>>    Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>>    October 1994.
>>
>>    [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>>        Levels", RFC 2119, March 1997.
>>
>> Dommety                                                 [Page 4]
>>
>> Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>>
>> Author Information
>>
>>    Gopal Dommety
>>    Cisco Systems, Inc.
>>    170 West Tasman Drive
>>    San Jose, CA 95134
>>    e-mail: gdommety@cisco.com
>>
>> Dommety
>>
>> Thank You.
>> Regards,
>> Gopal
>> -------------------------------------------------------------------------------------------------------------
>>
>> Gopal Dommety
>> 408 525 1404
>> gdommety@cisco.com
>> Cisco Systems, San Jose, CA, 95051
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 02:46:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00410
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 02:46:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9D5A570@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:41:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 85921 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 02:40:20
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7973C830@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:40:20
          -0500
Received: from gdommety-pc2 (gdommety-dsl3.cisco.com [10.19.17.140]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          XAA14315; Sun, 12 Mar 2000 23:42:51 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <200003092046.MAA21507@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003130742.XAA14315@omega.cisco.com>
Date:         Sun, 12 Mar 2000 23:55:23 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         "Frederick N. Chase" <fnc@mitre.org>
X-cc:         ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org,
              dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com,
              udlr@sophia.inria.fr, narten@raleigh.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38C94502.7D3D5026@mitre.org>

At 01:54 PM 10/03/00 -0500, Frederick N. Chase wrote:
>Re:  Key and Sequence Number Extensions to GRE
>
>
>
>The proposed use of two previously-reserved header bits
>in  draft-dommety-gre-ext-00.txt
>differ in a fundamental way.
>
>The proposed use of a reserved bit as a
>"Sequence Number Present" bit is a
>potentially-beneficial modifier
>on encapsulator/decapsulator behavior and therefore
>seems to me to be advisable or at least not inadvisable.
>
>The proposed use of a reserved bit as a
>"Key Present" bit does not affect (narrowly construed)
>encapsulator/decapsulator behavior but rather
>concerns the processor of the encapsulated or decapsulated
>data.  This proposal seems to me to be inadvisable.
>
>Acceptance of the "Key Present" proposal unnecessarily
>encumbers some other
>processor of encapsulated or decapsulated data
>which might like to have an optional extra 32 bits for some purpose
>where the terms "Key and "sub-tunnel" would be
>confusing and inappropriate.

Fred,

        I am not sure of the concern. Would appreciate if you could explain.
Is your concern that we have to maintain a  Sequence number per Key when both are present? Or that
earlier (in RFC1701) it was supposed to be  used by the receiver to authenticate
      the source of the packet?

Thanks
Gopal




>
>
>   -Fred Chase
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 06:39:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22630
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 06:39:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C4A9300@standards.nortelnetworks.com>; Mon, 13 Mar 2000 6:34:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86031 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 06:33:47
          -0500
Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.13BB6D10@standards.nortelnetworks.com>; Mon, 13 Mar 2000 6:33:43
          -0500
Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp
          [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP
          id UAA18703; Mon, 13 Mar 2000 20:36:24 +0900 (JST)
Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp
          [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with
          ESMTP id UAA12161; Mon, 13 Mar 2000 20:36:24 +0900 (JST)
Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by
          isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id UAA05974; Mon,
          13 Mar 2000 20:36:23 +0900 (JST)
References: <51F347B016ADD011963200805FC1456204BCBF5F@email1.wes.mot.com>
            <200003080554.VAA25162@sigma.cisco.com>
X-Mailer: Datula version 1.21.09 for Windows
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <200003131136.UAA05974@isl.rdc.toshiba.co.jp>
Date:         Mon, 13 Mar 2000 20:46:58 +0900
Reply-To: Yoshiyuki Tsuda <tsuntsun@ISL.RDC.TOSHIBA.CO.JP>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Yoshiyuki Tsuda <tsuntsun@ISL.RDC.TOSHIBA.CO.JP>
Organization: Corporate R&D Center, Toshiba Corporation
Subject:      Re: [MOBILE-IP] RFC2002 bis
X-To:         "Kent K. Leung" <kleung@CISCO.COM>, charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003080554.VAA25162@sigma.cisco.com>

Hello, Charlie and Kent,

 As Kent has already sent an email to this mailing-list, at the Connectathon,
 we found and agreed there was an unclear specification about replying an
 error by an FA to an MN, which would lead to an interoperability problem.
 I don't know wheather it should be specified in the 2002bis or it is
 described in aother draft.

 In case that an FA replys to an MN with error-code, I was once assuming as
 the followings:
 1) The FA creates an registration reply with a proper error-code.
 2) A dummy Mobile-Home Authentication extension, which may be copied from
    the received registration request, should be included in the above
    registration reply.
 3) If an MN receives such a registration reply, according to the error-
    code, the MN should skip checking the Mobile-Home Authentication
    extension.
 4) But, an MN should check there is only one Mobile-Home Authentication
    extension.

 Now, I have the following questions:
 a) Should a dummy Mobile-Home Authentication extension be included in such
    a reply ?  It is meaningless.  But, if an MN checks its existence, it
    must be included.
 b) May an MN skip checking a Mobile-Home Authentication extension in case
    of such an error-code ?  A man-in-the-middle problem may occur, if there
    is no SA between the FA and the MN.
 c) Should an MN check there is only one Mobile-Home Authentication extension
    in such a reply ?  If an FA doesn't include this extension, an MN will
    discard such a reply silently.

 I'd like to know some consensus to the above issue.

Thanks in advance.
-Yoshi


On Tue, 7 Mar 2000 21:54:27 -0800,  Kent K. Leung wrote:
>> One area that's not covered by RFC2002bis is how Mobile Node
>> as well as Foreign Agent should deal with Mobile-Home Authentication
>> Extension (MHAE) when FA replies with error code.  There are 2 scenarios
>> when FA rejects registration: 1) FA denies registration request
>> (ie requested lifetime greater than advertised) and 2) FA sends
>> rejection when HA reply is bad (ie Foreign-Home Authentication
>> Extension check fails).  In either case, the authenticator in
>> Mobile-Home Authentication Extension is invalid when received by
>> MN.
>>
>> So when registration is rejected by FA, the MN will silently
>> discard reply because authenticator is invalid.
>>
>> Seems like some MN implementation skips MHAE if the error code
>> is from FA.  But then this can lead to bad guy sending rejections
>> even when registration being accepted by HA, maybe a little later.
>> One possible solution is that MN can believe rejection reply if
>> MFAE exists or after it allows enough time for reply from HA to arrive.
>>
>> We need some more information in section 3.6.2.3 "Registration Request
>> Denied" in how Mobile Node handle denials from FA, section 3.7.2.3
>> "Denying Invalid Requests" and section 3.7.3 "Receiving Registration
>> Replies" in how FA deal with MHAE when generating a rejection reply.
>>
>> -- Kent --
>>
>> >
>> > It's important to turn this around quickly if we want it to replace 2002 and
>> > then move this from proposed standard to draft standard.  We discussed in
>> > Washington about the amount of work that will be involved from moving to
>> > proposed to draft and agreed that we should update 2002 while working on
>> > getting enough implementations to move to draft standard.  Getting the
>> > replacement done quickly would allow us to get to draft standard this year,
>> > hopefully.
>> >
>> > Phil
>>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 09:55:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04977
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 09:55:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2BE3090@standards.nortelnetworks.com>; Mon, 13 Mar 2000 9:50:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86133 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 09:49:10
          -0500
Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FBBA1B20@standards.nortelnetworks.com>; Mon, 13 Mar 2000 9:39:09
          -0500
Received: (from dmm@localhost) by sigma.cisco.com (8.8.8-Cisco List
          Logging/8.8.8) id GAA12264; Mon, 13 Mar 2000 06:43:06 -0800 (PST)
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003131443.GAA12264@sigma.cisco.com>
Date:         Mon, 13 Mar 2000 06:43:06 -0800
Reply-To: David Meyer <dmm@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: David Meyer <dmm@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Gopal Dommety <gdommety@cisco.com>
X-cc:         Ajoy Singh <ASINGH1@email.mot.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003130724.XAA13355@omega.cisco.com> from "Gopal Dommety" at
              Mar 12, 2000 11:36:52 PM
Content-Transfer-Encoding: 7bit

> This is an addendum to the draft-meyers. Using a different version number will definetly make it easy. If the version number is
> to be changed then we have to change it in  draft-meyers.

        We've been through this and decided not to change the
        version number.

> We should definetly not need to change all existing GRE implementations.

        right, should be backwardly compatable.


        Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 10:32:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19137
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 10:31:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB8DCC30@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:27:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86168 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 10:25:39
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.142EFE50@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:15:38
          -0500
Received: from ani.univie.ac.at (heraklit.ani.univie.ac.at [131.130.32.104]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA25321 for
          <mobile-ip@smallworks.com>; Mon, 13 Mar 2000 09:19:43 -0600 (CST)
Received: from www.archimedes.ani.univie.ac.at (archimedes [131.130.32.138]) by
          ani.univie.ac.at (8.9.3/8.8.8) with ESMTP id QAA28060 for
          <mobile-ip@smallworks.com>; Mon, 13 Mar 2000 16:14:03 +0100 (MET)
Received: (from gabi@localhost) by www.archimedes.ani.univie.ac.at
          (8.8.8+Sun/8.8.8) id QAA02845 for mobile-ip@SMALLWORKS.COM; Mon, 13
          Mar 2000 16:20:42 +0100 (MET)
Message-ID:  <200003131520.QAA02845@www.archimedes.ani.univie.ac.at>
Date:         Mon, 13 Mar 2000 16:20:42 +0100
Reply-To: Gabriele Kotsis <gabi@ANI.UNIVIE.AC.AT>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gabriele Kotsis <gabi@ANI.UNIVIE.AC.AT>
Subject:      [MOBILE-IP] CFP HiPC2000
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

               Special Session On High Performance Middleware

 7th International Conference on High Performance Computing (HiPC2000)
 December 17-20, 2000  -  Bangalore, India
 Deadline 19th April 2000


Session Chairs                  Important Dates
---------------                 ----------------
Shikharesh majumdar             May 1, 2000     Conference Paper Due
Systems and Computer Eng.       June 30, 2000   Notification of Acceptance
Carleton University,            August 15, 2000 Camera-Ready Paper Due
Ottawa, CANADA,
majumdar@sce.carleton.ca

Gabriele Kotsis
Institut fur Informatik und Wirtschaftsinformatik
University of Vienna
Vienna, AUSTRIA
gabriele.kotsis@univie.ac.at

Heterogeneity is natural in distributed systems. Middleware provides
the necessary inter-operability and the communication infrastructure
required in such systems in which application components that are
implemented using diverse technology can communicate with one
another. The importance of the topic is reflected in the great deal of
research and development work performed in the area in both industry
and academia. The rapid growth in interest on the topic is reflected
in the existence of middleware conferences, special issues of journals
on the topic, the emergence of standards such as CORBA and DCOM as
well as the availability of a number of commercial products. Although
middleware provides inter-operability, if not designed carefully, it
can introduce a serious performance penalty. Achieving high
performance is crucial in telecommunication products, embedded
systems, and other performance demanding applications. The growing
interest in performance issues is reflected in recent papers on the
topic and a proposal for a standard on Real Time CORBA submitted to OMG.

Our objective is to provide an opportunity for researchers in this new
and exciting area to present and discuss their research on middleware
performance. The special session seeks original, unpublished papers
on all performance aspects of middleware for distributed applications
including case studies on the use of middleware technologies. The
topics of interest include (but are not limited to):

-- real-time middleware systems and support for QoS
-- performance issues in middleware for mobile systems
-- multimedia support for middleware
-- performance of protocols for middleware
-- high performance adaptive systems and reflective middleware
-- application of middleware technologies to performance demanding applications
-- performance characterization of middleware products
-- performance issues related to CORBA and DCOM
-- the impact of middleware architecture on system scalability
-- the performance implications of milddleware on java-based systems.

Papers will be reviewed and the selected papers will be included in
the conference proceedings to published by Springer Verlag.

Submission Guidelines:
----------------------

The paper must be clearly identified as submitted to the "High Performance
Middleware" session. Other submission guidelines are identical to the HiPC
guidelines. Papers are to be sent to the HiPC program Chair. The
guidelines are summarized here (for details, see www.hipc.org). The selected
papers will be printed in the conference proceedings.

Submit original research papers not to exceed 15 double-spaced pages
of text using 12-point size type on 8.5 x 11 inch pages. Figures and
Tables may use additional pages. Preferably send your paper as a
correct PostScript (level 2) file. Ensure the PostScript prints on
PostScript printers using 8.5x11 paper. In addition to the PostScript,
your Email must include, in ASCII form: title, author name(s),
abstract, postal address, e-mail address, and telephone and fax
numbers. Include "High Performance Middleware" in the ASCII header as well
as in the paper title page.

Send Electronic submissions to: hipc2000@ac.upc.es

Alternatively send 6 hard copies (by mail, not fax) to the program chair:

Mateo Valero
Dept. de Arquitectura de Computadores
Universidad Politecnica de Catalunya
c/ Jordi Girona 1-3, Modulo D6
08034 Barcelona, SPAIN
Internet: mateo@ac.upc.es


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 10:42:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23028
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 10:42:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35E296D0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:38:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86186 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 10:36:15
          -0500
Received: from imc21.ex.nus.edu.sg by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F56D9500@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:36:15
          -0500
Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id
          <G2AGBTR0>; Mon, 13 Mar 2000 23:40:21 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <415039BB7DE8D011BC4600805F311E1602BD0B0D@exs25.ex.nus.edu.sg>
Date:         Mon, 13 Mar 2000 23:40:24 +0800
Reply-To: Sufatrio <scip8001@NUS.EDU.SG>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sufatrio <scip8001@NUS.EDU.SG>
Subject:      Re: [MOBILE-IP] RFC2002 bis
X-cc:         "kleung@CISCO.COM" <kleung@CISCO.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Kent,

In a situation where:
no secret-key based security association exists between MN and FA,
or public-key based authentication is not in use,
there is no way for MN to directly verify the authenticity/integrity of
a rejected Request message from FA.

Since RFC2002 only mandates the existence of shared-key based
security association between MN and HA, I think I agree
with you that more detailed specification is required
should FA reject a Request (with regard to the genuineness of that Replay).

An alternative strategy is that either :
(I assume that FA and HA can authenticate each other)

(1)  FA still relays the Request message to HA (with the indicated error
code)
     just in order for MN to get an authenticated (Mobile-Home-AE) rejected
Reply.
     This might be useful for error codes such as:
        69 requested Lifetime too long,
        72 requested encapsulation unavailable,
        73 requested Van Jacobson compression unavailable,
     which FA still can expect MN to send a valid Request in its next
registration attempt.

(2)  FA sends an unauthenticated Replay for error codes that are considered
"fatal"
     or that option (1) above is not possible to be carried out, such as:
        70 poorly formed Request
        80 home network unreachable (ICMP error received)
        81 home agent host unreachable (ICMP error received)
        82 home agent port unreachable (ICMP error received)
     However, in this case MN must intelligently wait for some time, in
order to
     anticipate a case where a bad guy sends a rejected Reply that comes
earlier
     than its genuine successful Reply (which you mentioned in your email).

Cheers,
~rio

> ----------
> From:         Kent K. Leung[SMTP:kleung@CISCO.COM]
> Reply To:     Kent K. Leung
> Sent:         08 March 2000 13:54
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] RFC2002 bis
>
> One area that's not covered by RFC2002bis is how Mobile Node
> as well as Foreign Agent should deal with Mobile-Home Authentication
> Extension (MHAE) when FA replies with error code.  There are 2 scenarios
> when FA rejects registration: 1) FA denies registration request
> (ie requested lifetime greater than advertised) and 2) FA sends
> rejection when HA reply is bad (ie Foreign-Home Authentication
> Extension check fails).  In either case, the authenticator in
> Mobile-Home Authentication Extension is invalid when received by
> MN.
>
> So when registration is rejected by FA, the MN will silently
> discard reply because authenticator is invalid.
>
> Seems like some MN implementation skips MHAE if the error code
> is from FA.  But then this can lead to bad guy sending rejections
> even when registration being accepted by HA, maybe a little later.
> One possible solution is that MN can believe rejection reply if
> MFAE exists or after it allows enough time for reply from HA to arrive.
>
> We need some more information in section 3.6.2.3 "Registration Request
> Denied" in how Mobile Node handle denials from FA, section 3.7.2.3
> "Denying Invalid Requests" and section 3.7.3 "Receiving Registration
> Replies" in how FA deal with MHAE when generating a rejection reply.
>
> -- Kent --
>
> >
> > It's important to turn this around quickly if we want it to replace 2002
> and
> > then move this from proposed standard to draft standard.  We discussed
> in
> > Washington about the amount of work that will be involved from moving to
> > proposed to draft and agreed that we should update 2002 while working on
> > getting enough implementations to move to draft standard.  Getting the
> > replacement done quickly would allow us to get to draft standard this
> year,
> > hopefully.
> >
> > Phil
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 10:58:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29833
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 10:58:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73C8C580@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:54:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86221 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 10:52:28
          -0500
Received: from imc21.ex.nus.edu.sg by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.39429FD0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:52:28
          -0500
Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id
          <G2AGBTWK>; Mon, 13 Mar 2000 23:56:34 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <415039BB7DE8D011BC4600805F311E1602BD0B0E@exs25.ex.nus.edu.sg>
Date:         Mon, 13 Mar 2000 23:56:35 +0800
Reply-To: Sufatrio <scip8001@NUS.EDU.SG>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Sufatrio <scip8001@NUS.EDU.SG>
Subject:      Re: [MOBILE-IP] RFC2002 bis
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi all,

I also have another question on RFC-2002bis
> regarding its specification of the "Identification" field.
>
> On the use of nonce-based anti-replay protection,
> Section 5.6.2 says the following in its last paragraph:
> "If a registration message is rejected because of an invalid nonce,
>  the Reply always provides the mobile node with a new nonce to
>  be used in the next registration.  Thus the nonce protocol is
>  self-synchronizing."
>
> Though it sounds OK, however, there might be a little problem
> when an Attacker replays a previous authenticated Request to HA.
>
> In that case, according to the specification above,
> HA will send a rejected Reply with a new nonce included.
> While HA now expects this new nonce in MN's next registration,
> the real MN --which is not expecting any Replies-- will discard that
> Reply.
> MN thus has no knowledge about HA's new nonce.
> As a result, another registration would be uselessly performed,
> should later this legitimate MN initiate a Request.
>
> I would suggest some clarification in RFC-2002bis specification,
> that a new nonce should not be "generated" upon receipt
> of Request with invalid nonce.
> But rather, HA must keep sending the same expected-nonce
> until it receives a Request with that correct nonce
> (though this Request may be rejected for some other reasons).
>
> Thanks.
>
~rio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 12:39:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09788
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 12:39:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.753C9870@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:34:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86345 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 12:33:19
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4FC512C0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:33:18
          -0500
Received: from gdommety-pc2 (gdommety-dsl3.cisco.com [10.19.17.140]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          JAA25646; Mon, 13 Mar 2000 09:37:13 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <200003130724.XAA13355@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003131737.JAA25646@omega.cisco.com>
Date:         Mon, 13 Mar 2000 09:50:03 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         David Meyer <dmm@cisco.com>
X-cc:         Ajoy Singh <ASINGH1@email.mot.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003131443.GAA12264@sigma.cisco.com>

Dave,



At 06:43 AM 13/03/00 -0800, David Meyer wrote:
>
>> This is an addendum to the draft-meyers. Using a different version number will definetly make it easy. If the version number is
>> to be changed then we have to change it in  draft-meyers.
>
>       We've been through this and decided not to change the
>       version number.

I am not suggesting we change the version number. I was clarifying that we cannot change the version no in draft-dommety. If at all it is done
it has to be done in draft-meyers.

Thanks
Gopal


>
>> We should definetly not need to change all existing GRE implementations.
>
>       right, should be backwardly compatable.
>
>
>       Dave
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 12:51:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14906
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 12:51:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.248F7300@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:46:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86354 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 12:45:14
          -0500
Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.947462E0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:35:14
          -0500
Received: (from dmm@localhost) by sigma.cisco.com (8.8.8-Cisco List
          Logging/8.8.8) id JAA00842; Mon, 13 Mar 2000 09:39:02 -0800 (PST)
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003131739.JAA00842@sigma.cisco.com>
Date:         Mon, 13 Mar 2000 09:39:01 -0800
Reply-To: David Meyer <dmm@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: David Meyer <dmm@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Gopal Dommety <gdommety@cisco.com>
X-cc:         Ajoy Singh <ASINGH1@email.mot.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003131737.JAA25646@omega.cisco.com> from "Gopal Dommety" at
              Mar 13, 2000 09:50:03 AM
Content-Transfer-Encoding: 7bit

> >
> >     We've been through this and decided not to change the
> >     version number.
>
> I am not suggesting we change the version number. I was clarifying that we cannot change the version no in draft-dommety. If at all it is done
> it has to be done in draft-meyers.
>

        Sure. But we don't plan to do that.

        Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 13:14:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24249
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 13:14:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CF52250@standards.nortelnetworks.com>; Mon, 13 Mar 2000 13:09:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86424 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 13:07:31
          -0500
Received: from web1301.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B1680250@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:57:31
          -0500
Received: (qmail 16883 invoked by uid 60001); 13 Mar 2000 18:01:31 -0000
Received: from [143.101.112.41] by web1301.mail.yahoo.com; Mon, 13 Mar 2000
          10:01:31 PST
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20000313180131.16882.qmail@web1301.mail.yahoo.com>
Date:         Mon, 13 Mar 2000 10:01:31 -0800
Reply-To: Vikram Venkataraghavan <vikramv25@YAHOO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vikram Venkataraghavan <vikramv25@YAHOO.COM>
Subject:      [MOBILE-IP] soft handoffs?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I would like to know how soft handoffs are taken care
off in Mobile IP.
What sort of communication goes on
between the routers to terminate a connection once the
mobile node moves into another domain?
How is packet loss minimized during handoff?
What are the internet drafts that talk about this
problem?
Thanks in advance,

Vikram Venkataraghavan
NEC America
972-550-5954
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 14:52:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04224
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 14:52:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.103E6DF0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 14:47:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86474 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 14:45:34
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63FC07B0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 14:35:34
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id MAA24139 for
          <mobile-ip@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:39:41
          -0700 (MST)]
Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by
          pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA16252 for
          <mobile-ip@standards.nortelnetworks.com>; Mon, 13 Mar 2000 12:39:39
          -0700 (MST)]
Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id
          <GNL4KTXF>; Mon, 13 Mar 2000 13:39:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7195C03599D9D311BE580008C75697EB0A1A9C@il33exm01.wes.mot.com>
Date:         Mon, 13 Mar 2000 13:39:32 -0600
Reply-To: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Roberts Phil-QA3445 <qa3445@EMAIL1.WES.MOT.COM>
Subject:      [MOBILE-IP] latest agenda
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi folks,

        here's the latest.  We're still looking for some ID titles
(draft-whoever-whatever-x.txt) for some of these.  If you're listed as a
presenter and there is a name where the ID title should be you should
contact me.  We have outstanding requests from others with drafts who would
like your time if you don't have something.

Phil


Draft Agenda for Mobile IP at 47th IETF

First Session  Mon 1530-1730

Intro and Agenda Bashing 5min
IPv6 draft-ietf-mobileip-ipv6-10.txt Dave Johnson 10min
Announcement on IPv6 and AAA discussion Erik Nordmark 5 min
RFC2002bis draft-ietf-mobileip-rfc2002-bis-01.txt Charlie Perkins 10min
Reverse Tunneling draft-ietf-mobileip-rfc2344-bis-00.txt Gabriel Montenegro
10min
AAA draft-ietf-mobileip-aaa-reqts-01.txt Tom Hiller 10min
AAA and IPv6 ?  Charlie Perkins 15min
AAA Keys draft-ietf-mobileip-aaa-keys-01.txt Pat Calhoun 10min
Registration Keys draft-ietf-mobileip-regkeys-01.txt Charlie Perkins 20min
Low Latency Secure Handoff draft-calhoun-mobileip-min-lat-handoff-00.txt Pat
Calhoun 10min
FA assisted handoff draft-calhoun-mobileip-proactive-fa-00.txt 20min

Second Session Tue 0900-1130
Announcement on Connectathon 2000 MIP/AAA/MIPv6 Carl Williams 10min
Fast Handover draft-dommety-mobileip-anchor-handoff-00.txt Gopal Dommety
15min
Fast Handoffs and Routing in Hierarchical Mobile IP ? Karim El-Malki 15min
Xu Mobile IP in 3gWireless draft-ietf-mobileip-3Gwireless-ext-02.txt 15min
GRE draft draft-dommety-gre-ext-00.txt Gopal Dommety 10min
Private IP addresses draft-petri-mobileip-pipe-00.txt  Petri Bernhard 20min
Route Optimization draft-ietf-mobileip-optim-09.txt Charlie Perkins 10min
Regional Registration draft-ietf-mobileip-reg-tunnel-01.txt Eva Gustaffson
15min
Universal Mobile IP ?  John Wang  20min
Generalize NAI draft-mkalil-gnaie-00.txt Pat Calhoun 10min
Dyn HA allocation for multiple sessions ?  Pete McCann 10min


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 16:58:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22130
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 16:58:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2883C60@standards.nortelnetworks.com>; Mon, 13 Mar 2000 16:53:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86626 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 16:51:51
          -0500
Received: from wacko.redbacknetworks.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.07FA15D0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 16:41:50
          -0500
Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com
          [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with
          ESMTP id NAA16808; Mon, 13 Mar 2000 13:44:56 -0800 (PST)
Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id
          NAA15299; Mon, 13 Mar 2000 13:44:55 -0800 (PST)
References: <200003130724.XAA13355@omega.cisco.com>
            <200003131443.GAA12264@sigma.cisco.com>
            <200003131737.JAA25646@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Message-ID:  <20000313134455.C14355@redback.com>
Date:         Mon, 13 Mar 2000 13:44:55 -0800
Reply-To: Rene Tio <tor@REDBACK.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rene Tio <tor@REDBACK.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Gopal Dommety <gdommety@cisco.com>
X-cc:         David Meyer <dmm@cisco.com>, Ajoy Singh <ASINGH1@email.mot.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003131737.JAA25646@omega.cisco.com>; from gdommety@cisco.com
              on Mon, Mar 13, 2000 at 09:50:03AM -0800

On Mon, Mar 13, 2000 at 09:50:03AM -0800, Gopal Dommety wrote:
> At 06:43 AM 13/03/00 -0800, David Meyer wrote:
> >
> >> This is an addendum to the draft-meyers. Using a different version
> >> number will definetly make it easy. If the version number is
> >> to be changed then we have to change it in  draft-meyers.
> >
> >     We've been through this and decided not to change the
> >     version number.
>
> I am not suggesting we change the version number. I was clarifying that we
> cannot change the version no in draft-dommety. If at all it is done
> it has to be done in draft-meyers.
>

I don't see why this has to be so.  draft-meyer is pretty much completely
backward compatible to 1701, whereas draft-dommety isn't.  Thus draft-meyer
doesn't require a version number bump but draft-dommety in its original form
did.

However, if the Sequence Number field were changed to 32 bits, as Gopal
recently suggested, and the only change was to better define the behaviour
of the Sequence Number field, then the need for bumping GRE versions I feel
would be unnecessary.

If, however, you are going to add an Ack sequence number, *and* use the Key
field as some form of tunnel demux, then it's beginning to look a whole lot
like PPTP and I'd probably suggest splitting out the PPTP GRE portions into
a separate draft and making draft-dommety look like it (and bump the version
numbers, eck).

This discussion is sounding very circular at the moment.

Cheers,
Rene


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 13 17:45:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09425
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 13 Mar 2000 17:45:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.45EA9600@standards.nortelnetworks.com>; Mon, 13 Mar 2000 17:40:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 86704 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 17:38:53
          -0500
Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.99EADE10@standards.nortelnetworks.com>; Mon, 13 Mar 2000 17:28:52
          -0500
Received: (from dmm@localhost) by sigma.cisco.com (8.8.8-Cisco List
          Logging/8.8.8) id OAA25511; Mon, 13 Mar 2000 14:32:54 -0800 (PST)
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003132232.OAA25511@sigma.cisco.com>
Date:         Mon, 13 Mar 2000 14:32:54 -0800
Reply-To: David Meyer <dmm@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: David Meyer <dmm@CISCO.COM>
Subject:      Re: [MOBILE-IP] New GRE Draft  Extensions
X-To:         Rene Tio <tor@redback.com>
X-cc:         Gopal Dommety <gdommety@cisco.com>,
              Ajoy Singh <ASINGH1@email.mot.com>,
              gre@ops.ietf.org, l2tp@ipsec.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <20000313134455.C14355@redback.com> from "Rene Tio" at Mar 13,
              2000 01:44:55 PM
Content-Transfer-Encoding: 7bit

> However, if the Sequence Number field were changed to 32 bits, as Gopal
> recently suggested, and the only change was to better define the behaviour
> of the Sequence Number field, then the need for bumping GRE versions I feel
> would be unnecessary.

        This is my feeling as well.
>
> If, however, you are going to add an Ack sequence number, *and* use the Key
> field as some form of tunnel demux, then it's beginning to look a whole lot
> like PPTP and I'd probably suggest splitting out the PPTP GRE portions into
> a separate draft and making draft-dommety look like it (and bump the version
> numbers, eck).

        Ditto.


        Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 14 04:07:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09036
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Mar 2000 04:07:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A90A4C0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 4:02:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87094 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 04:01:01
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.837E4930@standards.nortelnetworks.com>; Tue, 14 Mar 2000 3:51:01
          -0500
Received: from milena.par.univie.ac.at (milena.par.univie.ac.at
          [131.130.186.60]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP
          id CAA01722 for <mobile-ip@smallworks.com>; Tue, 14 Mar 2000 02:55:08
          -0600 (CST)
Received: from nadine (nadine [131.130.186.22]) by milena.par.univie.ac.at
          (8.9.3/8.9.3) with SMTP id JAA04094 for <tfmisc@par.univie.ac.at>;
          Tue, 14 Mar 2000 09:48:49 +0100 (MET)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: C5//Nm/DOI5PSDTEK25B5Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Message-ID:  <200003140848.JAA04094@milena.par.univie.ac.at>
Date:         Tue, 14 Mar 2000 09:48:49 +0100
Reply-To: Thomas Fahringer <tf@par.univie.ac.at>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Fahringer <tf@par.univie.ac.at>
Subject:      [MOBILE-IP] Open Research Position: Performance Prediction of
              Distributed/Parallel Applications
X-To:         tfmisc@par.univie.ac.at
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

The Institute for Software Science at the
University of Vienna is offering within a
long-term research project a

    ********************************************************
    ***  Research Position in Performance Prediction of  ***
    ***     Distributed and Parallel Applications        ***
    ********************************************************

Applicants should have knowledge in one or more of the
following areas:

        + distributed and parallel systems
        + programming skills
            + distributed programming (Java)
            + parallel programming (OpenMP, HPF, MPI, threads, ...)
        + performance modeling (analytical + symbolic + simulation)
        + simulation tools (discrete event simulation)

Position: Research position for a doctoral student or a post-doc.

Starting Date: April 10, 2000

Duration: 3 years

Project Summary:

   The position is offered as part of a long-term research project
   about performance-oriented application development for parallel
   and distributed systems.

   The main task of this position requires to develop a performance
   prediction tool for heterogeneous, object-oriented multi-threaded
   parallel and distributed applications exploiting both data and
   task parallelism. These applications are executed on clusters
   of SMPs or on heterogeneous workstation networks.
   Analytical performance prediction will be used to determine
   parameterized cost functions for small reusable components of a
   parallel/distributed application. Parameters in cost functions
   reflect the problem sizes of an application and the machine sizes
   of a target architecture. Simulation will be used to model
   highly dynamic behavior of applications and architectures, in
   particular, data exchange, synchronization, thread context-switches,
   etc. The performance prediction tool computes various performance
   parameters including estimated execution and communication times,
   synchronization overhead, memory locality, load balance, etc.

For more information, please contact

        Thomas Fahringer (tf@par.univie.ac.at)

=======================================================================
Thomas Fahringer, Ph.D.             Tel: (office): +43 1 310 56 08 - 86
Associate Professor                 Tel: (sec):    +43 1 310 56 08 - 71
University of Vienna                Fax: +43 1 310 56 08 - 88
Institute for Software Science      E-mail: tf@par.univie.ac.at
Liechtensteinstr. 22                WWW: http://www.par.univie.ac.at
A-1090 Vienna, Austria


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 14 08:49:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17463
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Mar 2000 08:49:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9287C950@standards.nortelnetworks.com>; Tue, 14 Mar 2000 8:44:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87425 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 08:43:13
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EF100EF0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 8:33:12
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA04043 for
          <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Mar 2000 06:37:21
          -0700 (MST)]
Received: [from zuk29exm01.euro.css.mot.com (zuk29exm01.euro.csg.mot.com
          [175.6.1.172]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id
          GAA02293 for <mobile-ip@standards.nortelnetworks.com>; Tue, 14 Mar
          2000 06:37:20 -0700 (MST)]
Received: by zuk29exm01.euro.csg.mot.com with Internet Mail Service
          (5.5.2650.21) id <GX40FKHR>; Tue, 14 Mar 2000 13:37:19 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <152A67906B5CD31194D000508B0BB84501514C22@zuk29exm01.euro.csg.mot.com>
Date:         Tue, 14 Mar 2000 13:37:09 -0000
Reply-To: Holt Mark-MARHOLT1 <Mark_Holt@EUROPE27.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Holt Mark-MARHOLT1 <Mark_Holt@EUROPE27.MOT.COM>
Subject:      [MOBILE-IP] Subscribing
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,

Is it possible to subscribe to mail list?

Best Regards

Mark Holt

Solutions Engineering

Personal Network Group

Basingstoke, United Kingdom.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 14 12:02:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04702
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 14 Mar 2000 12:02:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.738D13A0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 11:57:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 87670 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 11:55:51
          -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.3E42CDC0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 11:55:50
          -0500
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Tue Mar
          14 11:59:46 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Tue Mar
          14 11:59:45 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 708CA57042 for <mobile-ip@standards.nortelnetworks.com>; Tue, 14
          Mar 2000 10:59:43 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000314165944.708CA57042@king.research.bell-labs.com>
Date:         Tue, 14 Mar 2000 10:59:44 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      [MOBILE-IP] Mobile IP Session Identifier Extension
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

Kent Leung and I have put together a new internet draft called the
Mobile IP Session Identifier Extension.  You can find a copy at:

http://www.bell-labs.com/~mccap/publications/ids/draft-ietf-mobileip-sessionid-00.txt

I submitted it to the i-d editor on Friday but it may take a while for
it to appear in the ftp directory.  Right now it has the ietf-mobileip
in the name in the hopes of making it a working group item, although
this is not yet official.

This draft describes the Session Identifier which allows a user with
a single NAI to register multiple times on the same HA.  This might
be useful, for instance, if the user has 2 or 3 devices, all of which
need separate IP addresses assigned by the same HA.  The draft also
describes behavior to be followed by the MN and HA when a MN returns
home and wishes to de-register all mobility bindings but wants to
continue using a dynamically assigned address.  This is functionality
that is currently unspecified in the NAI draft.

Comments welcome.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 15 04:03:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10437
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Mar 2000 04:03:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1370260@standards.nortelnetworks.com>; Wed, 15 Mar 2000 3:58:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 88569 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 03:57:01
          -0500
Received: from kaikoura (195.169.92.5) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1F0F6EB0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 3:47:01
          -0500
Received: by kaikoura; id JAA28140; Wed, 15 Mar 2000 09:51:07 +0100 (MET)
Received: from unknown(134.203.8.201) by kaikoura.fel.tno.nl via smap (V5.5) id
          xma027838; Wed, 15 Mar 00 09:50:13 +0100
Received: from fel.tno.nl ([134.203.12.165]) by fs1.fel.tno.nl (Netscape
          Messaging Server 3.6)  with ESMTP id AAA6047; Wed, 15 Mar 2000
          09:50:17 +0100
X-Sender: "NMM van der Vlugt" <nmmv5@fs1.fel.tno.nl>
X-Mailer: Mozilla 4.07 [en]C-TNOTESTFEL  (Win95; I)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38CF4EC9.91D13A83@fel.tno.nl>
Date:         Wed, 15 Mar 2000 09:50:17 +0100
Reply-To: NMM van der Vlugt <vanderVlugt@FEL.TNO.NL>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: NMM van der Vlugt <vanderVlugt@FEL.TNO.NL>
Organization: TNO-FEL
Subject:      [MOBILE-IP] Combination of binding update and home address option
              in mobile
              IPv6
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

The binding update and de home address option are separated in mobile
IPv6. But the handling of a binding update requires a home address
option.
I see some implementation difficulties here. When a node is processing
all options, it has to store the home address and the contents of the
binding update options somewhere. It's not possible to process the
binding update option immediate because its processing depends on the
data in the home address option. There is now also an extra error
situation possibe: packet with a binding update option and no home
address option.

I think that it's more efficient to combine these two options. Or am I
missing something here? It's possible to keep the definition of the home
address option the same. The data that's now in a binding update option
can be defined as a sub option of the home address option. This
sub-option indicates that this is a binding update. This makes the
processing of the "binding update option" more efficient. The binding
cache can be updated immediate when the node processes this option. This
setup also eleminates one possible error situation in the protocol.

Marco


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 15 04:49:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25542
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Mar 2000 04:49:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31B615C0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 4:44:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 88635 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 04:43:43
          -0500
Received: from monza.broadswitch.com (195.178.164.65) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A4B2A5E0@standards.nortelnetworks.com>; Wed, 15 Mar 2000
          4:33:42 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AFA7@monza.broadswitch.com>
Date:         Wed, 15 Mar 2000 10:37:35 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Combination of binding update and home address op
              tion in
              mobile IPv6
X-To:         NMM van der Vlugt <vanderVlugt@FEL.TNO.NL>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: NMM van der Vlugt [mailto:vanderVlugt@FEL.TNO.NL]
> Sent: Wednesday, March 15, 2000 9:50 AM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] Combination of binding update and home address
> option in mobile IPv6
>
>
> Hi all,
>
> The binding update and de home address option are separated in mobile
> IPv6. But the handling of a binding update requires a home address
> option.
Yes and it is required by all IPv6 node to support home address option.
That means that every IPv6 node can at least receive and process the home
address option.
And every node should support binding update processing and return a binding
ack and the should also have a binding cache for all the accepted binding
updates (i.e. route optimazation..)

The above can be seen as what is required by a Correspondent node to support
so this SHOULD be the minimal every IPv6 node support...

> I see some implementation difficulties here.
Why?

> When a node is processing
> all options, it has to store the home address and the contents of the
> binding update options somewhere.
It stores them in its binding cache..

> It's not possible to process the
> binding update option immediate because its processing depends on the
> data in the home address option.
No,
You have to verify possible AH headers in the binding update option, check
the option length and the seq. no after that you proccess the home address
options which is the home address of the mobile node sending the binding
update and there is no sub otions defines today...

This is how it looks in the header because the home addrss option is send in
a destination option header and it is a separate extension header... And how
you process the order of extension header and espescially if you have a AH
included has been clearified in the latest mobile ipv6 draft (mobileipv6
version 10)...

> There is now also an extra error
> situation possibe: packet with a binding update option and no home
> address option.
This is when the binding update is not send from the mobile node, i.e it can
be sent from the correspondent nodes, routers (home agent). For instance it
could be in a reply to a binding update to ack it, or simply a refresh of
the cache...



>
> I think that it's more efficient to combine these two options. Or am I
If you combine them you have to change the router requirements... Which
might not be want you want to do...

> missing something here? It's possible to keep the definition
> of the home
> address option the same. The data that's now in a binding
> update option
> can be defined as a sub option of the home address option. This
> sub-option indicates that this is a binding update. This makes the
> processing of the "binding update option" more efficient. The binding
> cache can be updated immediate when the node processes this
> option. This
> setup also eleminates one possible error situation in the protocol.
>
> Marco
>

Regards
 Thomas Eklund


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 15 06:34:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03293
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Mar 2000 06:34:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3505FF0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 6:29:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 88823 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 06:27:52
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.31752940@standards.nortelnetworks.com>; Wed, 15 Mar 2000 6:17:51
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA28208; Wed, 15 Mar 2000 06:22:01
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003151122.GAA28208@ietf.org>
Date:         Wed, 15 Mar 2000 06:22:01 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-vendor-ext-10.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobile IP Vendor/Organization-Specific Extensions
        Author(s)       : G. Dommety, K. Leung
        Filename        : draft-ietf-mobileip-vendor-ext-10.txt
        Pages           : 4
        Date            : 14-Mar-00

This  document proposes   two   new    extensions   to   Mobile
IP [1]. These extensions will facilitate equipment vendors and
organizations to make specific use  of these extensions as they see
fit for research or deployment purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vendor-ext-10.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-vendor-ext-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-10.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:     <20000314132429.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-10.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-vendor-ext-10.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000314132429.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 15 11:41:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08650
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Mar 2000 11:41:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAB2E550@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:36:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 89522 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 11:34:59
          -0500
Received: from mainframe.dgrc.crc.ca by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.18D564B0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:24:58
          -0500
Received: from crc.ca (curly [142.92.38.251]) by mainframe.dgrc.crc.ca
          (8.9.3/8.9.3) with ESMTP id LAA06793; Wed, 15 Mar 2000 11:22:30 -0500
          (EST)
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <45AFD48D077ED211BB4700A0C9DCE8FD15AFA7@monza.broadswitch.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38CFB9D1.2CF0CA04@crc.ca>
Date:         Wed, 15 Mar 2000 11:26:57 -0500
Reply-To: Guilhem Tardy <Guilhem.Tardy@CRC.CA>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Guilhem Tardy <Guilhem.Tardy@CRC.CA>
Organization: CRC
Subject:      Re: [MOBILE-IP] Combination of binding update and home address
              option
              inmobile IPv6
X-To:         Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
X-cc:         vanderVlugt@FEL.TNO.NL
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Thomas Eklund wrote:

> > It's not possible to process the
> > binding update option immediate because its processing depends on the
> > data in the home address option.
> No,
> You have to verify possible AH headers in the binding update option, check
> the option length and the seq. no after that you proccess the home address
> options which is the home address of the mobile node sending the binding
> update and there is no sub otions defines today...
>
> This is how it looks in the header because the home addrss option is send in
> a destination option header and it is a separate extension header... And how
> you process the order of extension header and espescially if you have a AH
> included has been clearified in the latest mobile ipv6 draft (mobileipv6
> version 10)...
>

Although I agree mostly with your comments, I would like to add that a
correspondent node or Home Agent processing a Binding Update Option
needs to screen the whole Destination Option for a Home Address Option,
which I find ugly.
I didn't see any better explanation for the processing and order of the
options in rev. 10 compared to previous revisions, and I would
appreciate if you commented further. For instance, what if there's
several Home Address Options in the same Destination Option? And is
there any order assumed (e.g. Home Address Options located *before* a
Binding Update Option), or should a correspondent node or Home Agent
handle any of the possible situations (and therefore do the ugly thing)?

These are basic implementation consideration, and as I believe IPv6
requires the extension headers (e.g. Hop-by-Hop, Destination) to be
processed in order, I assume the same requirement applies to the options
within each of those extension headers, which is impossible here.

Best regards,
Guilhem Tardy.

--
                                    phone: (613) 993-8232
Network Systems and Technologies    fax:   (613) 998-9648
Communications Research Center      email: Guilhem.Tardy@crc.ca
3701 Carling Ave. #28/2B            web:   http://www.crc.ca/
Ottawa (Ontario) K2H 8S2


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 15 16:41:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13426
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 15 Mar 2000 16:41:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A7D1CC50@standards.nortelnetworks.com>; Wed, 15 Mar 2000 16:36:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 90002 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 16:35:38
          -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7EAECAD0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 16:35:38
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA17121 for
          <mobile-ip@standards.nortelnetworks.com>; Wed, 15 Mar 2000 23:39:50
          +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          XAA19089 for <mobile-ip@standards.nortelnetworks.com>; Wed, 15 Mar
          2000 23:39:49 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RMJANQM>;
          Wed, 15 Mar 2000 15:38:51 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2BCD4DFD@daeis07nok>
Date:         Wed, 15 Mar 2000 15:38:43 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Basavaraj Patil <Basavaraj.Patil@NOKIA.COM>
Subject:      [MOBILE-IP] Interesting Draft
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,

Scott carson recently submitted a draft that I believe
is of interest to the Mobile IP WG, especially in view
of the recent discussion on enhancing the scope of the
charter to support fast handoffs.

The draft is available in the standard repositories and is
titled : draft-oneill-ema-01.txt (Edge Mobility Architecture).

Since the Mobile IP agenda for Adelaide is already quite
full, we could not add this item to the discussions.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 16 10:15:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10164
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 16 Mar 2000 10:15:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9B06A00@standards.nortelnetworks.com>; Thu, 16 Mar 2000 10:09:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 91390 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 10:08:48
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9EE9F1B0@standards.nortelnetworks.com>; Thu, 16 Mar 2000
          10:08:48 -0500
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se
          [153.88.251.29]) by penguin.wise.edt.ericsson.se
          (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA17859 for
          <MOBILE-IP@standards.nortelnetworks.com>; Thu, 16 Mar 2000 16:13:03
          +0100 (MET)
Received: from SMTP ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with
          Microsoft SMTPSVC(5.0.2172.1); Thu, 16 Mar 2000 16:12:32 +0100
Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.29
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 16 Mar 2000
          15:12:31 0000 (GMT)
Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <G0XJ0GHM>;
          Thu, 16 Mar 2000 16:13:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 16 Mar 2000 15:12:32.0234 (UTC)
                       FILETIME=[0D4864A0:01BF8F5A]
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA7F2C@esealnt190>
Date:         Thu, 16 Mar 2000 16:12:54 +0100
Reply-To: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@ERA.ERICSSON.SE>
Subject:      [MOBILE-IP] New I-D : Hierarchical MIPv4/v6 and Fast Handoffs
X-cc:         "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi

Hesham and I have submitted a new I-D on Hierarchical Mobile IPv4/v6
and Fast Handoffs:
http://www.ietf.org/internet-drafts/draft-elmalki-soliman-hmipv4v6-00.txt

Any comments are much appreciated.

Cheers,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 03:57:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10953
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 03:57:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E02CA40@standards.nortelnetworks.com>; Fri, 17 Mar 2000 3:52:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92172 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 03:51:05
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.050F8B50@standards.nortelnetworks.com>; Fri, 17 Mar 2000 3:51:05
          -0500
Received: from gdommety-pc2 (gdommety-dsl4.cisco.com [10.19.17.141]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          AAA15902; Fri, 17 Mar 2000 00:53:37 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003170853.AAA15902@omega.cisco.com>
Date:         Fri, 17 Mar 2000 01:06:27 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      [MOBILE-IP] GRE Extensions (Modified)
X-To:         gre@ops.ietf.org
X-cc:         udlr@sophia.inria.fr, msdp@antc.uoregon.edu,
              ipsec@lists.tislabs.com, l2tp@ipsec.org, tsgp@3gpp2.org,
              tsga@3gpp2.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello:

I have changed the sequence no  to be 4 bytes.  The changes request by
most have been made.

A remining issue is regarding  the behaviour when both sequence no and
the Key are present. There are two options:

1. Have sequence no  per Key.  This will give  better granularity with
   added complexity of implementation.

2. Sequence no for the tunnel irrespective of the Key.

Let me know your opinion.

Thanks
Gopal


Network Working Group                                 Gopal Dommety
INTERNET DRAFT                                        cisco Systems
Category: Standards Track                             March 2000
Title:  draft-dommety-gre-ext-01.txt

Expires October 2000

                Key and Sequence Number Extensions to GRE
                    draft-dommety-gre-ext-01.txt

Status of this Memo

   This document is a submission by the Network Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the gre@ops.ietf.org mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol.

Dommety                                                           [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the
   requirements of the specification.

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    The proposed GRE header will have the following format:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Sequence Number (Optional)                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible
      with RFC 1701 [2].

2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel.

2.2. Sequence Number (4 octets)

    The Sequence Number field is a  four byte feild and is inserted by
    the  encapsulator when  Sequence Number  Present Bit  is set. The
    Sequence  Number MUST  be used  by the  receiver to  establish the
    order in which packets have been transmitted from the encapsulator
    to the receiver.  The intended use  of the Sequence Field is to
    provide unreliable and in-order  delivery.  If the Key present bit
    (bit 2) is set, the  sequence number is specific to the sub-tunnel
    identified by the Key field. Note that packets without the sequence
     bit set can be sent in between packets with the sequence bit set.

    The  sequence number  value ranges from 1 to  2**32-1. The first
    datagram is sent with a sequence number of 1. The  sequence
    number is thus a free running counter represented modulo 2**32,
    with the exception that 1 is used when modulo 2**32 results in 0
    (i.e., rollover to 1 instead of 0).

    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering
    schemes are outside the scope of  this  document. Note that the
    sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the  sequence
   number  of  the  received packet  is  lesser than or equal to  the
   sequence  number   of last  successfully  decapsulated
   packet. The  sequence number  of a received message is considered
   less than or equal to the last successfully received  sequence number
   if its value lies in the range of the last received  sequence number
   and the preceding 65534 values, inclusive.


    If  the   received  packet  is   an  in-sequence  packet,   it  is
    successfully decapsulated.  Note that  the sequence number is used
    to  detect lost packets  and/or restore  the original  sequence of
    packets  (with  buffering) that  may  have  been reordered  during
    transport.   Use of  the  sequence number  option  should be  used
    appropriately; in particular, it is a good idea a avoid using when
    tunneling  protocols  that  have  higher layer  in-order  delivery
    mechanisms or are tolerant to out-of-order delivery. If only at certain
    instances the protocol being carried in the GRE tunnel requires
    in-sequence delivery, only the corresponding packets encapsulated
    in a GRE header can be sent with the sequence bit set. Mechanisims
    to determine which packets need to be sent in-sequence and the
    signaling mechanisims are outside the scope of this document.




3. IANA Considerations

4. Acknowledgments


5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
   October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.


Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: gdommety@cisco.com

Dommety





Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 08:33:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26890
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 08:33:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEA06650@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:27:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92492 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 08:26:30
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.19045710@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:16:29
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id IAA21212; Fri, 17 Mar 2000 08:20:47
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003171320.IAA21212@ietf.org>
Date:         Fri, 17 Mar 2000 08:20:47 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-aaa-reqs-03.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobile IP Authentication, Authorization, and
                          Accounting Requirements
        Author(s)       : S. Glass, C. Perkins, T. Hiller, S. Jacobs
        Filename        : draft-ietf-mobileip-aaa-reqs-03.txt
        Pages           : 25
        Date            : 16-Mar-00

The Mobile IP and AAA working groups are currently looking at
defining the requirements for Authentication, Authorization, and
Accounting.  This document contains the requirements which would
have to be supported by a AAA service to aid in providing Mobile IP
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-reqs-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-aaa-reqs-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-aaa-reqs-03.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000316144122.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-aaa-reqs-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-aaa-reqs-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000316144122.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 08:33:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26895
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 08:33:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AECDB7E0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:27:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92493 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 08:26:35
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1C208B30@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:16:35
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id IAA21252; Fri, 17 Mar 2000 08:20:52
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003171320.IAA21252@ietf.org>
Date:         Fri, 17 Mar 2000 08:20:52 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-3gwireless-ext-03.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobile IP Based  Micro Mobility Management Protocol in
                          The Third Generation Wireless Network
        Author(s)       : Y. Xu et al.
        Filename        : draft-ietf-mobileip-3gwireless-ext-03.txt
        Pages           : 16
        Date            : 16-Mar-00

This document defines extensions to the Mobile IP protocol [1] to
allow mobility management for the interface between a radio network
and a packet data network in the third generation cdma2000 network.
Mobile IP requires link layer connectivity between the Mobile Node
and the Foreign Agent. This draft proposes a protocol for achieving
this when the physical layer terminating at a point distant from the
FA. In particular, this protocol applies to cdma2000 networks where
the physical layer terminates at a Radio Network Node (RNN) and the
FA resides inside a separate Packet Data Serving Node (PDSN). The
PDSN is responsible for establishing, maintaining, and terminating
the link layer to the Mobile Node. A RNN is responsible for relaying
the link layer protocol between a Mobile Node and its corresponding
PDSN.
The interface between the RNN and the PDSN is called the RP
interface. This interface requires mobility management for handling
handoff from one RNN to another without interrupting end to end
communication. It also requires the support of the link layer
protocol encapsulation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-3gwireless-ext-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-03.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000316144136.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-3gwireless-ext-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000316144136.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 08:58:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26906
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 08:33:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEEEFB80@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:27:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92494 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 08:26:40
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1EF55610@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:16:39
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id IAA21288; Fri, 17 Mar 2000 08:20:57
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003171320.IAA21288@ietf.org>
Date:         Fri, 17 Mar 2000 08:20:56 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-ipv6-11.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobility Support in IPv6
        Author(s)       : D. Johnson, C. Perkins
        Filename        : draft-ietf-mobileip-ipv6-11.txt
        Pages           : 104
        Date            : 16-Mar-00

This document specifies the operation of mobile computers using IPv6.
Each mobile node is always identified by its home address, regardless
of its current point of attachment to the Internet.  While situated
away from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current
location.  IPv6 packets addressed to a mobile node's home address are
transparently routed to its care-of address.  The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address, and to then send any packets destined for the
mobile node directly to it at this care-of address.  To support this
operation, Mobile IPv6 defines four new IPv6 destination options,
including one that MUST be supported in packets received by any node,
whether mobile or stationary.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-11.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-ipv6-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-ipv6-11.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:     <20000316144147.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-ipv6-11.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-ipv6-11.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000316144147.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 09:53:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26861
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 09:53:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E34BAC10@standards.nortelnetworks.com>; Fri, 17 Mar 2000 9:48:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92671 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 09:46:43
          -0500
Received: from melanieb.vtt.fi by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4DC4F990@standards.nortelnetworks.com>; Fri, 17 Mar 2000 9:36:42
          -0500
Received: from mailgw.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi
          (8.9.3/8.9.3) with ESMTP id QAA06607 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 17 Mar 2000 16:41:00
          +0200 (EET)
Received: from hemuli.tte.vtt.fi (hemuli.tte.vtt.fi [130.188.52.1]) by
          mailgw.vtt.fi (8.9.3/8.9.3) with ESMTP id QAA09627 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 17 Mar 2000 16:40:59
          +0200 (EET)
Received: (from tjs@localhost) by hemuli.tte.vtt.fi (8.8.8/8.8.8) id QAA12813;
          Fri, 17 Mar 2000 16:40:59 +0200 (EET)
Message-ID:  <200003171440.QAA12813@hemuli.tte.vtt.fi>
Date:         Fri, 17 Mar 2000 16:40:59 +0200
Reply-To: Tapio Suihko <Tapio.Suihko@VTT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Tapio Suihko <Tapio.Suihko@VTT.FI>
Subject:      [MOBILE-IP] A comment on Minimal Latency Secure Hand-off
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi All,

The "Minimal Latency Secure Hand-off" draft specifies a mechanism for
letting an MN convey keying information between FAs. This information
is embedded in an MN-Key-Token Extension, which is a subtype of
Generalized MN-FA Key Reply Extension.

There might be situations, where the MN could communicate to an FA, in
addition to registration keys, other state information from a previous
FA (related to QoS, authorization, or path setup, for
example). Therefore, I think that defining a Generalized Opaque
extension might be useful. The semantics would be trivial: the MN
should just pass any blobs to an FA if the advertised FA-NAI implies
that the MN is migrating within the same administrative domain, or
optionally a lifetime could be attached to the blob, so that the MN
can discard it when the lifetime expires.

Such generic blobs with simple semantics might facilitate developing
intra-domain protocols and policies which, however, could be
transparent to MNs and would allow interoperability with any MN.

Anyway, according to the "Minimal Latency Secure Hand-off" draft, the
Key Reply extensions may be passed to the MN without the MN having
requested this data and, on the other hand, it may sound slightly
awkward that an MN should send a Key Reply extension to an FA (and
only do this depending on the specific subtype of the
extension). Therefore, one might wonder whether Key Reply really is
the most appropriate extension to apply in this case.

Regards,
Tapio

--
Tapio Suihko            Technical Research Centre of Finland (VTT/IT)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 10:20:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07876
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 10:20:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF407910@standards.nortelnetworks.com>; Fri, 17 Mar 2000 10:15:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92799 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 10:13:47
          -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.7B81DC40@standards.nortelnetworks.com>; Fri, 17 Mar 2000 10:13:47
          -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Mar
          17 10:16:39 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Fri Mar
          17 10:16:37 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 74DB757042; Fri, 17 Mar 2000 09:16:36 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200003170853.AAA15902@omega.cisco.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000317151636.74DB757042@king.research.bell-labs.com>
Date:         Fri, 17 Mar 2000 09:16:36 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      [MOBILE-IP] GRE Extensions (Modified)
X-To:         Gopal Dommety <gdommety@cisco.com>
X-cc:         gre@ops.ietf.org, udlr@sophia.inria.fr, msdp@antc.uoregon.edu,
              ipsec@lists.tislabs.com, l2tp@ipsec.org, tsgp@3gpp2.org,
              tsga@3gpp2.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003170853.AAA15902@omega.cisco.com>
Content-Transfer-Encoding: 7bit

The sequence number should definitely be per key!  That way we can
tunnel multiple streams, one per key.  Each needs its own sequencing.

-Pete

Gopal Dommety <gdommety@cisco.com> (GD) writes:

GD> Hello:
GD> I have changed the sequence no  to be 4 bytes.  The changes request by
GD> most have been made.

GD> A remining issue is regarding  the behaviour when both sequence no and
GD> the Key are present. There are two options:

GD> 1. Have sequence no  per Key.  This will give  better granularity with
GD>    added complexity of implementation.

GD> 2. Sequence no for the tunnel irrespective of the Key.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 11:14:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00678
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 11:14:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E9AE990@standards.nortelnetworks.com>; Fri, 17 Mar 2000 11:09:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 92886 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 11:07:58
          -0500
Received: from jittlov.qualcomm.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0D8FD400@standards.nortelnetworks.com>; Fri, 17 Mar 2000 11:07:58
          -0500
Received: from rhsu4.qualcomm.com (annex2-p23.qualcomm.com [129.46.85.113]) by
          jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with SMTP id IAA17317; Fri, 17
          Mar 2000 08:11:47 -0800 (PST)
X-Sender: rhsu@fezik.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003171611.IAA17317@jittlov.qualcomm.com>
Date:         Fri, 17 Mar 2000 08:12:08 -0800
Reply-To: Raymond Hsu <rhsu@QUALCOMM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Raymond Hsu <rhsu@QUALCOMM.COM>
Subject:      Re: [MOBILE-IP] GRE Extensions (Modified)
X-To:         Gopal Dommety <gdommety@cisco.com>, tsgp@3gpp2.org
X-cc:         udlr@sophia.inria.fr, msdp@antc.uoregon.edu,
              ipsec@lists.tislabs.com, l2tp@ipsec.org, tsgp@3gpp2.org,
              tsga@3gpp2.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <LYR1158584-196913-2000.03.17-00.58.48--rhsu#qualcomm.com@3
              gpp2.org>

Hi Gopal:

In TR-45.6's R-P interface (aka A10 interface), we may use the first option
in the direction
from the PDSN to the PCF.  In this direction, we've identified scenarios
where some mobiles
require in-sequence delivery and some don't.  Since each mobile is
identified by the Key field
over the R-P interface, we need option 1.  However, in the direction from
the PCF to the PDSN,
we don't have a strong requirement per mobile basis; thus, option 2 is
adequate.  Therefore,
my recommendation is that both options should be allowed in the GRE draft.

Regards,

Raymond Hsu

At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote:
>Hello:
>
>I have changed the sequence no  to be 4 bytes.  The changes request by
>most have been made.
>
>A remining issue is regarding  the behaviour when both sequence no and
>the Key are present. There are two options:
>
>1. Have sequence no  per Key.  This will give  better granularity with
>   added complexity of implementation.
>
>2. Sequence no for the tunnel irrespective of the Key.
>
>Let me know your opinion.
>
>Thanks
>Gopal
>
>
>Network Working Group                                Gopal Dommety
>INTERNET DRAFT                                        cisco Systems
>Category: Standards Track                             March 2000
>Title:  draft-dommety-gre-ext-01.txt
>
>Expires October 2000
>
>               Key and Sequence Number Extensions to GRE
>                   draft-dommety-gre-ext-01.txt
>
>Status of this Memo
>
>   This document is a submission by the Network Working Group of the
>   Internet Engineering Task Force (IETF).  Comments should be submitted
>   to the gre@ops.ietf.org mailing list.
>
>   Distribution of this memo is unlimited.
>
>   This document is an Internet Draft and is in full conformance with
>   all provisions of Section 10 of RFC2026. Internet Drafts are working
>   documents of the Internet Engineering Task Force (IETF), its areas,
>   and working groups. Note that other groups may also distribute
>   working documents as Internet Drafts.
>
>   Internet Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time. It is inappropriate to use Internet Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/ietf/1id-abstracts.txt.
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html.
>
>Abstract
>
>   This  document describes extensions  by which  two fields,  Key and
>Sequence Number, can be optionally carried in the GRE (Generic Routing
>Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
>of an arbitrary network  layer protocol over another arbitrary network
>layer  protocol.
>
>Dommety                                                                  [Page 1]
>
>Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>
>1. Introduction
>
>   Current specification of Generic Routing Encapsulation [1] specifies
>a protocol  for encapsulation of  an arbitrary network  layer protocol
>over another arbitrary network layer protocol. This document describes
>enhancements  by which  two fields,  Key and  Sequence Number,  can be
>optionally carried  in the GRE  Header [1]. The  Key field is  used to
>create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
>is used to maintain sequence of packets within a GRE Tunnel.
>
>1.1. Specification Language
>
>   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>   this document are to be interpreted as described in RFC 2119 [3].
>
>   In addition, the following words are used to signify the
>   requirements of the specification.
>
>   Silently discard
>              The implementation discards the datagram without
>              further processing, and without indicating an error
>              to the sender.  The implementation SHOULD provide the
>              capability of logging the error, including the contents
>              of the discarded datagram, and SHOULD record the event
>              in a statistics counter.
>
>2. Extensions to GRE Header
>
>   The GRE packet header[1] has the following format:
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C|       Reserved0       | Ver |         Protocol Type         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    The proposed GRE header will have the following format:
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Key (optional)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                 Sequence Number (Optional)                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>      Key Present (bit 2)
>
>      If the Key Present bit is set to 1, then it indicates that the Key
>      field is present in the GRE header.  Otherwise, the Key field is
>      not present in the GRE header.
>
>      Sequence Number Present (bit 3)
>
>      If the Sequence Number Present bit is set to 1, then it indicates
>      that the Sequence Number field is present.  Otherwise, the
>      Sequence Number field is not present in the GRE header.
>
>      The  Key and Sequence Present bits are chosen to be  compatible
>      with RFC 1701 [2].
>
>2.1. Key Field (4 octets)
>
>     The Key field contains a  four octet number which was inserted by
>     the encapsulator. The actual method by which this Key is obtained
>     is beyond the scope of this document.  Key field is intended to be
>     used for  creating separate sub-tunnels within a  GRE Tunnel and the
>     Key field identifies the sub-tunnel.
>
>2.2. Sequence Number (4 octets)
>
>    The Sequence Number field is a  four byte feild and is inserted by
>    the  encapsulator when  Sequence Number  Present Bit  is set. The
>    Sequence  Number MUST  be used  by the  receiver to  establish the
>    order in which packets have been transmitted from the encapsulator
>    to the receiver.  The intended use  of the Sequence Field is to
>    provide unreliable and in-order  delivery.  If the Key present bit
>    (bit 2) is set, the  sequence number is specific to the sub-tunnel
>    identified by the Key field. Note that packets without the sequence
>     bit set can be sent in between packets with the sequence bit set.
>
>    The  sequence number  value ranges from 1 to  2**32-1. The first
>    datagram is sent with a sequence number of 1. The  sequence
>    number is thus a free running counter represented modulo 2**32,
>    with the exception that 1 is used when modulo 2**32 results in 0
>    (i.e., rollover to 1 instead of 0).
>
>    When the decapsulator receives an out-of sequence packet it SHOULD
>    be silently discarded. Additionally, reordering of out-of sequence
>    packets  MAY  be  performed   by  the  decapsulator  for  improved
>    performance and  tolerance to reordering in the  network (since the
>    state of the stateful compression or encryption is reset by packet
>    loss, it  might help the  performance to tolerate some  amount of
>    packet reordering in the network by buffering). Exact buffering
>    schemes are outside the scope of  this  document. Note that the
>    sequence number is used to detect
>    lost packets and/or restore  the original sequence of packets that
>    may have been reordered during transport.
>
>   A packet  is considered an out-of-sequence packet  if the  sequence
>   number  of  the  received packet  is  lesser than or equal to  the
>   sequence  number   of last  successfully  decapsulated
>   packet. The  sequence number  of a received message is considered
>   less than or equal to the last successfully received  sequence number
>   if its value lies in the range of the last received  sequence number
>   and the preceding 65534 values, inclusive.
>
>
>    If  the   received  packet  is   an  in-sequence  packet,   it  is
>    successfully decapsulated.  Note that  the sequence number is used
>    to  detect lost packets  and/or restore  the original  sequence of
>    packets  (with  buffering) that  may  have  been reordered  during
>    transport.   Use of  the  sequence number  option  should be  used
>    appropriately; in particular, it is a good idea a avoid using when
>    tunneling  protocols  that  have  higher layer  in-order  delivery
>    mechanisms or are tolerant to out-of-order delivery. If only at certain
>    instances the protocol being carried in the GRE tunnel requires
>    in-sequence delivery, only the corresponding packets encapsulated
>    in a GRE header can be sent with the sequence bit set. Mechanisims
>    to determine which packets need to be sent in-sequence and the
>    signaling mechanisims are outside the scope of this document.
>
>
>
>
>3. IANA Considerations
>
>4. Acknowledgments
>
>
>5. References
>
>   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>   "Generic           Routing           Encapsulation          (GRE),"
>   draft-meyer-gre-update-03.txt, January 2000.
>
>   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>   October 1994.
>
>   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>       Levels", RFC 2119, March 1997.
>
>
>Dommety                                                 [Page 4]
>
>Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>
>Author Information
>
>   Gopal Dommety
>   Cisco Systems, Inc.
>   170 West Tasman Drive
>   San Jose, CA 95134
>   e-mail: gdommety@cisco.com
>
>Dommety
>
>
>
>
>
>Thank You.
>Regards,
>Gopal
>---------------------------------------------------------------------------
----------------------------------
>
>Gopal Dommety
>408 525 1404
>gdommety@cisco.com
>Cisco Systems, San Jose, CA, 95051
>
>---
>You are currently subscribed to tsgp as: rhsu@qualcomm.com
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 14:23:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19409
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 14:23:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4D99BA0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 14:18:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93203 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 14:17:06
          -0500
Received: from wacko.redbacknetworks.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.13D4DD10@standards.nortelnetworks.com>; Fri, 17 Mar 2000 14:07:06
          -0500
Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com
          [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with
          ESMTP id LAA07185; Fri, 17 Mar 2000 11:10:51 -0800 (PST)
Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id
          LAA01237; Fri, 17 Mar 2000 11:10:50 -0800 (PST)
References: <LYR1158584-196913-2000.03.17-00.58.48--rhsu#qualcomm.com@3
            <200003171611.IAA17317@jittlov.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Message-ID:  <20000317111050.B1078@redback.com>
Date:         Fri, 17 Mar 2000 11:10:50 -0800
Reply-To: Rene Tio <tor@REDBACK.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rene Tio <tor@REDBACK.COM>
Subject:      Re: [MOBILE-IP] GRE Extensions (Modified)
X-To:         Raymond Hsu <rhsu@qualcomm.com>
X-cc:         Gopal Dommety <gdommety@cisco.com>,
              tsgp@3gpp2.org, udlr@sophia.inria.fr, msdp@antc.uoregon.edu,
              ipsec@lists.tislabs.com, l2tp@ipsec.org, tsga@3gpp2.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003171611.IAA17317@jittlov.qualcomm.com>; from
              rhsu@qualcomm.com on Fri, Mar 17, 2000 at 08:12:08AM -0800

On Fri, Mar 17, 2000 at 08:12:08AM -0800, Raymond Hsu wrote:
> Hi Gopal:
>
> In TR-45.6's R-P interface (aka A10 interface), we may use the first option
> in the direction
> from the PDSN to the PCF.  In this direction, we've identified scenarios
> where some mobiles
> require in-sequence delivery and some don't.  Since each mobile is
> identified by the Key field
> over the R-P interface, we need option 1.  However, in the direction from
> the PCF to the PDSN,
> we don't have a strong requirement per mobile basis; thus, option 2 is
> adequate.  Therefore,
> my recommendation is that both options should be allowed in the GRE draft.


I think if we plan the most limiting case (option 1, which we have at
least a few opinions is necessary) and allow for the not-so-limiting, both
cases will be covered.

IMHO the C, K, and S fields are a request for the other end to check, not a
requirement that the other end should send, i.e., if you configure a tunnel
to have checksums, you send checksums but don't require the other end to
send checksums (it's part of the "be liberal in what you receive" paradigm).
Thus in the PCF to PDSN direction you just don't configure sequence numbers
and everything Should Just Work.

Cheers,
Rene

ps/ Funny how the PPTP draft is vague on this as well, or at least my quick
    glance did not find any statement on this matter.  I don't think it
    would work if you didn't have a sequence number per key though, as one
    missed packet may cause you to turf packets across many PPP sessions.


> Regards,
>
> Raymond Hsu
>
> At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote:
> >Hello:
> >
> >I have changed the sequence no  to be 4 bytes.  The changes request by
> >most have been made.
> >
> >A remining issue is regarding  the behaviour when both sequence no and
> >the Key are present. There are two options:
> >
> >1. Have sequence no  per Key.  This will give  better granularity with
> >   added complexity of implementation.
> >
> >2. Sequence no for the tunnel irrespective of the Key.
> >
> >Let me know your opinion.
> >
> >Thanks
> >Gopal
> >
> >
> >Network Working Group                                      Gopal Dommety
> >INTERNET DRAFT                                        cisco Systems
> >Category: Standards Track                             March 2000
> >Title:  draft-dommety-gre-ext-01.txt
> >
> >Expires October 2000
> >
> >             Key and Sequence Number Extensions to GRE
> >                 draft-dommety-gre-ext-01.txt
> >
> >Status of this Memo
> >
> >   This document is a submission by the Network Working Group of the
> >   Internet Engineering Task Force (IETF).  Comments should be submitted
> >   to the gre@ops.ietf.org mailing list.
> >
> >   Distribution of this memo is unlimited.
> >
> >   This document is an Internet Draft and is in full conformance with
> >   all provisions of Section 10 of RFC2026. Internet Drafts are working
> >   documents of the Internet Engineering Task Force (IETF), its areas,
> >   and working groups. Note that other groups may also distribute
> >   working documents as Internet Drafts.
> >
> >   Internet Drafts are draft documents valid for a maximum of six months
> >   and may be updated, replaced, or obsoleted by other documents at any
> >   time. It is inappropriate to use Internet Drafts as reference
> >   material or to cite them other than as "work in progress."
> >
> >   The list of current Internet-Drafts can be accessed at
> >   http://www.ietf.org/ietf/1id-abstracts.txt.
> >
> >   The list of Internet-Draft Shadow Directories can be accessed at
> >   http://www.ietf.org/shadow.html.
> >
> >Abstract
> >
> >   This  document describes extensions  by which  two fields,  Key and
> >Sequence Number, can be optionally carried in the GRE (Generic Routing
> >Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
> >of an arbitrary network  layer protocol over another arbitrary network
> >layer  protocol.
> >
> >Dommety                                                                [Page 1]
> >
> >Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
> >
> >1. Introduction
> >
> >   Current specification of Generic Routing Encapsulation [1] specifies
> >a protocol  for encapsulation of  an arbitrary network  layer protocol
> >over another arbitrary network layer protocol. This document describes
> >enhancements  by which  two fields,  Key and  Sequence Number,  can be
> >optionally carried  in the GRE  Header [1]. The  Key field is  used to
> >create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
> >is used to maintain sequence of packets within a GRE Tunnel.
> >
> >1.1. Specification Language
> >
> >   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> >   this document are to be interpreted as described in RFC 2119 [3].
> >
> >   In addition, the following words are used to signify the
> >   requirements of the specification.
> >
> >   Silently discard
> >              The implementation discards the datagram without
> >              further processing, and without indicating an error
> >              to the sender.  The implementation SHOULD provide the
> >              capability of logging the error, including the contents
> >              of the discarded datagram, and SHOULD record the event
> >              in a statistics counter.
> >
> >2. Extensions to GRE Header
> >
> >   The GRE packet header[1] has the following format:
> >
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |C|       Reserved0       | Ver |         Protocol Type         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      Checksum (optional)      |       Reserved1 (Optional)    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >    The proposed GRE header will have the following format:
> >
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |      Checksum (optional)      |       Reserved1 (Optional)    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                         Key (optional)                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                 Sequence Number (Optional)                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >      Key Present (bit 2)
> >
> >      If the Key Present bit is set to 1, then it indicates that the Key
> >      field is present in the GRE header.  Otherwise, the Key field is
> >      not present in the GRE header.
> >
> >      Sequence Number Present (bit 3)
> >
> >      If the Sequence Number Present bit is set to 1, then it indicates
> >      that the Sequence Number field is present.  Otherwise, the
> >      Sequence Number field is not present in the GRE header.
> >
> >      The  Key and Sequence Present bits are chosen to be  compatible
> >      with RFC 1701 [2].
> >
> >2.1. Key Field (4 octets)
> >
> >     The Key field contains a  four octet number which was inserted by
> >     the encapsulator. The actual method by which this Key is obtained
> >     is beyond the scope of this document.  Key field is intended to be
> >     used for  creating separate sub-tunnels within a  GRE Tunnel and the
> >     Key field identifies the sub-tunnel.
> >
> >2.2. Sequence Number (4 octets)
> >
> >    The Sequence Number field is a  four byte feild and is inserted by
> >    the  encapsulator when  Sequence Number  Present Bit  is set. The
> >    Sequence  Number MUST  be used  by the  receiver to  establish the
> >    order in which packets have been transmitted from the encapsulator
> >    to the receiver.  The intended use  of the Sequence Field is to
> >    provide unreliable and in-order  delivery.  If the Key present bit
> >    (bit 2) is set, the  sequence number is specific to the sub-tunnel
> >    identified by the Key field. Note that packets without the sequence
> >     bit set can be sent in between packets with the sequence bit set.
> >
> >    The  sequence number  value ranges from 1 to  2**32-1. The first
> >    datagram is sent with a sequence number of 1. The  sequence
> >    number is thus a free running counter represented modulo 2**32,
> >    with the exception that 1 is used when modulo 2**32 results in 0
> >    (i.e., rollover to 1 instead of 0).
> >
> >    When the decapsulator receives an out-of sequence packet it SHOULD
> >    be silently discarded. Additionally, reordering of out-of sequence
> >    packets  MAY  be  performed   by  the  decapsulator  for  improved
> >    performance and  tolerance to reordering in the  network (since the
> >    state of the stateful compression or encryption is reset by packet
> >    loss, it  might help the  performance to tolerate some  amount of
> >    packet reordering in the network by buffering). Exact buffering
> >    schemes are outside the scope of  this  document. Note that the
> >    sequence number is used to detect
> >    lost packets and/or restore  the original sequence of packets that
> >    may have been reordered during transport.
> >
> >   A packet  is considered an out-of-sequence packet  if the  sequence
> >   number  of  the  received packet  is  lesser than or equal to  the
> >   sequence  number   of last  successfully  decapsulated
> >   packet. The  sequence number  of a received message is considered
> >   less than or equal to the last successfully received  sequence number
> >   if its value lies in the range of the last received  sequence number
> >   and the preceding 65534 values, inclusive.
> >
> >
> >    If  the   received  packet  is   an  in-sequence  packet,   it  is
> >    successfully decapsulated.  Note that  the sequence number is used
> >    to  detect lost packets  and/or restore  the original  sequence of
> >    packets  (with  buffering) that  may  have  been reordered  during
> >    transport.   Use of  the  sequence number  option  should be  used
> >    appropriately; in particular, it is a good idea a avoid using when
> >    tunneling  protocols  that  have  higher layer  in-order  delivery
> >    mechanisms or are tolerant to out-of-order delivery. If only at certain
> >    instances the protocol being carried in the GRE tunnel requires
> >    in-sequence delivery, only the corresponding packets encapsulated
> >    in a GRE header can be sent with the sequence bit set. Mechanisims
> >    to determine which packets need to be sent in-sequence and the
> >    signaling mechanisims are outside the scope of this document.
> >
> >
> >
> >
> >3. IANA Considerations
> >
> >4. Acknowledgments
> >
> >
> >5. References
> >
> >   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
> >   "Generic           Routing           Encapsulation          (GRE),"
> >   draft-meyer-gre-update-03.txt, January 2000.
> >
> >   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
> >   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
> >   October 1994.
> >
> >   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
> >       Levels", RFC 2119, March 1997.
> >
> >
> >Dommety                                                 [Page 4]
> >
> >Internet Draft   Key and Sequence Number extensions to GRE   February 2000
> >
> >Author Information
> >
> >   Gopal Dommety
> >   Cisco Systems, Inc.
> >   170 West Tasman Drive
> >   San Jose, CA 95134
> >   e-mail: gdommety@cisco.com
> >
> >Dommety
> >
> >
> >
> >
> >
> >Thank You.
> >Regards,
> >Gopal
> >---------------------------------------------------------------------------
> ----------------------------------
> >
> >Gopal Dommety
> >408 525 1404
> >gdommety@cisco.com
> >Cisco Systems, San Jose, CA, 95051
> >
> >---
> >You are currently subscribed to tsgp as: rhsu@qualcomm.com
> >
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 17 15:40:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20727
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 17 Mar 2000 15:40:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.589D6410@standards.nortelnetworks.com>; Fri, 17 Mar 2000 15:34:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 93327 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 15:33:22
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.20ADEED0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 15:33:22
          -0500
Received: from gdommety-pc2 (dhcp-sjc9-233-199.cisco.com [171.71.233.199]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          MAA03129; Fri, 17 Mar 2000 12:36:05 -0800 (PST)
X-Sender: gdommety@omega.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
References: <LYR1158584-196913-2000.03.17-00.58.48--rhsu#qualcomm.com@3
            gpp2.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003172036.MAA03129@omega.cisco.com>
Date:         Fri, 17 Mar 2000 12:49:00 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] GRE Extensions (Modified)
X-To:         Raymond Hsu <rhsu@qualcomm.com>, tsgp@3gpp2.org
X-cc:         udlr@sophia.inria.fr, msdp@antc.uoregon.edu,
              ipsec@lists.tislabs.com, l2tp@ipsec.org, tsgp@3gpp2.org,
              tsga@3gpp2.org
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003171611.IAA17317@jittlov.qualcomm.com>

Ray and Pete:

Thanks. I agree with both of you. That is why the current version has this description.
There was comment on the performance and that it might not be good to couple Key and sequence.
 So, I wanted to get opinion.

Ray, even in the PCF to PDSN direction, we don't absolutely need it. We can do with option 2, but the
performance may effected.  If you want to do some sort of buffering and reodering, not having a sequence no
will hurt performance (basically the sequence no will not have per session significance).

In the draft, we have option 1 as of now. Unless there is a major objections let us leave it as it is.

thanks
Gopal


At 08:12 AM 17/03/00 -0800, Raymond Hsu wrote:
>Hi Gopal:
>
>In TR-45.6's R-P interface (aka A10 interface), we may use the first option
>in the direction
>from the PDSN to the PCF.  In this direction, we've identified scenarios
>where some mobiles
>require in-sequence delivery and some don't.  Since each mobile is
>identified by the Key field
>over the R-P interface, we need option 1.  However, in the direction from
>the PCF to the PDSN,
>we don't have a strong requirement per mobile basis; thus, option 2 is
>adequate.  Therefore,
>my recommendation is that both options should be allowed in the GRE draft.
>
>Regards,
>
>Raymond Hsu
>
>At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote:
>>Hello:
>>
>>I have changed the sequence no  to be 4 bytes.  The changes request by
>>most have been made.
>>
>>A remining issue is regarding  the behaviour when both sequence no and
>>the Key are present. There are two options:
>>
>>1. Have sequence no  per Key.  This will give  better granularity with
>>   added complexity of implementation.
>>
>>2. Sequence no for the tunnel irrespective of the Key.
>>
>>Let me know your opinion.
>>
>>Thanks
>>Gopal
>>
>>
>>Network Working Group                               Gopal Dommety
>>INTERNET DRAFT                                        cisco Systems
>>Category: Standards Track                             March 2000
>>Title:  draft-dommety-gre-ext-01.txt
>>
>>Expires October 2000
>>
>>              Key and Sequence Number Extensions to GRE
>>                  draft-dommety-gre-ext-01.txt
>>
>>Status of this Memo
>>
>>   This document is a submission by the Network Working Group of the
>>   Internet Engineering Task Force (IETF).  Comments should be submitted
>>   to the gre@ops.ietf.org mailing list.
>>
>>   Distribution of this memo is unlimited.
>>
>>   This document is an Internet Draft and is in full conformance with
>>   all provisions of Section 10 of RFC2026. Internet Drafts are working
>>   documents of the Internet Engineering Task Force (IETF), its areas,
>>   and working groups. Note that other groups may also distribute
>>   working documents as Internet Drafts.
>>
>>   Internet Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time. It is inappropriate to use Internet Drafts as reference
>>   material or to cite them other than as "work in progress."
>>
>>   The list of current Internet-Drafts can be accessed at
>>   http://www.ietf.org/ietf/1id-abstracts.txt.
>>
>>   The list of Internet-Draft Shadow Directories can be accessed at
>>   http://www.ietf.org/shadow.html.
>>
>>Abstract
>>
>>   This  document describes extensions  by which  two fields,  Key and
>>Sequence Number, can be optionally carried in the GRE (Generic Routing
>>Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
>>of an arbitrary network  layer protocol over another arbitrary network
>>layer  protocol.
>>
>>Dommety                                                                 [Page 1]
>>
>>Internet Draft  Key and Sequence Number Extensions to GRE  February 2000
>>
>>1. Introduction
>>
>>   Current specification of Generic Routing Encapsulation [1] specifies
>>a protocol  for encapsulation of  an arbitrary network  layer protocol
>>over another arbitrary network layer protocol. This document describes
>>enhancements  by which  two fields,  Key and  Sequence Number,  can be
>>optionally carried  in the GRE  Header [1]. The  Key field is  used to
>>create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
>>is used to maintain sequence of packets within a GRE Tunnel.
>>
>>1.1. Specification Language
>>
>>   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>   this document are to be interpreted as described in RFC 2119 [3].
>>
>>   In addition, the following words are used to signify the
>>   requirements of the specification.
>>
>>   Silently discard
>>              The implementation discards the datagram without
>>              further processing, and without indicating an error
>>              to the sender.  The implementation SHOULD provide the
>>              capability of logging the error, including the contents
>>              of the discarded datagram, and SHOULD record the event
>>              in a statistics counter.
>>
>>2. Extensions to GRE Header
>>
>>   The GRE packet header[1] has the following format:
>>
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |C|       Reserved0       | Ver |         Protocol Type         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>    The proposed GRE header will have the following format:
>>
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |      Checksum (optional)      |       Reserved1 (Optional)    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                         Key (optional)                        |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                 Sequence Number (Optional)                    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>      Key Present (bit 2)
>>
>>      If the Key Present bit is set to 1, then it indicates that the Key
>>      field is present in the GRE header.  Otherwise, the Key field is
>>      not present in the GRE header.
>>
>>      Sequence Number Present (bit 3)
>>
>>      If the Sequence Number Present bit is set to 1, then it indicates
>>      that the Sequence Number field is present.  Otherwise, the
>>      Sequence Number field is not present in the GRE header.
>>
>>      The  Key and Sequence Present bits are chosen to be  compatible
>>      with RFC 1701 [2].
>>
>>2.1. Key Field (4 octets)
>>
>>     The Key field contains a  four octet number which was inserted by
>>     the encapsulator. The actual method by which this Key is obtained
>>     is beyond the scope of this document.  Key field is intended to be
>>     used for  creating separate sub-tunnels within a  GRE Tunnel and the
>>     Key field identifies the sub-tunnel.
>>
>>2.2. Sequence Number (4 octets)
>>
>>    The Sequence Number field is a  four byte feild and is inserted by
>>    the  encapsulator when  Sequence Number  Present Bit  is set. The
>>    Sequence  Number MUST  be used  by the  receiver to  establish the
>>    order in which packets have been transmitted from the encapsulator
>>    to the receiver.  The intended use  of the Sequence Field is to
>>    provide unreliable and in-order  delivery.  If the Key present bit
>>    (bit 2) is set, the  sequence number is specific to the sub-tunnel
>>    identified by the Key field. Note that packets without the sequence
>>     bit set can be sent in between packets with the sequence bit set.
>>
>>    The  sequence number  value ranges from 1 to  2**32-1. The first
>>    datagram is sent with a sequence number of 1. The  sequence
>>    number is thus a free running counter represented modulo 2**32,
>>    with the exception that 1 is used when modulo 2**32 results in 0
>>    (i.e., rollover to 1 instead of 0).
>>
>>    When the decapsulator receives an out-of sequence packet it SHOULD
>>    be silently discarded. Additionally, reordering of out-of sequence
>>    packets  MAY  be  performed   by  the  decapsulator  for  improved
>>    performance and  tolerance to reordering in the  network (since the
>>    state of the stateful compression or encryption is reset by packet
>>    loss, it  might help the  performance to tolerate some  amount of
>>    packet reordering in the network by buffering). Exact buffering
>>    schemes are outside the scope of  this  document. Note that the
>>    sequence number is used to detect
>>    lost packets and/or restore  the original sequence of packets that
>>    may have been reordered during transport.
>>
>>   A packet  is considered an out-of-sequence packet  if the  sequence
>>   number  of  the  received packet  is  lesser than or equal to  the
>>   sequence  number   of last  successfully  decapsulated
>>   packet. The  sequence number  of a received message is considered
>>   less than or equal to the last successfully received  sequence number
>>   if its value lies in the range of the last received  sequence number
>>   and the preceding 65534 values, inclusive.
>>
>>
>>    If  the   received  packet  is   an  in-sequence  packet,   it  is
>>    successfully decapsulated.  Note that  the sequence number is used
>>    to  detect lost packets  and/or restore  the original  sequence of
>>    packets  (with  buffering) that  may  have  been reordered  during
>>    transport.   Use of  the  sequence number  option  should be  used
>>    appropriately; in particular, it is a good idea a avoid using when
>>    tunneling  protocols  that  have  higher layer  in-order  delivery
>>    mechanisms or are tolerant to out-of-order delivery. If only at certain
>>    instances the protocol being carried in the GRE tunnel requires
>>    in-sequence delivery, only the corresponding packets encapsulated
>>    in a GRE header can be sent with the sequence bit set. Mechanisims
>>    to determine which packets need to be sent in-sequence and the
>>    signaling mechanisims are outside the scope of this document.
>>
>>
>>
>>
>>3. IANA Considerations
>>
>>4. Acknowledgments
>>
>>
>>5. References
>>
>>   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
>>   "Generic           Routing           Encapsulation          (GRE),"
>>   draft-meyer-gre-update-03.txt, January 2000.
>>
>>   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
>>   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems,
>>   October 1994.
>>
>>   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
>>       Levels", RFC 2119, March 1997.
>>
>>
>>Dommety                                                 [Page 4]
>>
>>Internet Draft   Key and Sequence Number extensions to GRE   February 2000
>>
>>Author Information
>>
>>   Gopal Dommety
>>   Cisco Systems, Inc.
>>   170 West Tasman Drive
>>   San Jose, CA 95134
>>   e-mail: gdommety@cisco.com
>>
>>Dommety
>>
>>
>>
>>
>>
>>Thank You.
>>Regards,
>>Gopal
>>---------------------------------------------------------------------------
>----------------------------------
>>
>>Gopal Dommety
>>408 525 1404
>>gdommety@cisco.com
>>Cisco Systems, San Jose, CA, 95051
>>
>>---
>>You are currently subscribed to tsgp as: rhsu@qualcomm.com
>>
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 18 11:24:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18022
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Mar 2000 11:24:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6BD4DF0@standards.nortelnetworks.com>; Sat, 18 Mar 2000 11:20:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94023 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 11:18:54
          -0500
Received: from mailhub.fokus.gmd.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.591560B0@standards.nortelnetworks.com>; Sat, 18 Mar 2000 11:08:54
          -0500
Received: from acrux.fokus.gmd.de (acrux-u [193.175.135.67]) by
          mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA28993 for
          <mobile-ip@standards.nortelnetworks.com>; Sat, 18 Mar 2000 17:12:02
          +0100 (MET)
Received: from cco by acrux.fokus.gmd.de with local (Exim 2.05 #2 (Debian)) id
          12WLpI-0003Oj-00; Sat, 18 Mar 2000 17:11:44 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
Message-ID:  <20000318171144.A10210@acrux.fokus.gmd.de>
Date:         Sat, 18 Mar 2000 17:11:44 +0100
Reply-To: Cristian CONSTANTIN <constantin@FOKUS.GMD.DE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Cristian CONSTANTIN <constantin@FOKUS.GMD.DE>
Subject:      [MOBILE-IP] Mobile IPv4 / IPSec
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello!

I need to know which are the latest drafts (RFCs?) describing the interaction
between Mobile IPv4 and IPSec.

One draft that I've found it's called "draft-bpatil-mobileip-sec-guide-00.txt"
(Securing MIP with IPSec).

It seems it has expired in Dec. 1999, though...

Bye now!
Cristian


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 18 12:14:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06688
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Mar 2000 12:14:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3EE4ED0@standards.nortelnetworks.com>; Sat, 18 Mar 2000 12:09:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94120 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 12:07:27
          -0500
Received: from monza.broadswitch.com (195.178.164.73) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.217CE0E0@standards.nortelnetworks.com>; Sat, 18 Mar 2000
          11:57:27 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <45AFD48D077ED211BB4700A0C9DCE8FD15AFD1@monza.broadswitch.com>
Date:         Sat, 18 Mar 2000 18:01:43 +0100
Reply-To: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Eklund <thomas.eklund@SWITCHCORE.COM>
Subject:      Re: [MOBILE-IP] Combination of binding update and home address op
              tion
              inmobile IPv6
X-To:         Guilhem Tardy <Guilhem.Tardy@CRC.CA>
X-cc:         "charliep@iprg.nokia.com" <charliep@iprg.nokia.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Guilhem Tardy [mailto:Guilhem.Tardy@CRC.CA]
> Sent: Wednesday, March 15, 2000 5:27 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MOBILE-IP] Combination of binding update and
> home address
> option inmobile IPv6
>
>
> Thomas Eklund wrote:
>
> > > It's not possible to process the
> > > binding update option immediate because its processing
> depends on the
> > > data in the home address option.
> > No,
> > You have to verify possible AH headers in the binding
> update option, check
> > the option length and the seq. no after that you proccess
> the home address
> > options which is the home address of the mobile node
> sending the binding
> > update and there is no sub otions defines today...
> >
> > This is how it looks in the header because the home addrss
> option is send in
> > a destination option header and it is a separate extension
> header... And how
> > you process the order of extension header and espescially
> if you have a AH
> > included has been clearified in the latest mobile ipv6
> draft (mobileipv6
> > version 10)...
> >
>
> Although I agree mostly with your comments, I would like to add that a
> correspondent node or Home Agent processing a Binding Update Option
> needs to screen the whole Destination Option for a Home
> Address Option,
> which I find ugly.
> I didn't see any better explanation for the processing and
> order of the
> options in rev. 10 compared to previous revisions, and I would
> appreciate if you commented further. For instance, what if there's
> several Home Address Options in the same Destination Option? And is
This is NOT specified in the draft...

And I have commented this myself several times... This feature is a kind of
multi homing feature... In other words you have several homeaddresses (one
per interface)...

I would be very happy to see this multihoming extension for mobile IPv6...

Charles Any comment?

Do you think we could add a chapter about multihoming and how the home agent
process several homeaddresses in the home address option...

Regards
 Thomas Eklund


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 18 13:04:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25220
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Mar 2000 13:04:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3BFC090@standards.nortelnetworks.com>; Sat, 18 Mar 2000 12:59:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94183 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 12:57:45
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.2754D570@standards.nortelnetworks.com>; Sat, 18 Mar 2000 12:47:43
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id MAA20391; Sat, 18 Mar 2000 12:52:04
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200003181752.MAA20391@ietf.org>
Date:         Sat, 18 Mar 2000 12:52:03 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-reg-tunnel-02.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobile IP Regional Registration
        Author(s)       : E. Gustafsson, A. Jonsson, C. Perkins
        Filename        : draft-ietf-mobileip-reg-tunnel-02.txt
        Pages           : 27
        Date            : 17-Mar-00

In Mobile IP a mobile node registers with its home agent each time it
changes care-of address.  If the distance between the visited network
and the home network of the mobile node is large, the signaling
delay for these registrations may be long.  We propose a new kind of
regional registrations, i.e., registrations local to the visited
domain.  Regional registrations reduce the number of signaling
messages to the home network, and reduce the signaling delay when a
mobile node moves from one foreign agent to another, within the same
visited domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-reg-tunnel-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-02.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:     <20000317103055.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-02.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-reg-tunnel-02.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000317103055.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 18 21:10:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22320
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 18 Mar 2000 21:10:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B630E500@standards.nortelnetworks.com>; Sat, 18 Mar 2000 21:05:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94512 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 21:03:47
          -0500
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7378A9F0@standards.nortelnetworks.com>; Sat, 18 Mar 2000
          21:03:46 -0500
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id NAA00359; Sun,
          19 Mar 2000 13:07:33 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA08774; Sun, 19
          Mar 2000 13:08:11 +1100 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2448.0)
          id <G78HGMSF>; Sun, 19 Mar 2000 13:07:38 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF9147.E6037016"
Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A50185D7BA@eaubrnt018.epa.ericsson.se>
Date:         Sun, 19 Mar 2000 13:07:38 +1100
Reply-To: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
Subject:      Re: [MOBILE-IP] Combination of binding update and home address op
              tion
              inmobile IPv6
X-To:         Guilhem Tardy <Guilhem.Tardy@CRC.CA>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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_01BF9147.E6037016
Content-Type: text/plain

Hi,

If a MN has more than one Home address, then when performing a Home
registration it has two options:
- Send one BU for each Home address (A relation of 1:1 between the BU and
the Home option)
- Send one BU with a prefix length other than Zero which will make the HA
act on behalf of that MN on each link it (ie HA) is attached to. This is
done by adding the interface identifier to the prefix of each one of these
links. This is explained in ch 9.5 in the latest rev of the draft. Some
issues might come up here of course because that assumption (the interface
identifier is the same on different links might not always be right).
However the MN has a choice as to what way it does its Home Registration.

As for registering with a CN , I believe it is always 1:1. ie. One BU per
Home address.

The Home option NEEDS to be placed before the IPSec header, since the Home
address is reqiored for the processing of the IPSec header.

Regards,
Hesham

> -----Original Message-----
> From: Guilhem Tardy [SMTP:Guilhem.Tardy@CRC.CA]
> Sent: Thursday, 16 March 2000 3:27
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] Combination of binding update and home
> address option inmobile IPv6
>
> Thomas Eklund wrote:
>
> > > It's not possible to process the
> > > binding update option immediate because its processing depends on the
> > > data in the home address option.
> > No,
> > You have to verify possible AH headers in the binding update option,
> check
> > the option length and the seq. no after that you proccess the home
> address
> > options which is the home address of the mobile node sending the binding
> > update and there is no sub otions defines today...
> >
> > This is how it looks in the header because the home addrss option is
> send in
> > a destination option header and it is a separate extension header... And
> how
> > you process the order of extension header and espescially if you have a
> AH
> > included has been clearified in the latest mobile ipv6 draft (mobileipv6
> > version 10)...
> >
>
> Although I agree mostly with your comments, I would like to add that a
> correspondent node or Home Agent processing a Binding Update Option
> needs to screen the whole Destination Option for a Home Address Option,
> which I find ugly.
> I didn't see any better explanation for the processing and order of the
> options in rev. 10 compared to previous revisions, and I would
> appreciate if you commented further. For instance, what if there's
> several Home Address Options in the same Destination Option? And is
> there any order assumed (e.g. Home Address Options located *before* a
> Binding Update Option), or should a correspondent node or Home Agent
> handle any of the possible situations (and therefore do the ugly thing)?
>
> These are basic implementation consideration, and as I believe IPv6
> requires the extension headers (e.g. Hop-by-Hop, Destination) to be
> processed in order, I assume the same requirement applies to the options
> within each of those extension headers, which is impossible here.
>
> Best regards,
> Guilhem Tardy.
>
> --
>                                     phone: (613) 993-8232
> Network Systems and Technologies    fax:   (613) 998-9648
> Communications Research Center      email: Guilhem.Tardy@crc.ca
> 3701 Carling Ave. #28/2B            web:   http://www.crc.ca/
> Ottawa (Ontario) K2H 8S2

------_=_NextPart_001_01BF9147.E6037016
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2644.0">
<TITLE>RE: [MOBILE-IP] Combination of binding update and home address =
option inmobile IPv6</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If a MN has more =
than one Home address, then when performing a Home registration it has =
two options:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- Send one BU for =
each Home address (A relation of 1:1 between the BU and the Home =
option)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- Send one BU with =
a prefix length other than Zero which will make the HA act on behalf of =
that MN on each link it (ie HA) is attached to. This is done by adding =
the interface identifier to the prefix of each one of these links. This =
is explained in ch 9.5 in the latest rev of the draft. Some issues =
might come up here of course because that assumption (the interface =
identifier is the same on different links might not always be right). =
However the MN has a choice as to what way it does its Home =
Registration.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As for registering =
with a CN , I believe it is always 1:1. ie. One BU per Home address. =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The Home option =
NEEDS to be placed before the IPSec header, since the Home address is =
reqiored for the processing of the IPSec header. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Guilhem Tardy =
[SMTP:Guilhem.Tardy@CRC.CA]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, 16 March 2000 3:27</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MOBILE-IP@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: [MOBILE-IP] Combination of =
binding update and home address option inmobile IPv6</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thomas Eklund wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; It's not possible to process =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; binding update option =
immediate because its processing depends on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; data in the home address =
option.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; No,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; You have to verify possible AH =
headers in the binding update option, check</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the option length and the seq. =
no after that you proccess the home address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; options which is the home =
address of the mobile node sending the binding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; update and there is no sub =
otions defines today...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This is how it looks in the =
header because the home addrss option is send in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a destination option header and =
it is a separate extension header... And how</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; you process the order of =
extension header and espescially if you have a AH</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; included has been clearified in =
the latest mobile ipv6 draft (mobileipv6</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; version 10)...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Although I agree mostly with your =
comments, I would like to add that a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">correspondent node or Home Agent =
processing a Binding Update Option</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">needs to screen the whole Destination =
Option for a Home Address Option,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which I find ugly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I didn't see any better explanation =
for the processing and order of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">options in rev. 10 compared to =
previous revisions, and I would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">appreciate if you commented further. =
For instance, what if there's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">several Home Address Options in the =
same Destination Option? And is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">there any order assumed (e.g. Home =
Address Options located *before* a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Binding Update Option), or should a =
correspondent node or Home Agent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">handle any of the possible situations =
(and therefore do the ugly thing)?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">These are basic implementation =
consideration, and as I believe IPv6</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requires the extension headers (e.g. =
Hop-by-Hop, Destination) to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">processed in order, I assume the same =
requirement applies to the options</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">within each of those extension =
headers, which is impossible here.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Guilhem Tardy.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; phone: (613) 993-8232</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Systems and =
Technologies&nbsp;&nbsp;&nbsp; fax:&nbsp;&nbsp; (613) 998-9648</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Communications Research =
Center&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: Guilhem.Tardy@crc.ca</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3701 Carling Ave. =
#28/2B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 web:&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A HREF=3D"http://www.crc.ca/" =
TARGET=3D"_blank">http://www.crc.ca/</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ottawa (Ontario) K2H 8S2</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BF9147.E6037016--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 20 00:08:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12736
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Mar 2000 00:08:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B127D950@standards.nortelnetworks.com>; Mon, 20 Mar 2000 0:03:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 94947 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 00:01:36
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0F61EDA0@standards.nortelnetworks.com>; 19 Mar 2000 23:51:35 -0500
Received: from ani.univie.ac.at (heraklit.ani.univie.ac.at [131.130.32.104]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA01030 for
          <mobile-ip@smallworks.com>; Sun, 19 Mar 2000 22:55:57 -0600 (CST)
Received: from www.archimedes.ani.univie.ac.at (archimedes [131.130.32.138]) by
          ani.univie.ac.at (8.9.3/8.8.8) with ESMTP id OAA16450 for
          <mobile-ip@smallworks.com>; Thu, 16 Mar 2000 14:50:10 +0100 (MET)
Received: (from gabi@localhost) by www.archimedes.ani.univie.ac.at
          (8.8.8+Sun/8.8.8) id OAA20598 for mobile-ip@SMALLWORKS.COM; Thu, 16
          Mar 2000 14:56:50 +0100 (MET)
Message-ID:  <200003161356.OAA20598@www.archimedes.ani.univie.ac.at>
Date:         Thu, 16 Mar 2000 14:56:50 +0100
Reply-To: Gabriele Kotsis <gabi@ANI.UNIVIE.AC.AT>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gabriele Kotsis <gabi@ANI.UNIVIE.AC.AT>
Subject:      [MOBILE-IP] CFP WETICE2K
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

-                               WET ICE 2000
                IEEE Eighth International Workshops on
   Enabling Technologies: Infrastructure for Collaborative Enterprises
                              June 14-16, 2000,
               National Institute of Standards and Technology
                           Gaithersburg, Maryland, USA

             Sponsors: IEEE Computer Society and
                       CERC at West Virginia University
                 Host: Center for Design Research, Stanford University

WORKSHOP:             Web-based Infrastructures and
         Coordination Architectures for Collaborative Enterprises


CALL FOR PAPERS  - DEADLINE MARCH 31!!


This workshop continues two threads of workshops in the WETICE series that
were held over the last four years. In general these workshops addressed
the question of how Web techniques can be used to achieve or to improve
collaboration within or between organizations, and which coordination
mechanisms could be used in such an architecture.

A list of topics of interest includes (but is not limited to):

Collaborative Applications
     virtual organisations
     show case scenarios
     reports on hands-on experiences
Infrastructure and Technology
     coordination models and languages for the Web
     workflow languages
     languages and architectures for Web interoperability
     use of recent Internet and Web standards
     agent based approaches
     support for mobile users and software
Development of Collaborative Applications
     engineering methodologies for collaborative Web applications
     collaboration versus competition
     development methodologies, tools and platforms
     coordination patterns

Workshop Organization

Each paper will be reviewed by at least three reviewers. The workshop will
consist of 3 sessions presenting and discussing papers and a final working
session preparing the workshop report. 40% of the workshop's time will be
dedicated to discussion. Each paper presentation should provide answers
and/or considerations related to a list of main questions/topics that each
presenter will receive prior to the workshop.

Submission Details

Papers should contain original contributions not published or submitted
elsewhere, and references to related state-of-the-art work. Authors of
accepted papers are expected to present their views of the field at
the oral presentation.


Papers up to six pages (including figures, tables and references) can be
submitted. Papers should follow the IEEE format , which is single spaced,
two columns, 10 pt Times/Roman font. Papers should include a title, the name
and affiliation of each author, an abstract of up to 150 words and no more
than eight keywords. Authors are also required to provide contact addresses,
if different from the submitting electronic address.

Please, submit your paper in electronic format (PostScript or PDF) via the
following WWW-Interface (thanks to David Nicol for providing WIMPE):

        http://scylla.ani.univie.ac.at/~wetice2k/forms/authpaper_reg.html

Additionally, authors may send the URL of their paper and/or of their
home page to be included into the WWW page of the workshop.

As an exception, papers may also be submitted as hardcopies. In that case
submit 5 copies of your paper to one of the organisers.

Interested experts in one or many of the workshop's focal points are invited
to  register as a referee via

        http://scylla.ani.univie.ac.at/~wetice2k/forms/referee_reg.html

Full papers accepted for the workshop will be included in the
post-proceedings.

The best paper of the workshop will be nominated for the WETICE best-paper
award.

Paper submissions are not required for participation in the workshop. If you
plan to participate and want to receive a copy of the question/topics-list
prior to the workshop, please contact the organizers.

If you have further questions or remarks, don't hesitate to contact the
workshop organizers.

Workshop Organizers

KIRSTIE L. BELLMAN
Aerospace Integration Science Center
The Aerospace Corporation, Mail Stop M6/214
P.O.Box 92957
Los Angeles, California 90009-2957, USA
Phone: +1 (310) 336-2191
bellman@aero.org

GABRIELE KOTSIS
Institut fuer Angewandte Informatik
Universitaet Wien
Lenaugasse 2/8
A-1080 Wien
Phone: +43 1 4277 38463, Fax: +43 1 4277 38451
gabi@ani.univie.ac.at
http://www.ani.univie.at/~gabi

CHRISTOPHER LANDAUER
Aerospace Integration Science Center
The Aerospace Corporation, Mail Stop M6/214
P.O.Box 92957
Los Angeles, California 90009-2957, USA
Phone: +1 (310) 336-1361
cal@aero.org

GUSTAF NEUMANN
Information Systems and Software Techniques
University of Essen
Universtaetsstrasse 9
D-45141 Essen
Germany
Phone: +49 201 183-4074, Fax: +49 201 183-4073
neumann@wi-inf.uni-essen.de
http://nestroy.wi-inf.uni-essen.de/

ROBERT TOLKSDORF
Technische Universität Berlin
FB 13, Informatik, KIT/FLP
FR 6-10
Franklinstr. 28/29
D-10587 Berlin
Germany
tolk@cs.tu-berlin.de
http://www.cs.tu-berlin.de/~tolk

FRANCO ZAMBONELLI
Dipartimento di Scienze dell'Ingegneria
Universita' di Modena e Reggio Emilia
Via Campi 213-b
41100 Modena
ITALY
Phone: +39-059-376735
franco.zambonelli@unimo.it
http://www.dsi.unimo.it/Staff/st35/Zambonelli.idc




Important Dates

 Full papers due to workshop
 organizers                              March 31, 2000

 Notification of decisions to paper
 authors                                 April 28, 2000

 Advance Registration                    May 26, 2000

 Workshop                                June 14-16, 2000

 Final papers due for proceedings        July 1, 2000


Papers are submitted directly to the Workshop organizers. Please use the
following URL for submission to this workshop:

http://scylla.ani.univie.ac.at/~wetice2k/forms/authpaper_reg.html.


General WETICE Information:

see http://www.ida.liu.se/conferences/WETICE/WETICE2000/


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 20 14:17:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20835
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Mar 2000 14:17:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E46B240@standards.nortelnetworks.com>; Mon, 20 Mar 2000 14:11:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 95984 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 14:10:17
          -0500
Received: from cheetah.cs.ucla.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9EC1DCF0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 14:00:16
          -0500
Received: from localhost (sjlee@localhost) by cheetah.cs.ucla.edu
          (8.9.1/UCLACS-5.0) with ESMTP id LAA02234; Mon, 20 Mar 2000 11:01:15
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.SOL.4.10.10003201056240.21093-100000@cheetah.cs.ucla.edu>
Date:         Mon, 20 Mar 2000 11:01:14 -0800
Reply-To: SJ Lee <sjlee@CS.UCLA.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: SJ Lee <sjlee@CS.UCLA.EDU>
Subject:      [MOBILE-IP] CFP - MobiHOC 2000
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

[Please accept our apologies if you receive duplicate messages]

=========================================================================


               Announcement and Call for Papers


                 THE FIRST ANNUAL WORKSHOP ON
             MOBILE AD HOC NETWORKING & COMPUTING

               in conjunction with Mobicom 2000

                        August 11, 2000
                  Boston, Massachusetts, USA

         http://www.ece.gatech.edu/~cktoh/workshop.html





SCOPE
=====

We are interested in work-in-progress, visionary papers, experimental
and systems-related papers. Papers should describe original, previously
unpublished, and not currently under review by another conference,
workshop, or journal. Topics of interest include, but are not limited to:

 - Ad Hoc Routing Protocols
 - Ad Hoc Multicasting Protocols
 - Ad Hoc Transport Issues
 - Service Discovery Protocols
 - Media Access Techniques
 - Low Power Algorithms and Protocols
 - Ad Hoc Mobile Applications
 - Sensor & Data Fusion Ad Hoc Networks
 - Quality of Service Issues
 - Ad Hoc Mobile Computing Platforms
 - Secure Ad Hoc Services

Please consult the program chairs if you are uncertain whether your paper
falls within the theme of this workshop.


SUBMISSIONS
===========

Postscript copies of your submissions should be sent to
C.-K. Toh (cktoh@ece.gatech.edu) and Nitin Vaidya (vaidya@cs.tamu.edu).
All papers will be reviewed for technical merit. Submissions should not
exceed 20 double-spaced pages (including text and figures).


IMPORTANT DATES
===============

Paper submission due:                  April 10th, 2000
Notification of acceptance:            May 15th, 2000
Camera ready version due:              June 1st, 2000


SPONSORSHIP
===========

    ACM SIGMOBILE and IEEE Communications Society


ORGANIZING COMMITTEE
====================

General Chair:
    Charles E. Perkins (Nokia Research Center)

Technical Co-Chairs:
    C.-K. Toh (Georgia Institute of Technology)
    Nitin H. Vaidya (Texas A&M University)

Advisory Committee:
    Leonard Kleinrock (UCLA/Nomadix)
    Victor O.K. Li (USC/Hong Kong University)

Local Arrangement Chair:
    Katia Obraczka (USC/ISI)

Publicity Chair:
    Sung-Ju Lee (University of California, Los Angeles)

Registration Chair:
    Elizabeth M. Royer (University of California, Santa Barbara)

Publication Co-Chairs:
    Stefano Basagni (University of Texas, Dallas)
    Violet R. Syrotiuk (University of Texas, Dallas)

Treasurer:
    Bruce Worthman (IEEE)

Steering Committee:
    Charles E. Perkins (Nokia Research Center)
    C.-K. Toh (Georgia Institute of Technology)
    Nitin H. Vaidya (Texas A&M University)

Technical Program Committee:
    Samir Das                     University of Cincinnati
    Deborah Estrin                USC/ISI
    J.J. Garcia-Luna-Aceves       University of California, Santa Cruz
    Mario Gerla                   University of California, Los Angeles
    Zygmunt Haas                  Cornell University
    Parviz Kermani                IBM Research
    Katia Obraczka                USC/ISI
    Stephen Pink                  University of Arizona
    Ram Ramanathan                BBN Technologies
    Adam Wolisz                   Technische Universitat Berlin


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 20 16:19:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08431
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Mar 2000 16:19:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.516DE4E0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 16:14:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96170 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 16:13:02
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C4909AA0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 16:03:01
          -0500
Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id PAA07250 for
          <mobile-ip@smallworks.com>; Mon, 20 Mar 2000 15:07:24 -0600 (CST)
Received: from tot-tj.proxy.aol.com (tot-tj.proxy.aol.com [152.163.213.131]) by
          rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id QAA11932;
          Mon, 20 Mar 2000 16:06:45 -0500 (EST)
Received: from 203.73.10.100 (98AA1C7A.ipt.aol.com [152.170.28.122]) by
          tot-tj.proxy.aol.com (8.10.0/8.10.0) with SMTP id e2KL6Hx31538; Mon,
          20 Mar 2000 16:06:23 -0500 (EST)
Received: from andybrod@aol.com by andybrod@aol.com (8.8.5/8.6.5) with SMTP id
          GAA08202 for <andybrod@aol.com>; Mon, 20 Mar 2000 13:31:11 -0600 (EST)
X-Apparently-From: BdavidC463@aol.com
Message-ID:  <>
Date:         Mon, 20 Mar 2000 13:31:11 EST
Reply-To: andybrod@aol.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Comments:     Authenticated sender is <andybrod@aol.com>
From: laura@5NETWEB.COM
Subject:      [MOBILE-IP] Brand New USA and INTERNATIONAL Merchant Accounts !!!
X-To:         andybrod@aol.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW
U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD.

Click below to Apply

http://3462929566/%67e%67%65g%65/%69n%64%65x%2E%68%74%6D%6C#@3626198025/%31%399%39m%65%72%63%68%61%6Et%73/%69%6Ede%78%2E%68%74%6D%6C@3491382728/%31%39%39%39%6D%65%72%63h%61%6Ets/%69%6E%64%65%78%2E%68%74%6D%6C

ARE YOU REALLY AN E-COMMERCE MERCHANT?
Increase your revenues by up to 1500% by accepting credit cards and
electronic checks.
Increase your customer base 200- 400% with instant access to the World.

ARE YOU PAYING TOO MUCH?
Discount rates start at 2.1%
Transaction fees start at 25 cents.

DO YOU WAIT TOO LONG FOR YOUR MONEY?
Funds available in 24-48 hours anywhere in the world

DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS
99% of all applications are approved.

ARE YOU LIMITED BY WHAT YOU CAN ACCEPT?
Mastercard, Visa, Discover, Amex and Checks (USA checks only)
All cards from ALL COUNTRIES - Including Eastern Europe and Asia

- - - - - - - - - -
-
Click HERE to APPLY.


http://3462929566/%67e%67%65g%65/%69n%64%65x%2E%68%74%6D%6C#@3626198025/%31%399%39m%65%72%63%68%61%6Et%73/%69%6Ede%78%2E%68%74%6D%6C@3491382728/%31%39%39%39%6D%65%72%63h%61%6Ets/%69%6E%64%65%78%2E%68%74%6D%6C

NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A
MERCHANT ACCOUNT.

- - - - - - - - - -




(REMOVAL INSTRUCTIONS) This is a one-time mailing, done by an independent
marketing company.
 We respect your online privacy and apologize if you have received this message
in error. To be removed, simply delete this message and you will not receive any
additional messages.


Just Click or copy and paste the link below in you Internet Explorer Browser:


http://angelfire.com%40%77%77%77%2E%63%79ber%67%61%74%65w%61%79%2E%6E%65%74/t%68e%72%65%6D%6F%76e%31/r%65%6Do%76%65%2E%68%74%6D#@f%72%65%65%79%65%6C%6C%6Fw.%63%6F%6D/%6D%65%6D%62%65%72%73/b%69%67%6Der%63%68a%6E%74%73%74%75%66%66/i%6Edex%2E%68%74%6D%6C


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 20 16:28:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11757
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 20 Mar 2000 16:28:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A5F5610@standards.nortelnetworks.com>; Mon, 20 Mar 2000 16:23:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96175 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 16:22:40
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1D440320@standards.nortelnetworks.com>; Mon, 20 Mar 2000 16:12:39
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate.mot.com (motgate 2.1) with ESMTP id OAA21657 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 20 Mar 2000 14:17:07
          -0700 (MST)]
Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by
          mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA27459 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 20 Mar 2000 14:17:06
          -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay2.cig.mot.com
          (8.9.0/SCERG-RELAY-1.11b) with ESMTP id PAA21925 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 20 Mar 2000 15:16:59
          -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id PAA06406 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon,
          20 Mar 2000 15:16:57 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------E14C8DEF69685140D0FA4DB0"
Message-ID:  <200003202116.PAA06406@dolce.cig.mot.com>
Date:         Mon, 20 Mar 2000 14:31:56 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      [MOBILE-IP] RP Flow Control
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------E14C8DEF69685140D0FA4DB0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello All,
Here is the initial draft of the flow control extension for RP
interface. Lately we have been doing some work and it seems, it is
useful to have flow control for RP interface. We would like to have your
comments and suggestion for improvement for the attached document.
regards,
ajoy

--------------E14C8DEF69685140D0FA4DB0
Content-Type: text/plain; charset=us-ascii;
 name="draft-singh-mobileip-fcext-00.txt"
Content-Disposition: inline;
 filename="draft-singh-mobileip-fcext-00.txt"
Content-Transfer-Encoding: 7bit



MOBILE IP WORKING GROUP                            Ajoy Singh
Internet Draft                                     Irafan Ali
Document: draft-singh-mobileip-fcext-00.txt        Sebastian Thalanany,
Category: Standard Track                           Motorola
Expires August 2000                                Umamaheswar Acahari Kakinada,
                                                   3 Com Corporation
                                                   Rohit Verma,
                                                   Deloitte Consulting

        Flow control extension to Mobile IP for 3G Wireless Networks
                <draft-singh-mobileip-fcext-00.txt>

Status of this Memo

   This document is an internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as ``work in
   progress''.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   This draft proposes an extension to mobile IP as used in third
   generation wireless network [7,1,14] to provide a flow control
   mechanism on a per-session basis for data sent from the packet data
   servicing node (PDSN) to a radio network node (RNN). This extension
   solves the problem of significant performance degradation when
   packets are dropped at the RNN due to channel setup latency and rate
   mismatch between the air interface and link between the RNN and PDSN
   (RP link).

2. Conventions used in this document

2.1 Requirements keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [8].


Singh et. al,        RP Flow Control  August 2000                    1

                  draft-singh-mobileip-fcext-00.txt       August 2000

2.2 Terminology

     CDMA                  Code Division Multiple Access
     LZW                   Lempel-Ziv and Welch
     PDSN                  Packet Data Serving Node
     RNN                   Radio Network Node
     RP                    Interface between the RNN and the PDSN
     RF                    Radio Frequency

3. Introduction

   The high level architecture of a third generation cdma2000 network
   RP interface is shown in Figure 1 [7,1,14].

         +---------+            +---------+         +---------+
         |         |            |         |         |         |
         |   RNN   |----RP------|  PDSN   |---------|  HA     |
         |         | Interface  |         |         |         |
         +---------+            +---------+         +---------+
            /|\
             |  Visited Access                    Home Network
             |  Provider Network
             |
             |
            \|/
        +--------+
        | Mobile |
        | Node   |
        +--------+_

     Figure 1: The Third Generation cdma2000 Network RP Interface [7,1]

   In figure 1, GRE encapsulated link layer traffic is exchanged
   between a PDSN and a RNN. RNN buffers packets received from the PDSN
   when it is unable to schedule radio resources for transmitting the
   packets received from the PDSN.

   The RNN interacts with a mobile node over a low bandwidth RF link,
   while it interacts with a PDSN over a relatively high bandwidth
   wired link. This is likely to cause packet loss since the PDSN can
   transfer packets to the RNN at a higher rate than the rate at which
   the RNN can transfer these packets to the mobile node over the RF
   link. Additionally, buffer overflow may occur at the RRN as a result
   of the following reasons:

        Handoff signaling latency.
        Data transfer rate reduction as a result of RF link
        degradation.
        Scheduling latency in an overloaded system.




Singh et.al,         RP Flow Control August 2000                    2

                  draft-singh-mobileip-fcext-00.txt       August 2000

   The effects of packet losses are amplified when delta compression
   [2,3] algorithms are used to compress packet headers or LZW based
   payload compression [4,5] is used. The loss of one compressed packet
   results in a loss of a larger number of packets. Also, packets
   subsequent to a dropped packet at the RNN, which are not correctly
   decompressed by the mobile node, are transmitted on the air-
   interface. This results in wastage of precious air-interface
   bandwidth.

   Moreover, even in cases where no compression is used, the loss of
   one packet at the RNN could result in multiple PPP frames being
   dropped at the mobile node as multiple PPP frames could be
   encapsulated in a single GRE packet or the dropped GRE packet could
   contain a PPP frame boundary.

   The objective of the flow-control mechanism is to reduce the packet
   drops at the RNN. Packets could be buffered at the PDSN or dropped
   before the compression process at the PDSN. The utility of the
   proposed flow control mechanism is not limited to links carrying
   compressed traffic, it may also be used to enhance throughput for
   non-compressed traffic.


4. Mobile/IP and RP protocol Extensions

   This section describes extensions to Mobile/IP [9] and RP[7,1,14]
   protocol required to support flow control at RP interface within the
   third generation cdma2000 network.

4.1 Registration Request

   An RNN will send flow control extension as a part of a Registration
   Request message. The flow control extension SHOULD be attached by
   RNN as part of Registration Request to negotiate flow control with
   PDSN. The flow control extension should be attached after the
   session specific extension defined in the RP interface protocol
   [7,1,14]. The format of flow control is defined in section 4.2.

4.2. Flow Control Extension

   This extension is defined to carry information related to flow
   control for the session between a RNN and a PDSN across the RP
   interface. It should be a part of the Registration Request and Reply
   messages. The code field in the request message MUST be set to 1 for
   the peer to detect flow control support. If the recipient also
   supports this extension then the code is set to zero, else the code
   is set to a non-zero value.






Singh et.al,         RP Flow Control August 2000                    3

                  draft-singh-mobileip-fcext-00.txt       August 2000


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    | Code  |          PPD          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Receive Window Size                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Starting Tx Window Size                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The detailed format of the extension is shown as follows.


        Type            TBD.


        Length          This is one octet field and it indicates the
                        length (in bytes) of the extension, NOT
                        including the Type and Length fields.

        Code            1 in Request
                        0 in Reply if accepted
                        Non zero in reply if extension not acceptable.

        PPD             A measure of packet processing delay (PPD).
                        This value is specified in units of 1/10
                        seconds. For sliding window flow control, see
                        section 6.3 for a description of how this value
                        is determined and used. For ON-OFF flow
                        control, see Section 7.

        Receive Window Size This Indicates receive window size of
                        sender. In case the value set by the sender is
                        non-zero, then sliding window flow control is
                        being negotiated. In case the value is 0, then
                        ON-OFF flow control is being negotiated. Note
                        that a zero receive window size is not
                        appropriate for sliding window flow control. In
                        reply if code is non-zero this field is not
                        interpreted.

        Starting Tx Sequence Number Indicates starting transmit
                        sequence number. In reply if code is non-zero
                        this field is not interpreted.


   When a Registration Request is received by a PDSN, if the PDSN
   supports the flow control extension, it sets the expected receive
   sequence number to the Starting Tx sequence number of the extension.
   For sliding window flow control, the PDSN also

Singh et.al,         RP Flow Control August 2000                    4

                  draft-singh-mobileip-fcext-00.txt       August 2000

   sets the its transmit window size to the receive window size
   received in the flow control extension and uses the PPD value to as
   a seed to the adaptive algorithm to compute time-out value as
   specified in Section 6.3. For ON-OFF flow control, the PDSN uses PPD
   for the timeout value to avoid deadlock situation due to drop of ON
   signal from the receiver as specified in Section 7.

   To signal to the RNN that the PDSN supports flow control, a PDSN
   MUST set the Code to zero in the flow control extension of the
   Registration Reply message. When the flow control extension is NOT
   supported by PDSN, the extension (all fields) is copied to the
   Registration Reply without any changes. For sliding window flow
   control, the PDSN sets the receive window size to a non-zero value
   if flow-control is desired for data transfer from RNN to PDSN and to
   zero value if flow-control is not desired. For ON-OFF flow control
   the receive window size field is set to zero in the registration
   reply message. In either flow control schemes, the PDSN sets the
   starting Tx. sequence number and PPD field to appropriate values.

   When a Registration Reply is received by a RNN that has sent a
   Registration Request with flow control extension, the reply message
   MUST be processed as described in the following sentences. If the
   Registration Reply message does not contain the flow control
   extension or the Code field of the flow control extension is set to
   a non-zero value, the RNN will assume that the PDSN does not support
   flow control. Otherwise, based on the flow control mechanism being
   negotiated, the RNN uses the values in the different fields
   according to the logic specified above for PDSN.

4.3 Registration Reply

   The Registration Reply will be sent by a PDSN following the
   procedure as described in [7,1,14]. The PDSN shall attach a flow
   control extension with every Registration Reply message sent based
   on the procedure defined in Section 4.2, when the received
   Registration Request message contains a flow control extension. PDSN
   MAY accept or reject proposed flow control by setting appropriate
   code field of flow control extension as defined in Section 4.2.

5. GRE Extension

   The GRE header suggested in [10] is modified to add acknowledgement
   field, which will be used for sending explicit, or piggybacked
   acknowledgement of received GRE packet.









Singh et.al,         RP Flow Control August 2000                    5

                  draft-singh-mobileip-fcext-00.txt       August 2000

   The proposed GRE header will have the following format


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S|F| Reserved        |Ver  |        Protocol Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved (Optional)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Tx Sequence Number (Optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         ON-OFF Signal/Ack Sequence Number (Optional)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Key Present (bit 2)

        If the Key Present bit is set to 1, it indicates that the Key
        field is present in the GRE header. Otherwise, the Key field is
        not present in the GRE header.


   Tx Sequence Number Present (bit 3)

        If the Tx Sequence Number Present bit is set to 1, then it
        indicates that the Sequence Number field is present.
        This field MUST be set to support sliding Window based flow
        control.

   Flow Control Present (bit 4)

        If the Flow Control Present is bit set to 1, it indicates that
        the ON-OFF signal/Ack sequence number field is present.


   Key Field (4 octets)

        The Key Field contains a four octet number, which was inserted
        by the encapsulator. The key field will be used to send Session
        id of the RP session.

   Sequence Number (4 octets)

        Contains sequence number of the payload.


   ON-OFF Signal/Ack Sequence Number (4 octets)

        If sliding window flow control used, this field contains the
        sequence number of the highest numbered GRE packet received by

Singh et.al,         RP Flow Control August 2000                    6

                  draft-singh-mobileip-fcext-00.txt       August 2000

        the sending peer for this user session. If ON-OFF flow control
        is used, a non-zero value in this field is an OFF signal and a
        zero value is a ON signal from the receiver to the sender.


6.  Sliding Window Flow Control Mechanism

   This document proposes a sliding window protocol to provide flow
   control between a PDSN and an RNN. The main purpose of the sliding
   window protocol is to provide flow control. The tunnel peers do not
   perform packet retransmissions. Note: The sliding window mechanism
   provided here is identical to PPTP RFC [11]. Any recommendations on
   an improved sliding window mechanism are welcome.


6.1. Sliding Window Protocol

   The sliding window protocol used on the RP data path is used for
   flow control by the RP tunnel peers involved in packet transfers.
   The enhanced GRE protocol allows packet acknowledgments to be
   piggybacked on data packets. Acknowledgments can also be sent
   separate from data packets. The main purpose of the sliding window
   protocol is for flow control and the RP tunnel peers do not perform
   retransmissions.

6.1.1.  Initial Window Size

   Although each side has indicated (section 7) the maximum size of its
   receive window, it is recommended that a conservative approach be
   taken while starting a packet transfer. The initial window size on
   the transmitter is set to half the maximum size the receiver
   requested, with a minimum size of one packet. The transmitter stops
   sending packets when the number of packets awaiting acknowledgment
   is equal to the current window size.  As the receiver successfully
   digests each window, the window size on the transmitter is bumped up
   by one packet until the maximum is reached.  This method prevents a
   system from flooding an already congested network in the absence of
   history information.

6.1.2. Closing the Window

   When a time-out does occur on a packet transfer, the sender adjusts
   the size of the transmit window down to one half of it's value when
   it failed. Fractions are rounded up, and the minimum window size is
   one.

6.1.3 Opening the Window

   With every successful transmission of a window's worth of packet
   without a time-out, the transmit window size is increased by one



Singh et.al,         RP Flow Control August 2000                    7

                  draft-singh-mobileip-fcext-00.txt       August 2000

   packet until it reaches the maximum window size that was sent by the
   other side, when the call was connected.  As stated earlier, no
   retransmission is done on a time-out. After a time-out, the
   transmission resumes with the window starting at one half the size
   of the transmit window when the time-out occurred and adjusting
   upward by one each time the transmit window is filled with packets
   that are all acknowledged without time-outs.

6.1.3. Window Overflow

   When a receiver's window overflows with too many incoming packets,
   excess packets are thrown away. This situation should not arise if
   the sliding window procedures are being properly followed by the
   transmitter and receiver. It is assumed that, on the transmit side,
   packets are buffered for transmission and are no longer accepted
   from the packet source when the transmit buffer fills.

6.1.4. Multi-packet Acknowledgment

   One feature of the RP sliding window protocol is that it allows the
   acknowledgment of multiple packets with a single acknowledgment. All
   outstanding packets with a sequence number lower or equal to the
   acknowledgment number are considered acknowledged. Time-out
   calculations are performed using the time the packet corresponding
   to the highest sequence number being acknowledged was transmitted.
   Adaptive time-out calculations are only performed when an
   acknowledgment is received.  When multi-packet acknowledgments are
   used, the overhead of the adaptive time-out algorithm is reduced.
   The RNN is not required to transmit multi-packet acknowledgments.
   The RNN can instead acknowledge each packet individually as it is
   delivered to the higher layer.

6.2.  Out-of-sequence Packets

   Occasionally packets may lose their sequencing across a complicated
   internetwork. For instance, a PDSN may send packets 0 to 5 to a RNN.
   As a result of rerouting in the internetwork, packet 4 may arrive at
   the RNN before packet 3. The RNN acknowledges packet 4, and may
   assume that packet 3 is lost. This acknowledgment grants window
   credit beyond packet 4.

   When the RNN does receive packet 3, it MUST not attempt to transmit
   it to the corresponding higher layer.  To do so could cause
   problems, as proper PPP or any serial interface protocol operation
   is based upon receiving packets in sequence.  PPP properly deals
   with the loss of packets, but not with reordering. Therefore, out of
   sequence packets between the PDSN and RNN MUST be silently
   discarded, or they may be reordered by the receiver.  When packet 5
   comes in, it is acknowledged by the RNN since it has a higher
   sequence number than 4, which was the last highest packet
   acknowledged by the RNN.  Packets with duplicate sequence numbers
   should never occur since the RNN and PDSN never retransmit GRE

Singh et.al,         RP Flow Control August 2000                    8

                  draft-singh-mobileip-fcext-00.txt       August 2000

   packets. A robust implementation will silently discard duplicate GRE
   packets, if any are received.

6.3 Acknowledgment Time-Outs

   The RP protocol uses sliding windows and time-outs to provide both
   user session flow-control across the internetwork and to perform
   efficient data buffering to keep the RNN-PDSN data channels full
   without causing receive buffer overflow. RP protocol requires that a
   time-out be used to recover from dropped data or acknowledgment
   packets. The implementation of the time-out is vendor-specific. It
   is suggested that an adaptive time-out be implemented with backoff
   for congestion control.

   The time-out mechanism proposed here has the following properties:

   Independent time-outs for each session. A device (RNN or PDSN) will
   have to maintain and calculate time-outs for every active session.
   An administrator-adjustable maximum time-out, MaxTimeOut, unique to
   each device.

   An adaptive time-out mechanism that compensates for changing
   throughput. To reduce packet-processing overhead, vendors may choose
   not to recompute the adaptive time-out for every received
   acknowledgment.  The result of this overhead reduction is that the
   time-out will not respond as quickly to rapid network changes.
   Timer backoff on time-out to reduce congestion. The backed-off timer
   value is limited by the configurable maximum time-out value. Timer
   backoff is done every time an acknowledgment time-out occurs. In
   general, this mechanism has the desirable behavior of quickly
   backing off upon a time-out, and of slowly decreasing the time-out
   value as packets are delivered without time-outs.

Some definitions:

   Packet Processing Delay (PPD) is the amount of time required for
   each side to process the maximum amount of data buffered in their
   receive packet sliding window. The PPD is the value exchanged
   between the RNN and PDSN when a call is established. For the PDSN,
   this number should be small.  For a RNN making RF connections, this
   number could be significant.

   Sample is the actual amount of time incurred receiving an
   acknowledgment for a packet. The Sample is measured, not calculated.

   Round-Trip Time (RTT) is the estimated round-trip time for an
   Acknowledgment to be received for a given transmitted packet. When
   the network link is a local network, this delay will be minimal (if
   not zero). When the network link is the Internet, this delay could
   be substantial and vary widely. RTT is adaptive: it will adjust to
   include the PPD and whatever shifting network delays contribute to
   the time between a packet being transmitted and receiving its

Singh et.al,         RP Flow Control August 2000                    9

                  draft-singh-mobileip-fcext-00.txt       August 2000


   acknowledgement.

   Adaptive Time-Out (ATO) is the time that must elapse before an
   acknowledgment is considered lost.  After a time-out, the sliding
   window is partially closed and the ATO is backed off.

   The Packet Processing Delay (PPD) parameter is a 12-bit value
   exchanged during the Call Control phase that represents tenths of a
   second (64 means 6.4 seconds). The protocol only specifies that the
   parameter is exchanged, it does not specify how it is calculated.
   The determination of PPD values is implementation-dependent, and
   need not be variable (static time-outs are allowed). The PPD must be
   exchanged in the call connect sequences, even if it remains constant
   in an implementation. One possible way to calculate the PPD is:

   PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate


   Where,

   Header is the total size of the IP and GRE headers. MTU is the
   overall MTU for the internetwork link between the RNN and PDSN.

   WindowSize represents the number of packets in the sliding window,
   and is implementation-dependent. The latency of the internetwork
   could be used to pick a window size sufficient to keep the current
   session's pipe full. The constant 8 converts octets to bits
   (assuming ConnectRate is in bits per second). If the ConnectRate is
   in bytes per second, omit the 8. The value of PPD is used to seed
   the adaptive algorithm with the initial RTT[n-1] value.

6.3.1.  Calculating Adaptive Acknowledgment Time-Out

   The time-out allocated for the receipt of an acknowledgement is to
   be determined. If the time-out is set too high, the wait may be
   unnecessarily long for dropped packets. If the time-out is too
   short, the time-out may occur just before an acknowledgment arrives.
   The acknowledgement time-out should be reasonable and responsive to
   changing network conditions. The suggested adaptive algorithm
   described below is based on the TCP 1989 implementation and is
   explained in [11].  'n' means this iteration of the calculation, and
   'n-1' refers to values from the last calculation.

         DIFF[n] = SAMPLE[n] - RTT[n-1]
         DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
         RTT[n] = RTT[n-1] + (alpha * DIFF[n])
         ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
                  (chi * DEV[n]), MaxTimeOut))

   DIFF represents the error between the last estimated round-trip
   time and the measured time. DIFF is calculated on each iteration.

Singh et.al,         RP Flow Control August 2000                   10

                  draft-singh-mobileip-fcext-00.txt       August 2000

   DEV is the estimated mean deviation. This approximates the standard
   deviation. DEV is calculated on each iteration and stored for use in
   the next iteration. Initially, it is set to 0.

   RTT is the estimated round-trip time of an average packet. RTT is
   calculated on each iteration and stored for use in the next
   iteration. Initially, it is set to PPD.

   ATO is the adaptive time-out for the next transmitted packet. ATO is
   calculated on each iteration.  Its value is limited, by the MIN
   function, to be a maximum of the configured MaxTimeOut value.

   Alpha is the gain for the average and is typically 1/8 (0.125).

   Beta is the gain for the deviation and is typically 1/4 (0.250).

   Chi is the gain for the time-out and is typically set to 4.

   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled. With the suggested gain
   constants, they should be scaled by 8 to eliminate all division. To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.

6.3.2. Congestion Control: Adjusting for Time-Out

   This section describes how the calculation of ATO is modified in the
   case where a time-out does occur.  When a time-out occurs, the time-
   out value should be adjusted rapidly upward.  Although the GRE
   packets are not retransmitted when a time-out occurs, the time-out
   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the time-out when it expires (notice that in addition to
   increasing the time-out, we are also shrinking the size of the
   window as described in the next section).  For an interval in which
   a time-out occurs, the new  ATO is calculated as:

        RTT[n] = delta * RTT[n-1]
        DEV[n] = DEV[n-1]
        ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
                (chi * DEV[n]), MaxTimeOut))

   In this calculation of ATO, only the two values, that contribute to
   ATO and are stored for the next iteration, are calculated.  RTT is
   scaled by delta, and DEV is unmodified.  DIFF is not carried forward
   and is not used in this scenario.  A value of 2 for Delta, the time-
   out gain factor for RTT, is suggested.





Singh et.al,         RP Flow Control August 2000                   11

                  draft-singh-mobileip-fcext-00.txt       August 2000

7.ON-OFF Flow Control Mechanism

   In an ON-OFF flow control scheme, the receiver on detecting
   congestion event sends an explicit OFF signal to the sender to stop
   transmitting packets of a particular session. Once the receiver is
   ready to receive additional packets, it sends an ON signal event to
   the sender to restart transmission of a session's packet. The
   congestion event could be any receiver-defined event such as the
   average length of buffer dedicated to a flow reaching a high
   watermark. The congestion clearance signal, in such a case, would be
   the average queue length below a low watermark.

   ON-OFF flow control is simpler than sliding window flow control in
   the following manner:

   1.The receiver does not need to send explicit/piggybacked
   acknowledgement of the received packets. While sequence numbering is
   not needed for flow control, it could still be used to re-order out-
   of-sequence packets at the receiver.

   2.The logic at the sender and receiver is simpler in an ON-OFF flow
   control scheme.

   3.The bandwidth for feedback signaling is lower. Sliding window flow
   control requires constant updating of the ack sequence number,
   whereas in ON-OFF flow control, the receiver only sends an OFF or ON
   signal on detection/clearance of congestion conditions.

   However, ON-OFF flow control provides coarser flow control than
   sliding window flow control. In certain situations, such as when the
   tunneling end-points are not many hops away, ON-OFF flow control may
   be adequate.

   The extensions to Mobile IP protocol presented in Section 4 and 5
   enable either sliding window flow control or ON-OFF flow control to
   be used. As stated in Section 4.2, if the Receive window size field
   in a flow control extension message is set to zero (0), then ON-OFF
   flow control is being negotiated.

   Once an RP session has been opened, the sender MAY start
   transmitting packets in the GRE tunnel. The receiver is NOT REQUIRED
   to transmit an explicit ON signal to the sender.

7.1 Receiver's Logic

   On detecting a congestion event, the receiver transmits one or more
   OF signal to the sender. On the clearance of a congestion event, the
   sender sends one or more ON signal. The ON/OFF signal could be sent
   as a separate GRE packet or piggybacked onto data packets.

   It is RECOMMENDED that the detection of congestion/congestion-


 Singh et.al,         RP Flow Control August 2000                   12

                  draft-singh-mobileip-fcext-00.txt       August 2000

   clearance events at the receiver be based on averaged values rather
   than on instantaneous values for graceful operation.

   In the registration request message, the receiver informs the sender
   of the approximate time it takes for a congestion event to be
   cleared at the receiver in the PPD field of the flow control
   extension. Setting PPD to a low value could result in the sender
   sending packets to the receiver before a congestion is cleared,
   leading to packet drops at the receiver. Setting the PPD to a high
   value could result in the sender taking much longer to resume
   transmission of packets in case a ON signal is dropped by a network,
   resulting in lower throughput.

   As an OPTION, during congestion conditions, the receiver could
   periodically transmit OFF signals to the transmitter every alpha*PPD
   (alpha < 1.0) time units.

7.2 Sender's Logic

   On receiving an OFF signal from the receiver, the sender stops
   transmission of the tunneled session's packets. It should also start
   a timer on receipt of every OFF signal. The timeout value of the
   timer MUST be set to the value of PPD field flow control extension
   of the registration request message. On receipt of an ON signal or
   the expiration of the timer, the sender starts transmission of the
   tunneled session's packet.

   The timer is used at the sender to avoid a deadlock situation in
   case ON signals from the receiver are dropped in the network.

7.Security Considerations

   The flow control extension presented in this section will be used
   with base R-P interface protocol [7,1,14], so it will follow all the
   security measures supplied by R-P Interface protocol. No extra
   security measures are required to support flow control extension.

8.IANA Consideration

   This document specifies one new extension to Mobile IP protocol [9].
   The flow control Specific Extension defined in section 6 MUST be
   assigned the Type value of TBD.

9. References

   [1] 3GPP2 TSG-A,"3GPP2 Access Network Interfaces Technical
        Specification (3G-IOS)", Version 4.0.0, December 13 1999.

   [2] Jacobson, V., "Compressing TCP/IP Headers for low speed Serial
      links," RFC 1144, February 1990.



Singh et.al,         RP Flow Control August 2000                   13

                  draft-singh-mobileip-fcext-00.txt       August 2000

   [3] M. Degermark, B. Nordgren, S.Pink. "IP Header Compression",
   February 1999.

   [4] Pall, G., "Microsoft Point to Point Compression (MPPC)
   Protocol", RFC 2118, March 1997.

   [5] Friend, Simpson, "PPP LZS-DCP Compression Protocol (LZS-DCP),"
   RFC 1867, August 1996.

   [6] Hank, S., Li R., Farinacci, D., and P. Traina, "Generic Routing
   Encapsulation (GRE)", RFC 1701, October 1994.

   [7] Yong Chang, et. al, "Mobile IP Based Micro Mobility Management
   Protocol in The Third Generation Wireless Network", draft-ietf-
   mobileip-ext-02.txt

   [8] Brander, S., "Key words for use in RFCS to indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [9] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
   1996.

   [10] Gopal Dommety, "Key and Sequence Number Extensions to GRE",
     draft-dommety-gre-ext-00.txt

   [11] K. Hamzeh, "Point to point tunneling Protocol", RFC 2637, July
   1999.

   [12] Stevens, R, "TCP/IP Illustrated Volume 1", p. 300, Addison
   Wesley, 1994.

   [13] Postel, J.,"Transmission Control Protocol", STD 7, RFC 793,
   Sept 1981.

   [14] TR 45.6,"Wireless IP Network standards", Jan 13 2000.

12. Acknowledgments

   The authors of this draft would like to thank author of PPTP
   informational RFC 2637. This draft uses windowing mechanism proposed
   in PPTP RFC. The authors of this draft would like to thank Shreesha
   Ramana for valuable comments and review of this draft.

11. Author's Addresses

   Ajoy Singh
   Motorola
   1501 West Shure Driver
   Arlington Heights, IL- 60004
   Phone: 847-632 6941
   Email: asingh1@email.mot.com


Singh et.al,         RP Flow Control August 2000                   14

                  draft-singh-mobileip-fcext-00.txt       August 2000

   Irfan Ali
   Motorola
   1501 West Shure Driver
   Arlington Heights, IL- 60004
   Phone: 1-847-632-3281
   Email: FIA225@email.mot.com

   Sebastian Thalanany
   Motorola
   1475 West Shure Drive
   Arlington Heights, IL - 60004
   Phone: (847) 435-9296
   Email: sthalan1@email.mot.com

   Umamaheswar A, Kakinand
   3Com Corporation,
   1800 West Central Road,
   Mount Prospect, IL -60056
   Email: ukakinad@mw.3com.com

   Rohit Verma
   180, N. Stetson Ave.
   Chicago, IL 60601
   Email: rverma@dttus.com


   Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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.

Singh et.al,         RP Flow Control August 2000                   15

























































Singh et.al,         RP Flow Control August 2000                   16


--------------E14C8DEF69685140D0FA4DB0--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 21 04:53:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29205
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Mar 2000 04:53:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2A8A1B0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 4:48:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 96817 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 04:46:03
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F6F7A600@standards.nortelnetworks.com>; Tue, 21 Mar 2000 4:36:03
          -0500
Received: from milena.par.univie.ac.at (milena.par.univie.ac.at
          [131.130.186.60]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP
          id DAA10943 for <mobile-ip@smallworks.com>; Tue, 21 Mar 2000 03:40:27
          -0600 (CST)
Received: from nadine (nadine [131.130.186.22]) by milena.par.univie.ac.at
          (8.9.3/8.9.3) with SMTP id KAA11820 for <tfmisc@par.univie.ac.at>;
          Tue, 21 Mar 2000 10:33:18 +0100 (MET)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 8xjVRSe++3vS2UmspcqETw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Message-ID:  <200003210933.KAA11820@milena.par.univie.ac.at>
Date:         Tue, 21 Mar 2000 10:33:18 +0100
Reply-To: Thomas Fahringer <tf@par.univie.ac.at>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Fahringer <tf@par.univie.ac.at>
Subject:      [MOBILE-IP] Open Research Position: Execution-Driven Performance
              Analysis for
              Distributed/Parallel Applications
X-To:         tfmisc@par.univie.ac.at
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

The Institute for Software Science at the University of Vienna
is offering within a long-term research project a

    ***********************************************************
    ***  Research Position in Execution-Driven Performance  ***
    ***    Analysis for Distributed and Parallel Systems    ***
    ***********************************************************

Applicants should have knowledge in one or more of the
following areas:

        + distributed and parallel systems
        + performance measurement, monitoring, and tracing
        + on-line and post-execution performance analysis
        + performance visualization
        + programming skills
            + distributed programming (Java)
            + parallel programming (OpenMP, HPF, MPI, threads, ...)
        + databases and expert systems

Position: Research position for a doctoral student or a post-doc.

Starting Date: April 10, 2000

Duration: 3 years

Project Summary:

   The position is offered as part of a long-term research project
   about performance-oriented application development for distributed
   and parallel systems.

   The main task of this position requires to develop a performance
   analysis system that searches for performance problems in
   heterogeneous, object-oriented multi-threaded distributed and
   parallel applications exploiting both data and task parallelism.
   These applications are executed on clusters of SMPs or on
   heterogeneous workstation networks. Various instrumentation systems
   are used to obtain raw performance data while executing a program.
   Performance data may be stored in a data repository (database or
   expert system) for post-execution analysis. The system to be developed
   tries to find performance problems based on collected and computed
   performance data, and information about the input program provided by
   a compiler. Performance problems will be associated with the input program.
   Based on detected performance problems further decisions may be taken, e.g.
   refinement of instrumentation, more detailed search for performance problems,
   application and system changes to improve performance, etc.

For more information, please contact

        Thomas Fahringer (tf@par.univie.ac.at)


=======================================================================
Thomas Fahringer, Ph.D.             Tel: (office): +43 1 310 56 08 - 86
Associate Professor                 Tel: (sec):    +43 1 310 56 08 - 71
University of Vienna                Fax: +43 1 310 56 08 - 88
Institute for Software Science      E-mail: tf@par.univie.ac.at
Liechtensteinstr. 22                WWW: http://www.par.univie.ac.at/~tf
A-1090 Vienna, Austria


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

p.s. Note that there is another open research position at the Institute
for Software Science, University of Vienna. For more details see below:
Make sure that you indicate in your reply whether you apply for the research
position about execution-driven performance analysis or about performance
prediction.


The Institute for Software Science at the University of Vienna is offering
within a long-term research project a

    ********************************************************
    ***  Research Position in Performance Prediction of  ***
    ***     Distributed and Parallel Applications        ***
    ********************************************************

Applicants should have knowledge in one or more of the
following areas:

        + distributed and parallel systems
        + programming skills
            + distributed programming (Java)
            + parallel programming (OpenMP, HPF, MPI, threads, ...)
        + performance modeling (analytical + symbolic + simulation)
        + simulation tools (discrete event simulation)

Position: Research position for a doctoral student or a post-doc.

Starting Date: April 10, 2000

Duration: 3 years

Project Summary:

   The position is offered as part of a long-term research project
   about performance-oriented application development for parallel
   and distributed systems.

   The main task of this position requires to develop a performance
   prediction tool for heterogeneous, object-oriented multi-threaded
   parallel and distributed applications exploiting both data and
   task parallelism. These applications are executed on clusters
   of SMPs or on heterogeneous workstation networks.
   Analytical performance prediction will be used to determine
   parameterized cost functions for small components of a
   parallel/distributed application. Parameters in cost functions
   reflect the problem sizes of an application and the machine sizes
   of a target architecture. Simulation will be used to model
   highly dynamic behavior of applications and architectures, in
   particular, data exchange, synchronization, thread context-switches,
   etc. The performance prediction tool computes various performance
   parameters including estimated execution and communication times,
   synchronization overhead, memory locality, load balance, etc.

For more information, please contact

        Thomas Fahringer (tf@par.univie.ac.at)

=======================================================================
Thomas Fahringer, Ph.D.             Tel: (office): +43 1 310 56 08 - 86
Associate Professor                 Tel: (sec):    +43 1 310 56 08 - 71
University of Vienna                Fax: +43 1 310 56 08 - 88
Institute for Software Science      E-mail: tf@par.univie.ac.at
Liechtensteinstr. 22                WWW: http://www.par.univie.ac.at/~tf
A-1090 Vienna, Austria


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 21 17:57:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10942
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Mar 2000 17:57:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3DF49030@standards.nortelnetworks.com>; Tue, 21 Mar 2000 17:52:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 97817 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 17:51:22
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AC278A50@standards.nortelnetworks.com>; Tue, 21 Mar 2000 17:41:22
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate.mot.com (motgate 2.1) with ESMTP id PAA07884 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Mar 2000 15:45:53
          -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 PAA13582 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Mar 2000 15:45:51
          -0700 (MST)]
Received: by IL27EXB01 with Internet Mail Service (5.5.2650.21) id <HKGKFZ3G>;
          Tue, 21 Mar 2000 16:45:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <BB60654DFAA8D311B16400508B6F253898436E@il27exm05.cig.mot.com>
Date:         Tue, 21 Mar 2000 16:45:50 -0600
Reply-To: Wang John-EZW001 <John_Wang-EZW001@EMAIL.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Wang John-EZW001 <John_Wang-EZW001@EMAIL.MOT.COM>
Subject:      Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-reg-tunnel-02.txt
X-To:         "Internet-Drafts@IETF.ORG" <Internet-Drafts@IETF.ORG>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Universal Mobile IP (UMIP) Location Management
        Author(s)       : John Wang, Almon Tang
        Filename        : draft-wang-mobileip-umip-00.txt
        Pages           : 31
        Date            : 21-Mar-00

UMIP is an enabling system technology to support All IP 3G services
characterized by ubiquitous, integrated and efficient personal services for
real-time applications with high QoS and low cost. UMIP minimizes triangle
routing in signaling and bearer traffic. It offers integrated solutions for
personal mobility management, security and billing processes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wang-mobileip-umip-00.txt

Internet-Drafts can also be obtained by e-mail.

Your comments are appreciated.

Thanks,

John


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 21 18:23:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19716
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Mar 2000 18:22:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BF1DDF60@standards.nortelnetworks.com>; Tue, 21 Mar 2000 18:17:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 97872 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 18:17:35
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.55D8FA90@standards.nortelnetworks.com>; Tue, 21 Mar 2000 18:07:35
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id QAA27632 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Mar 2000 16:12:07
          -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101])
          by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA02670 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Tue, 21 Mar 2000 16:12:06
          -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id
          <HKGGYHH7>; Tue, 21 Mar 2000 17:12:06 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <BB60654DFAA8D311B16400508B6F2538984371@il27exm05.cig.mot.com>
Date:         Tue, 21 Mar 2000 17:12:04 -0600
Reply-To: Wang John-EZW001 <John_Wang-EZW001@EMAIL.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Wang John-EZW001 <John_Wang-EZW001@EMAIL.MOT.COM>
Subject:      [MOBILE-IP] I-D:draft-wang-mobileip-umip-00.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Due to the wrong subject contents in my previous message, here is the
replacement. Sorry for inconvenience.

John

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

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Universal Mobile IP (UMIP) Location Management
        Author(s)       : John Wang, Almon Tang
        Filename        : draft-wang-mobileip-umip-00.txt
        Pages           : 31
        Date            : 21-Mar-00

UMIP is an enabling system technology to support All IP 3G services
characterized by ubiquitous, integrated and efficient personal services for
real-time applications with high QoS and low cost. UMIP minimizes triangle
routing in signaling and bearer traffic. It offers integrated solutions for
personal mobility management, security and billing processes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wang-mobileip-umip-00.txt

Internet-Drafts can also be obtained by e-mail.

Your comments are appreciated.

Thanks,

John


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 21 21:24:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27248
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 21 Mar 2000 21:24:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15F6F5B0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 21:19:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 98156 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 21:17:13
          -0500
Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D3378EB0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 21:17:12
          -0500
Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by
          mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id
          LAA13157; Wed, 22 Mar 2000 11:21:37 +0900 (JST)
Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp
          (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id LAA19537; Wed, 22 Mar
          2000 11:21:36 +0900 (JST)
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <LYR1158584-196913-2000.03.17-00.58.48--rhsu#qualcomm.com@3
            gpp2.org> <200003172036.MAA03129@omega.cisco.com>
Content-Type: multipart/alternative;
              boundary="------------E03B614176BAD40114E2AE9D"
Message-ID:  <38D82E30.F123B687@u-aizu.ac.jp>
Date:         Wed, 22 Mar 2000 11:21:36 +0900
Reply-To: sarikaya@U-AIZU.AC.JP
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Behcet Sarikaya <sarikaya@U-AIZU.AC.JP>
Organization: University of Aizu
Subject:      Re: [MOBILE-IP] Anchor Handoff Draft
X-To:         Gopal Dommety <gdommety@CISCO.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------E03B614176BAD40114E2AE9D
Content-Type: text/plain; charset=iso-8859-9
Content-Transfer-Encoding: 7bit

Hello Gopal,
  In your anchor handoff draft RFC, you propose to use zone IDs to be
advertised
by FAs so that MNs can detect the change of the zone.
  In the draft RFC on regional registration (reg-tunnel-02), FAs should
include their NAIs
in the agent advertisements using FA NAI extension.
  While NAI has a well defined structure, and zone ID does not seem to
be well defined
however as a concept the zone ID could be better than NAI which was
defined to identify persons.
  What do you think?

Regards,

--behcet

--
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742
Home page:  http://www.u-aizu.ac.jp/~sarikaya/
email: sarikaya@u-aizu.ac.jp



--------------E03B614176BAD40114E2AE9D
Content-Type: text/html; charset=iso-8859-9
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Gopal,
<br>&nbsp; In your anchor handoff draft RFC, you propose to use zone IDs
to be advertised
<br>by FAs so that MNs can detect the change of the zone.
<br>&nbsp; In the draft RFC on regional registration (reg-tunnel-02), FAs
should include their NAIs
<br>in the agent advertisements using FA NAI extension.
<br>&nbsp; While NAI has a well defined structure, and zone ID does not
seem to be well defined
<br>however as a concept the zone ID could be better than NAI which was
defined to identify persons.
<br>&nbsp; What do you think?
<p>Regards,
<p>--behcet
<pre>--&nbsp;
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742&nbsp;
Home page:&nbsp; <A HREF="http://www.u-aizu.ac.jp/~sarikaya/">http://www.u-aizu.ac.jp/~sarikaya/</A>
email: sarikaya@u-aizu.ac.jp</pre>
&nbsp;</html>

--------------E03B614176BAD40114E2AE9D--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 22 18:32:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23663
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 22 Mar 2000 18:32:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D6CF350@standards.nortelnetworks.com>; Wed, 22 Mar 2000 18:26:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 99328 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 18:24:59
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7532BD20@standards.nortelnetworks.com>; Wed, 22 Mar 2000 18:14:26
          -0500
Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id RAA22464 for
          <mobile-ip@smallworks.com>; Wed, 22 Mar 2000 17:18:57 -0600 (CST)
Received: from localhost by cse.uta.edu (8.9.0/8.9.0) with SMTP id RAA29113;
          Wed, 22 Mar 2000 17:18:24 -0600 (CST)
X-Sender: ramesh@cse
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GSO.3.96.1000322170309.28816B-100000@cse>
Date:         Wed, 22 Mar 2000 17:18:24 -0600
Reply-To: Ramesh Yeraballi <ramesh@CSE.UTA.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ramesh Yeraballi <ramesh@CSE.UTA.EDU>
Subject:      [MOBILE-IP] WoWMoM-2000: Call for Papers
X-To:         alg@comm.toronto.edu, cabernet-events@ncl.ac.uk,
              cellular@dfv.rwth-aachen.de, cnom@maestro.bellcore.com,
              commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk,
              ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu,
              DMANET@zpr.uni-koeln.de, end2end-interest@isi.edu,
              enternet@bbn.com, giga@tele.pitt.edu, hipparch@sophia.inria.fr,
              ieeetcpc@ccvm.sunysb.edu, itc@ieee.org, kuvs-elg@fokus.gmd.de,
              manet@itd.NRL.NAVY.MIL, mobile-ip@smallworks.com,
              multicomm@cc.bellcore.com, multicomm@research.panasonic.com,
              performance@haven.epm.ornl.gov, reres@laas.fr,
              sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov,
              tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@Dartmouth.EDU,
              testnet@canarie.ca, xtp-relay@cs.concordia.ca
X-cc:         WoWMoM Committee -- Amitave Mukherjee
              <amitava.mukherjee@in.pwcglobal.com>,
              Andrew Campbell <campbell@comet.columbia.edu>,
              Anthony Joseph <adj@rover.CS.Berkeley.EDU>,
              Anurag Kumar <anurag@ece.iisc.ernet.in>,
              Azzedine Boukerche <boukerch@silo.csci.unt.edu>,
              Claude Castelluccia <claude.castelluccia@inrialpes.fr>,
              Cristopher Rose <crose@steph.Rutgers.EDU>,
              Dhawal Moghe <moghe@nortel.com>,
              Giridhar Mandyam <giridhar.mandyam@nokia.com>,
              Hiroyuki Morikawa <mori@mlab.t.u-tokyo.ac.jp>,
              Ian Akyildiz <ian@ee.gatech.edu>,
              Imrich Chlamtac <chlamtac@utdallas.edu>,
              Jason Redi <jredi@bbn.com>, "K.-C. Chua" <chuakc@cwc.nus.edu.sg>,
              Kalyan Basu <kbasu@nortelnetworks.com>,
              Krishna Sivalingam <krishna@eecs.wsu.edu>,
              Lorenzo Donatiello <donat@CS.UniBO.IT>,
              Mahmoud Naghsineh <mahmoud@us.ibm.com>,
              Mani Srivastava <mbs@JAserv1.janet.ucla.edu>,
              Marco Conti <M.Conti@cnuce.cnr.it>,
              Maurizio Bonuccelli <bonucce@di.unipi.it>,
              Mischa Schwartz <schwartz@ctr.columbia.edu>,
              Mohan Kumar <kumar@cs.curtin.edu.au>,
              Prathima Agrawal <pagrawal@research.telcordia.com>,
              Pravin Bhagawat <pravin@watson.ibm.com>,
              Raja Neogi <rajaneogi@home.com>,
              Randy Katz <randy@cs.Berkeley.edu>, Sajal Das <das@cse.uta.edu>,
              Sanjoy Sen <sanjoy@nortel.com>,
              Satish Tripathi <tripathi@engr.ucr.edu>,
              Subir Das <subir@research.telcordia.com>,
              Sumit Roy <roy@ee.washington.edu>,
              Tom Jacob <jacob@silo.csci.unt.edu>,
              Vasant Prabhu <prabhu@uta.edu>,
              Venkat Padmanabhan <padmanab@microsoft.com>,
              Violet Syrotiuk <syrotiuk@utdallas.edu>,
              Yanghee Choi <yhchoi@mmlab.snu.ac.kr>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello Everybody,
You may have received this announcement in the begining of February. This
is a reminder that the deadline for submission is fast approaching (April
25th). The workshop was a phenomenal success last year both due to the
quality of papers and the audience turnout. We hope to repeat or even
better this year.

My apologies if you receive multiple copies of this announcement.

Regards
Ramesh Yerraballi

-----------------------------------
  Dr. Ramesh Yerraballi
  Assistant Professor, Dept. of CSE
  Univ. of Texas at Arlington
  Phone: (817)-272-5128 e-mail: ramesh@cse.uta.edu
-----------------------------------



                           Call for Papers
-------------------------------------------------------------------------
                 The Third ACM International Workshop on

        WIRELESS MOBILE MULTIMEDIA (WoWMoM-2000)

              (to be held in conjunction with MobiCom-2000)

                      August 11, 2000 (Friday)
              Seaport Hotel at the World Trade Center
                     Boston, Massachusetts, USA

                     Sponsored by ACM SIGMOBILE
         with support from Nortel Networks, Microsoft Research,
              University of California at Riverside, and
   DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science, and
           CReWMaN at the University of Texas at Arlington

             URL: http://www.cse.uta.edu/crew/wowmom-2000/

               SUBMISSION DEADLINE:  April  25, 2000

GENERAL CHAIR

Sajal K. Das, Director
Center for Research in Wireless Mobility and Networking (CReWMaN)
Department of Computer Science and Engineering       Tel: (817) 272-7405
The University of Texas at Arlington                 Fax: (817) 272-3784
Arlington, TX 76019-0015                          E-mail: das@cse.uta.edu


PROGRAM CO-CHAIRS

Satish K. Tripathi, Dean                       Kalyan Basu, Director
William R. Johnson, Jr. Family Professor       Wireless Technologies
Bourns College of Engineering                  Nortel Networks
University of California                       2201 Lakeside Blvd
Riverside, CA 92521-0425                       Richardson, TX 75083
USA                                            USA

Phone: (909) 787-6374                         Phone : (972) 684-5399
Fax:   (909) 787-3188                         Fax   : (972) 684-3775
E-mail: tripathi@engr.ucr.edu                 E-mail: kbasu@nortelnetworks.com

-------------------------------------------------------------------------
IMPORTANT DATES:

     Paper Submissions Deadline:        April 25, 2000
     Acceptance Notification:           June 1, 2000
     Camera-ready Manuscripts:          June 15, 2000
     Workshop                           August 11, 2000
-------------------------------------------------------------------------

SCOPE:
Over the last decade there has been a rapid growth of wireless
communication technology. Voice communication using cellular phones has
matured and become a significant part of our life today. In the recent
past, the emergence of portable computing devices such as notebook
computers and personal digital assistants have led to the opportunity
of such services as electronic mail, fax and calendar/diary programs
being provided to mobile or roving users. Observing this trend, it can
be predicted that the traffic over next generation, high-speed wireless
networks will be dominated by personal multimedia applications such as
video/news-on-demand, telemetry services, traveler information systems,
WWW browsing, and so on.

        The 3rd Generation Wireless activities are focused through the effort
of UMTS and IMT-2000 are considering the ATM technologies for the network
implementation. The recent activities at 3GIP forum is actively considering
the use of IP technology for the future wireless network. The wideband
wireless network using IP technology is becoming an important industry issue
and the seamless integration of the wireless standards and wireless IP and
mobility standard are necessary to create this future network. The role of
the different IP technologies like SIP, HTML, XML, Netmeeting for wireless
and mobility are not finalized and will require considerable discussion to
obtain the resolution. Also, the wireless access techniques like Bluetooth,
WAP etc may require seamless integration to the 2.5G (GPRS) and 3G wireless
standards.

The objective of this workshop is to provide a forum for
researchers and technologists to present new ideas and contributions in
the form of technical paper, panel discussions, as well as online demos
of service applications or technology related to wireless multimedia.
The issues and challenges for the development of wireless multimedia
networks not only encompass a broad spectrum of research topics such as
quality-of-service provisioning, broadband wireless, network support,
protocols, or handover, but also involves a way to envision the evolution
of multimedia networks in the future.

TOPICS:
Technical papers and/or product demos are solicited in all areas
related to wireless multimedia and its interfaces (or co-existence) with
the conventional wireline networks. Topics include but are not limited to:

        - Third Generation Systems
- Multimedia Applications
        - Fixed or Mobile Wireless Multimedia Access
- Wireless Network Evolution
- Broadband Wireless
- Wireless ATM and Wireless IP
        - Multicasting in Wireless Services
        - Delay and Jitter Management for Multimedia Services
        - Synchronization of Multimedia Wireless services using ATM and IP
- Quality-of-Service and Admission Control
- Multimedia Network Architecture and Protocols
- Compression Techniques
- Mobility Management & Handover Issues
        - Routing
- WWW Browsing
        - Telemetry Services
        - Broadcast Data
        - Mobile Agents
-------------------------------------------------------------

SUBMISSION GUIDELINES:

All submissions will be handled electronically. Authors should E-mail
a Postscript version of their full paper to wowmom-2000@engr.ucr.edu .
This E-mail address will become available by February 15, 2000. In order
to ensure that the Postscript versions of the papers can be printed,
authors should be careful that their papers meet the following restrictions:

 - Postscript version 2 or later.
 - Fits properly on "US Letter" size paper (8.5 X 11 inches)
 - Reference only Computer Modern or standard Adobe printer fonts
   (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used
   but must be included in the Postscript file.
 - No longer than 20 pages including, pictures, tables and references.

In addition, authors should separately E-mail the title, author names
and full address, and abstract of their paper to the Program Co-Chairs:
Satish K. Tripathi at tripathi@engr.ucr.edu and Kalyan Basu at
kbasu@nortel.com. It is expected that all accepted papers will be
presented at the workshop.

The Workshop Proceedings will be published by the ACM Press. Selected papers
will be considered for publication in the ACM/Baltzer WINET and MONET journals.
(WoWMoM'99 and WoWMoM'98 proceedings are available on the ACM digital library.)

TECHNICAL PROGRAM COMMITTEE

   * Azzedine Boukerche (Univ of North Texas, USA)
   * Pravin Bhagwat (IBM Watson Research Center, USA)
   * Andrew Campbell (Columbia Univ, USA)
   * Yanghee Choi (Seoul National Univ, Korea)
   * K.-C. Chua (National University of Singapore)
   * Marco Conti (CNUCE, Pisa, Italy)
   * Subir Das (Telcordia Technologies, USA)
   * Lorenzo Donatiello (Univ of Bologna, Italy)
   * Anthony Joseph (UC Berkeley, USA)
   * Anurag Kumar (Indian Inst of Science, Bangalore)
   * Mohan Kumar (Curtin Univ, Perth, Australia)
   * Giri Mandyam (Nokia Research, Irving, USA)
   * Hiroyuki Morikawa (University of Tokyo, Japan)
   * S. Muthukrishnan (At&T Research)
   * Raja Neogi (Intel, Portland, USA)
   * Venkat Padmanabhan (Microsoft Research, USA)
   * Vasant Prabhu (Univ of Texas at Arlington, USA)
   * Jason Redi (BBN Technologies, USA)
   * Sumit Roy (Univ of Washington, USA)
   * Sanjoy Sen (Nortel Networks, USA)
   * Krishna Sivalingam (Washington State Univ, USA)
   * Mani Srivastava (Univ of California at Los Angeles, USA)
   * Violet Syrotiuk (Univ of Texas at Dallas, USA)
   * Philip Whiting (Lucent/Bell Labs, USA)


STEERING COMMITTEE

   * Prathima Agrawal (Telcordia)
   * Ian Akyildiz (Georgia Institute of Technology)
   * Kalyan Basu (Nortel Networks)
   * Maurizio Bonuccelli (University of Pisa)
   * Imrich Chlamtac (University of Texas at Dallas)
   * Sajal K. Das (Univ of Texas at Arlington)
   * Randy Katz (University of California at Berkeley)
   * Mahmoud Naghshineh (IBM Watson Research)
   * Christopher Rose (Rutgers University)
   * Mischa Schwartz (Columbia University)
   * Satish Tripathi (University of California at Riverside)

FINANCE CHAIR

  * Tom Jacob, University of North Texas

PUBLICITY CO-CHAIRS

  * Dhawal Moghe, Nortel Networks
  * Ramesh Yerraballi, Univ of Texas at Arlington
  * Claude Castelluccia, INRIA Rhone-Alpes
  * Amitava Mukherjee, Pricewaterhouse Coopers Ltd.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 05:22:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28692
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 05:22:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15FE5AF0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 5:17:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 99818 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 05:15:44
          -0500
Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D71A0B40@standards.nortelnetworks.com>; Thu, 23 Mar 2000 5:15:44
          -0500
Received: from gdommety-pc2 (tokyo-dhcp250.cisco.com [144.254.169.252]) by
          omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id
          CAA20865; Thu, 23 Mar 2000 02:19:40 -0800 (PST)
X-Sender: gdommety@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200003231019.CAA20865@omega.cisco.com>
Date:         Thu, 23 Mar 2000 02:33:04 -0800
Reply-To: Gopal Dommety <gdommety@CISCO.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Gopal Dommety <gdommety@CISCO.COM>
Subject:      Re: [MOBILE-IP] Anchor Handoff Draft
X-To:         Gabriel Montenegro <gab@eng.sun.com>, sarikaya@U-AIZU.AC.JP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <Roam.SIMC.2.0.6.953746599.19514.gab@eng.sun.com>

Hello Behcet and Gabriel:

        I agree with you that something like realm is a good choice for Zone ID. For example Zone1.cisco.com and Zone2.cisco.com could be two different
Zone IDs.   I was also thinking about the possibility of  overlapping zones so that a type of softhandoff is always possible. So, when you are in an overlapping area
you can perform a local registration with the current achor in the old zone while trying to perform a global reg in the new zone.

Thanks
Gopal


At 09:36 AM 22/03/00 -0800, Gabriel Montenegro wrote:
>"Behcet Sarikaya" <sarikaya@U-AIZU.AC.JP> said:
>> Hello Gopal,
>>   In your anchor handoff draft RFC, you propose to use zone IDs to be
>> advertised
>> by FAs so that MNs can detect the change of the zone.
>>   In the draft RFC on regional registration (reg-tunnel-02), FAs should
>> include their NAIs
>> in the agent advertisements using FA NAI extension.
>>   While NAI has a well defined structure, and zone ID does not seem to
>> be well defined
>> however as a concept the zone ID could be better than NAI which was
>> defined to identify persons.
>>   What do you think?
>
>this is exactly right, the nai is not quite what we want. but
>the nai includes the definition of a "realm". in some recent emails
>to the list i suggested extending the "realm" definition in
>the nai (rfc2486) via the following:
>
>the ABNF for a "realm indicator" (ri) could simply be:
>
>   realm-indicator  = realm / "."
>
>   realm            = <from network access identifier (rfc2486)>
>
>network elements would advertise realm indicators, not complete
>nai's. for more details, please refer to the attached msgs.
>what do you think?
>
>tnx,
>
>-gabriel
>
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 11:12:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02597
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 11:12:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E01E6E80@standards.nortelnetworks.com>; Thu, 23 Mar 2000 11:06:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 99994 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 11:05:27
          -0500
Received: from crufty.research.bell-labs.com (204.178.16.49) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B1C1FE30@standards.nortelnetworks.com>; Thu, 23 Mar 2000
          11:05:27 -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu
          Mar 23 11:09:22 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Thu Mar
          23 11:09:21 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 5E8BB57042; Thu, 23 Mar 2000 10:09:20 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200003202116.PAA06406@dolce.cig.mot.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000323160920.5E8BB57042@king.research.bell-labs.com>
Date:         Thu, 23 Mar 2000 10:09:20 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@CIG.MOT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003202116.PAA06406@dolce.cig.mot.com>
Content-Transfer-Encoding: 7bit

Hi, Ajoy,

Is there any convincing evidence (simulation results, analysis) that
says flow control is really needed over the R-P interface?  In the
absence of such evidence I am really skeptical about putting such
details in - remember the whole debacle that L2TP got into with flow
control (it was eventually removed from L2TP).

I would hope that any congestion can be taken care of by higher-layer
backoff or admission control mechanisms.  Adding flow control to R-P
really adds a lot of complexity that I think is unnecessary and will
slow down standardization and deployment of RNNs and PDSNs.  Also, if
the R-P interface ever evolves to carry IP packets instead of the
octet stream for PPP, the flow control will be quite redundant.

If you really think that some kind of flow control is necessary then
you can always put a buffer in the RNN, since the wireless physical
link is really terminated there (in fact there is such a buffer
already in the RNN for RLP).  I don't think propagating the flow
control back to the PDSN makes sense.

-Pete


Ajoy Singh <singhak@CIG.MOT.COM> (AS) writes:

AS> Hello All,
AS> Here is the initial draft of the flow control extension for RP
AS> interface. Lately we have been doing some work and it seems, it is
AS> useful to have flow control for RP interface. We would like to have your
AS> comments and suggestion for improvement for the attached document.
AS> regards,


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 11:25:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08463
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 11:25:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2B17C60@standards.nortelnetworks.com>; Thu, 23 Mar 2000 11:19:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100032 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 11:19:10
          -0500
Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9C7D9640@standards.nortelnetworks.com>; Thu, 23 Mar 2000
          11:19:10 -0500
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA05578
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 23 Mar 2000
          11:23:47 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id LAA05569 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 23 Mar 2000 11:23:46 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <GXMK5T9Q>; Thu, 23 Mar 2000 16:23:45 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876AD1@en0060exch001u.uk.lucent.com>
Date:         Thu, 23 Mar 2000 16:23:44 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> you can always put a buffer in the RNN, since the wireless physical
> link is really terminated there (in fact there is such a buffer
> already in the RNN for RLP).
>
In fact 3GPP does exactly so (buffers in the RNC and no flow control between
the RNC and the SGSN).

alessio

PS Sorry to pollute the MIP list with this kind of discussion,
   but this is necessary in this case.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 13:33:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23779
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 13:33:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E2A0FB0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:26:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100322 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 13:24:29
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1DFC9E30@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:24:29
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate.mot.com (motgate 2.1) with ESMTP id LAA00351; Thu, 23 Mar
          2000 11:29:05 -0700 (MST)]
Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by
          mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA10615; Thu, 23 Mar
          2000 11:29:05 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay2.cig.mot.com
          (8.9.0/SCERG-RELAY-1.11b) with ESMTP id MAA24263; Thu, 23 Mar 2000
          12:29:03 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id MAA19027; Thu, 23 Mar 2000 12:29:03 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003202116.PAA06406@dolce.cig.mot.com>
            <200003231614.KAA17188@dolce.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003231829.MAA19027@dolce.cig.mot.com>
Date:         Thu, 23 Mar 2000 11:43:39 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Pete,
Thanks for your reply. Please read the embedded reply.
regards,
ajoy

Pete McCann wrote:

> Hi, Ajoy,
>
> Is there any convincing evidence (simulation results, analysis) that
> says flow control is really needed over the R-P interface?  In the
> absence of such evidence I am really skeptical about putting such
> details in - remember the whole debacle that L2TP got into with flow
> control (it was eventually removed from L2TP).

I do not have any simulation results with me that i can send to you. But we have
observed this problem in prototype 3G system and we have alleviated this by
using  ON/OFF based flow control mechanism.  The main idea of this draft is to
provide PDSN with some feedback mechanism which can be used to drop packets
before doing any compression. This is usefull for payload and header compression
case. Moreover we are trying to say this is a optional feature and which can be
used in case we need to support PPP type of  payload/header compression
otherwise do not need to bother about flow control.

>
>
> I would hope that any congestion can be taken care of by higher-layer
> backoff or admission control mechanisms.
>

BTW congestion control mechanism of TCP is also being challenged in case of
wireless link.

|Adding flow control to R-P really adds a lot of complexity that I think is
unnecessary and will
| slow down standardization and deployment of RNNs and PDSNs.

Yes adding sliding window flow control apprach might add complexity but adding
ON/OFF flow control seems to be very simple to implement.  Moreover suggested
flow control mechanism is optional feature and i do not see how this is going to
complicate implementation of RP interface.

|Also, if the R-P interface ever evolves to carry IP packets instead of the
|octet stream for PPP, the flow control will be quite redundant.

I do no know about any such plan, so i would rather not comment about this. But
are you talking to use SLIP like mechanism ?  If we assume RF link  same as
serial link we can use existing compression mechanism in this case ?  Comments ?

>
> If you really think that some kind of flow control is necessary then
> you can always put a buffer in the RNN, since the wireless physical
> link is really terminated there (in fact there is such a buffer
> already in the RNN for RLP).  I don't think propagating the flow
> control back to the PDSN makes sense.
>

I do not believe that any congestion can be taken care by providng buffering.
Buffering delays the congestion does not fix it , unless end to end feedback
mechanism is povided.  Comments ?

>
> -Pete
>
> Ajoy Singh <singhak@CIG.MOT.COM> (AS) writes:
>
> AS> Hello All,
> AS> Here is the initial draft of the flow control extension for RP
> AS> interface. Lately we have been doing some work and it seems, it is
> AS> useful to have flow control for RP interface. We would like to have your
> AS> comments and suggestion for improvement for the attached document.
> AS> regards,


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 14:10:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08836
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 14:10:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D62CC570@standards.nortelnetworks.com>; Thu, 23 Mar 2000 14:05:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100428 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 14:03:44
          -0500
Received: from hoemail2.firewall.lucent.com (192.11.226.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.99CC1360@standards.nortelnetworks.com>; Thu, 23 Mar 2000
          14:03:44 -0500
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA22661
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 23 Mar 2000
          14:08:21 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id OAA22647 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 23 Mar 2000 14:08:20 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <GXMK5YP3>; Thu, 23 Mar 2000 19:08:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876AD6@en0060exch001u.uk.lucent.com>
Date:         Thu, 23 Mar 2000 19:08:07 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@CIG.MOT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> I do not believe that any congestion can be taken care by providng
> buffering.
> Buffering delays the congestion does not fix it , unless end to end
> feedback
> mechanism is povided.  Comments ?
>
>
I comment that your mechanism just moves the congestion to the PDSN, If I
understand your proposal. How do you solve the problem
of congestion in the PDSN, missing an end to end feedback?

The best I can see one can do, in IP networks, is to actively manage buffers
(RED, LQD+WFQ and drop from front ...). There's ECN to be used
experimentally, but that is anyway ultimately relying on some active queue
management augmented with ECN capability.

there's a dangerous slip into transport issue here... are we supposed to do
that here?

alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 14:54:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24720
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 14:54:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DBF39870@standards.nortelnetworks.com>; Thu, 23 Mar 2000 14:48:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100508 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 14:47:27
          -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B4CC66F0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 14:47:26
          -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Mar
          23 14:50:40 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Thu Mar
          23 14:50:39 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 84B9557042; Thu, 23 Mar 2000 13:50:38 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <200003202116.PAA06406@dolce.cig.mot.com>
            <200003231614.KAA17188@dolce.cig.mot.com>
            <200003231829.MAA19027@dolce.cig.mot.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000323195038.84B9557042@king.research.bell-labs.com>
Date:         Thu, 23 Mar 2000 13:50:38 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@cig.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200003231829.MAA19027@dolce.cig.mot.com>
Content-Transfer-Encoding: 7bit

Hi, Ajoy,

A few comments below.

Ajoy Singh <singhak@cig.mot.com> (AS) writes:

AS> I do not have any simulation results with me that i can send to
AS> you. But we have observed this problem in prototype 3G system and
AS> we have alleviated this by using ON/OFF based flow control
AS> mechanism.  The main idea of this draft is to provide PDSN with
AS> some feedback mechanism which can be used to drop packets before
AS> doing any compression. This is usefull for payload and header
AS> compression case. Moreover we are trying to say this is a optional
AS> feature and which can be used in case we need to support PPP type
AS> of payload/header compression otherwise do not need to bother
AS> about flow control.

Are you familiar with the role of RLP (the Radio Link Protocol) in a
cellular network?  It seems to me that you are duplicating some of
that functionality.  Did your prototype system take RLP into account?
Did it employ TCP-level flow control?

>> I would hope that any congestion can be taken care of by higher-layer
>> backoff or admission control mechanisms.

AS> BTW congestion control mechanism of TCP is also being challenged
AS> in case of wireless link.

Yes, but only because TCP confuses packet loss with congestion.  If we
have RLP to fix the packet loss, then TCP can handle congestion
end-to-end.

>> Adding flow control to R-P really adds a lot of complexity that I
>> think is unnecessary and will slow down standardization and
>> deployment of RNNs and PDSNs.

AS> Yes adding sliding window flow control apprach might add
AS> complexity but adding ON/OFF flow control seems to be very simple
AS> to implement.  Moreover suggested flow control mechanism is
AS> optional feature and i do not see how this is going to complicate
AS> implementation of RP interface.

Well, even though it would be optional depending on the connection
type you are still requiring vendors to implement and support it.
There will be a delay both in standardization and implementation.

>> Also, if the R-P interface ever evolves to carry IP packets instead of the
>> octet stream for PPP, the flow control will be quite redundant.

AS> I do no know about any such plan, so i would rather not comment
AS> about this. But are you talking to use SLIP like mechanism ?  If
AS> we assume RF link same as serial link we can use existing
AS> compression mechanism in this case ?  Comments ?

I was talking about one potential evolution step for 3G wireless data
that was discussed during development of the R-P interface document.
Right now the R-P interface is assumed to carry the PPP octet stream,
but it is flexible enough to carry encapsulated IP packets in the
future.  In that case the data link would be terminated in the RNN and
there would be no need to do the kind of buffering and flow control
you are talking about - the whole network between the RNN and PDSN
would be (encapsulated) IP traffic.  IP does not have or need flow
control between routers.

>> If you really think that some kind of flow control is necessary then
>> you can always put a buffer in the RNN, since the wireless physical
>> link is really terminated there (in fact there is such a buffer
>> already in the RNN for RLP).  I don't think propagating the flow
>> control back to the PDSN makes sense.

AS> I do not believe that any congestion can be taken care by providng
AS> buffering.  Buffering delays the congestion does not fix it ,
AS> unless end to end feedback mechanism is povided.  Comments ?

Exactly my point - you are not doing end-to-end flow control either.
You are stopping in the PDSN, which means (I assume) that packets are
buffered there until the RNN tells the PDSN it's OK to transmit them.
This buffer can overflow as well unless there is a truly end-to-end
congestion control scheme - that scheme today is TCP and in the future
(for voice-over-IP) it is admission control based on RSVP or some
other request/response protocol.  The R-P link is just one hop in a
larger end-to-end picture.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 15:02:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27525
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 15:02:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB8414C0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 14:56:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100546 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 14:55:11
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C99D9350@standards.nortelnetworks.com>; Thu, 23 Mar 2000 14:55:11
          -0500
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id MAA28064; Thu, 23 Mar
          2000 12:59:43 -0700 (MST)]
Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by
          mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA21014; Thu, 23 Mar
          2000 12:59:43 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay2.cig.mot.com
          (8.9.0/SCERG-RELAY-1.11b) with ESMTP id NAA07314; Thu, 23 Mar 2000
          13:59:42 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id NAA20385; Thu, 23 Mar 2000 13:59:42 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003231908.NAA19498@dolce.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003231959.NAA20385@dolce.cig.mot.com>
Date:         Thu, 23 Mar 2000 13:14:18 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         "Casati, Alessio (Alessio)" <acasati@lucent.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Casati, Alessio (Alessio)" wrote:

> > I do not believe that any congestion can be taken care by providng
> > buffering.
> > Buffering delays the congestion does not fix it , unless end to end
> > feedback
> > mechanism is povided.  Comments ?
> >
> >
> I comment that your mechanism just moves the congestion to the PDSN, If I
> understand your proposal. How do you solve the problem
> of congestion in the PDSN, missing an end to end feedback?
>

Yes this just moves congestion to PDSN.  But just look at the following points.

1. PDSN can drop packets before doing compression.

2. The dropping of one LZW compressed frame at RNN can cause mobile station to
drop all compressed packets of the compression window. So dropping packet at RNN
means, we have to send some frames over air interface which will be dropped
eventually at mobile station.  This is not desirable as we are wasting RF
resources for nothing.

3. Moreover R-P interface tunnels octet stream so RNN might be not able to make
efficient dropping mechanism, unless we say that  GRE packet  encapsulates
complete PPP frame. I do not remember reading any such thing in RP document.
Correct me in case i missed it. RNN might end up dropping some thing which just
contain PPP  frame boundary.  In this case incomplete PPP frame will cause CRC
errors at mobile station.  We do not want to send something over SCH, which we
know is going to be erased by mobile station. Note in case of L2TP framing is
done at LAC, so such problem does not exist.

regards,
ajoy

>
> The best I can see one can do, in IP networks, is to actively manage buffers
> (RED, LQD+WFQ and drop from front ...). There's ECN to be used
> experimentally, but that is anyway ultimately relying on some active queue
> management augmented with ECN capability.
>
> there's a dangerous slip into transport issue here... are we supposed to do
> that here?
>
> alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 15:51:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15958
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 15:51:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6171230@standards.nortelnetworks.com>; Thu, 23 Mar 2000 15:45:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 100600 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 15:44:11
          -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A1FB8850@standards.nortelnetworks.com>; Thu, 23 Mar 2000
          15:44:11 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA22913
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 23 Mar 2000
          15:48:48 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id PAA22898 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 23 Mar 2000 15:48:47 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <GXMK5ZXL>; Thu, 23 Mar 2000 20:48:46 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876ADA@en0060exch001u.uk.lucent.com>
Date:         Thu, 23 Mar 2000 20:48:46 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@cig.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Ajoy,

these considerations are very interesting.

> Yes this just moves congestion to PDSN.  But just look at the following
> points.
>
> 1. PDSN can drop packets before doing compression.
>
This is a laudable goal. Have you an estimate of
the impact of saving compression in (transient) congestion condition?
I assume that there are some compression processing resources that are
reserved, not to starve flows in case there happens to be
no congestion, right?
This appears not to be a big plus on its own right.


> 2. The dropping of one LZW compressed frame at RNN can cause mobile
> station to
> drop all compressed packets of the compression window. So dropping packet
> at RNN
> means, we have to send some frames over air interface which will be
> dropped
> eventually at mobile station.  This is not desirable as we are wasting RF
> resources for nothing.
>
This is a laudable goal. But I start to question the merits of the choice
that lead to have a PDSN handling the link layer and compression if the one
you describe is a significant problem due to that choice. The 3GPP
architecture is superior from this respect. And also some proposals that are
aiming at not having link layer terminated at the PDSN should be seriously
considered, I would guess.
Anyway, I'm not going to stir the pot further on this, since
I was (and I am) not involved in the dicussion on R-P and I may be missing
something.

> 3. Moreover R-P interface tunnels octet stream so RNN might be not able to
> make
> efficient dropping mechanism, unless we say that  GRE packet  encapsulates
> complete PPP frame. I do not remember reading any such thing in RP
> document.
> Correct me in case i missed it. RNN might end up dropping some thing which
> just
> contain PPP  frame boundary.  In this case incomplete PPP frame will cause
> CRC
> errors at mobile station.  We do not want to send something over SCH,
> which we
> know is going to be erased by mobile station. Note in case of L2TP framing
> is
> done at LAC, so such problem does not exist.
>
This is not a so laudable thing. I hope you are not going to
send incomplete PPP frames encapsulated in any protocol used over the R-P
(the system would start to suck quite a lot).

alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 19:10:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22259
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 19:10:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6B1BE60@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:05:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101001 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 19:03:41
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.80F025A0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:03:41
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id RAA19018; Thu, 23 Mar
          2000 17:08:19 -0700 (MST)]
Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA05795; Thu, 23 Mar
          2000 17:08:18 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay2.cig.mot.com
          (8.9.0/SCERG-RELAY-1.11b) with ESMTP id SAA08987; Thu, 23 Mar 2000
          18:08:18 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id SAA25983; Thu, 23 Mar 2000 18:08:17 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003202116.PAA06406@dolce.cig.mot.com>
            <200003231614.KAA17188@dolce.cig.mot.com>
            <200003231829.MAA19027@dolce.cig.mot.com>
            <200003231955.NAA20326@dolce.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003240008.SAA25983@dolce.cig.mot.com>
Date:         Thu, 23 Mar 2000 17:22:52 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pete,
Please see the embedded reply.
regards,
ajoy

Pete McCann wrote:

> Hi, Ajoy,
>
> A few comments below.
>
> Ajoy Singh <singhak@cig.mot.com> (AS) writes:
>
> AS> I do not have any simulation results with me that i can send to
> AS> you. But we have observed this problem in prototype 3G system and
> AS> we have alleviated this by using ON/OFF based flow control
> AS> mechanism.  The main idea of this draft is to provide PDSN with
> AS> some feedback mechanism which can be used to drop packets before
> AS> doing any compression. This is usefull for payload and header
> AS> compression case. Moreover we are trying to say this is a optional
> AS> feature and which can be used in case we need to support PPP type
> AS> of payload/header compression otherwise do not need to bother
> AS> about flow control.
>
> Are you familiar with the role of RLP (the Radio Link Protocol) in a
> cellular network?  It seems to me that you are duplicating some of
> that functionality.  Did your prototype system take RLP into account?
> Did it employ TCP-level flow control?
>

Matter of fact i have implemented IS-707 RLP code. So i do not know what RLP has
to do with this contribution. We are just arguing about some thing different.
The point here is to move congestion from RNN to PDSN so that RNN does not need
to build such mechanism of discarding packets. Just treat RF link as serial link
rather any anything else.  You might be aware that in case of modem some flow
control is built in modem and RAS drops packets before sending to modem.
Comments ?

>
> >> I would hope that any congestion can be taken care of by higher-layer
> >> backoff or admission control mechanisms.
>
> AS> BTW congestion control mechanism of TCP is also being challenged
> AS> in case of wireless link.
>
> Yes, but only because TCP confuses packet loss with congestion.  If we
> have RLP to fix the packet loss, then TCP can handle congestion
> end-to-end.
>
> >> Adding flow control to R-P really adds a lot of complexity that I
> >> think is unnecessary and will slow down standardization and
> >> deployment of RNNs and PDSNs.
>
> AS> Yes adding sliding window flow control apprach might add
> AS> complexity but adding ON/OFF flow control seems to be very simple
> AS> to implement.  Moreover suggested flow control mechanism is
> AS> optional feature and i do not see how this is going to complicate
> AS> implementation of RP interface.
>
> Well, even though it would be optional depending on the connection
> type you are still requiring vendors to implement and support it.
> There will be a delay both in standardization and implementation.

This will work even if PDSN does not support flow control as RNN does not do flow
control when it does not receive flow control extension in Registration Reply
message.

>
>
> >> Also, if the R-P interface ever evolves to carry IP packets instead of the
> >> octet stream for PPP, the flow control will be quite redundant.
>
> AS> I do no know about any such plan, so i would rather not comment
> AS> about this. But are you talking to use SLIP like mechanism ?  If
> AS> we assume RF link same as serial link we can use existing
> AS> compression mechanism in this case ?  Comments ?
>
> I was talking about one potential evolution step for 3G wireless data
> that was discussed during development of the R-P interface document.
> Right now the R-P interface is assumed to carry the PPP octet stream,
> but it is flexible enough to carry encapsulated IP packets in the
> future.  In that case the data link would be terminated in the RNN and
> there would be no need to do the kind of buffering and flow control
> you are talking about - the whole network between the RNN and PDSN
> would be (encapsulated) IP traffic.  IP does not have or need flow
> control between routers.
>
> >> If you really think that some kind of flow control is necessary then
> >> you can always put a buffer in the RNN, since the wireless physical
> >> link is really terminated there (in fact there is such a buffer
> >> already in the RNN for RLP).  I don't think propagating the flow
> >> control back to the PDSN makes sense.
>
> AS> I do not believe that any congestion can be taken care by providng
> AS> buffering.  Buffering delays the congestion does not fix it ,
> AS> unless end to end feedback mechanism is povided.  Comments ?
>
> Exactly my point - you are not doing end-to-end flow control either.
> You are stopping in the PDSN, which means (I assume) that packets are
> buffered there until the RNN tells the PDSN it's OK to transmit them.
> This buffer can overflow as well unless there is a truly end-to-end
> congestion control scheme - that scheme today is TCP and in the future
> (for voice-over-IP) it is admission control based on RSVP or some
> other request/response protocol.  The R-P link is just one hop in a
> larger end-to-end picture.
>

I think i have talked about this in my previous replies.

>
> -Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 19:24:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26699
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 19:24:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE6B24B0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:19:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101064 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 19:18:34
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.94BDF650@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:18:33
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA06959; Thu, 23 Mar 2000
          17:23:11 -0700 (MST)]
Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by
          pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA22377; Thu, 23 Mar
          2000 17:23:11 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay1.cig.mot.com
          (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id SAA14311; Thu, 23 Mar
          2000 18:23:05 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id SAA26170; Thu, 23 Mar 2000 18:23:09 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003232053.OAA21227@dolce.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003240023.SAA26170@dolce.cig.mot.com>
Date:         Thu, 23 Mar 2000 17:37:44 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Alessio,
Thanks for your comment buit still i do not understand some of  your comments.
Can you explain this in more detail ?
regards,
ajoy

"Casati, Alessio (Alessio)" wrote:

> Ajoy,
>
> these considerations are very interesting.
>
> > Yes this just moves congestion to PDSN.  But just look at the following
> > points.
> >
> > 1. PDSN can drop packets before doing compression.
> >
> This is a laudable goal. Have you an estimate of
> the impact of saving compression in (transient) congestion condition?
> I assume that there are some compression processing resources that are
> reserved, not to starve flows in case there happens to be
> no congestion, right?
> This appears not to be a big plus on its own right.

I do not have any exact figure about this right now.   Can you explain this
problem in more detail as i do not see any thing here which is a problem ?

>
>
> > 2. The dropping of one LZW compressed frame at RNN can cause mobile
> > station to
> > drop all compressed packets of the compression window. So dropping packet
> > at RNN
> > means, we have to send some frames over air interface which will be
> > dropped
> > eventually at mobile station.  This is not desirable as we are wasting RF
> > resources for nothing.
> >
> This is a laudable goal. But I start to question the merits of the choice
> that lead to have a PDSN handling the link layer and compression if the one
> you describe is a significant problem due to that choice. The 3GPP
> architecture is superior from this respect. And also some proposals that are
> aiming at not having link layer terminated at the PDSN should be seriously
> considered, I would guess.
> Anyway, I'm not going to stir the pot further on this, since
> I was (and I am) not involved in the dicussion on R-P and I may be missing
> something.
>

Well i do not think this is a architectural issue in 3GPPP2. I believe it is
perfectly all right to terminate PPP at PDSN and RF at RNN. This makes more
business sense as PDSN is something which is implemented by data communication
companies and RNN is something which is implemented by Cellular Vendors.  So why
should we mix them up. Moreover, if you terminating PPP at PDSN it will be mess
to implement PPP compression mechanism at RNN.  I would guess we will be better
off not suggestion any such thing. Comments ?

>
> > 3. Moreover R-P interface tunnels octet stream so RNN might be not able to
> > make
> > efficient dropping mechanism, unless we say that  GRE packet  encapsulates
> > complete PPP frame. I do not remember reading any such thing in RP
> > document.
> > Correct me in case i missed it. RNN might end up dropping some thing which
> > just
> > contain PPP  frame boundary.  In this case incomplete PPP frame will cause
> > CRC
> > errors at mobile station.  We do not want to send something over SCH,
> > which we
> > know is going to be erased by mobile station. Note in case of L2TP framing
> > is
> > done at LAC, so such problem does not exist.
> >
> This is not a so laudable thing. I hope you are not going to
> send incomplete PPP frames encapsulated in any protocol used over the R-P
> (the system would start to suck quite a lot)

>
>
> alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 23 19:26:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27398
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 23 Mar 2000 19:26:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7F4ACA0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:21:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101097 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 19:21:13
          -0500
Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F3FF5690@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:21:13
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate.mot.com (motgate 2.1) with ESMTP id RAA08044; Thu, 23 Mar
          2000 17:25:51 -0700 (MST)]
Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA15291; Thu, 23 Mar
          2000 17:25:51 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay1.cig.mot.com
          (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id SAA15718; Thu, 23 Mar
          2000 18:25:45 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id SAA26215; Thu, 23 Mar 2000 18:25:49 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003202116.PAA06406@dolce.cig.mot.com>
            <200003231614.KAA17188@dolce.cig.mot.com>
            <200003231829.MAA19027@dolce.cig.mot.com>
            <200003231955.NAA20326@dolce.cig.mot.com>
            <38DAA74C.8B2CF485@cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003240025.SAA26215@dolce.cig.mot.com>
Date:         Thu, 23 Mar 2000 17:40:24 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I was talking about one potential evolution step for 3G wireless data
> that was discussed during development of the R-P interface document.
> Right now the R-P interface is assumed to carry the PPP octet stream,
> but it is flexible enough to carry encapsulated IP packets in the
> future.  In that case the data link would be terminated in the RNN and
> there would be no need to do the kind of buffering and flow control
> you are talking about - the whole network between the RNN and PDSN
> would be (encapsulated) IP traffic.  IP does not have or need flow
> control between routers.
>
Let us talk about the current problem. You are absolutely right when thing changes
some of this will not make much sense.

Ajoy Singh wrote:

> Pete,
> Please see the embedded reply.
> regards,
> ajoy
>
> Pete McCann wrote:
>
> > Hi, Ajoy,
> >
> > A few comments below.
> >
> > Ajoy Singh <singhak@cig.mot.com> (AS) writes:
> >
> > AS> I do not have any simulation results with me that i can send to
> > AS> you. But we have observed this problem in prototype 3G system and
> > AS> we have alleviated this by using ON/OFF based flow control
> > AS> mechanism.  The main idea of this draft is to provide PDSN with
> > AS> some feedback mechanism which can be used to drop packets before
> > AS> doing any compression. This is usefull for payload and header
> > AS> compression case. Moreover we are trying to say this is a optional
> > AS> feature and which can be used in case we need to support PPP type
> > AS> of payload/header compression otherwise do not need to bother
> > AS> about flow control.
> >
> > Are you familiar with the role of RLP (the Radio Link Protocol) in a
> > cellular network?  It seems to me that you are duplicating some of
> > that functionality.  Did your prototype system take RLP into account?
> > Did it employ TCP-level flow control?
> >
>
> Matter of fact i have implemented IS-707 RLP code. So i do not know what RLP has
> to do with this contribution. We are just arguing about some thing different.
> The point here is to move congestion from RNN to PDSN so that RNN does not need
> to build such mechanism of discarding packets. Just treat RF link as serial link
> rather any anything else.  You might be aware that in case of modem some flow
> control is built in modem and RAS drops packets before sending to modem.
> Comments ?
>
> >
> > >> I would hope that any congestion can be taken care of by higher-layer
> > >> backoff or admission control mechanisms.
> >
> > AS> BTW congestion control mechanism of TCP is also being challenged
> > AS> in case of wireless link.
> >
> > Yes, but only because TCP confuses packet loss with congestion.  If we
> > have RLP to fix the packet loss, then TCP can handle congestion
> > end-to-end.
> >
> > >> Adding flow control to R-P really adds a lot of complexity that I
> > >> think is unnecessary and will slow down standardization and
> > >> deployment of RNNs and PDSNs.
> >
> > AS> Yes adding sliding window flow control apprach might add
> > AS> complexity but adding ON/OFF flow control seems to be very simple
> > AS> to implement.  Moreover suggested flow control mechanism is
> > AS> optional feature and i do not see how this is going to complicate
> > AS> implementation of RP interface.
> >
> > Well, even though it would be optional depending on the connection
> > type you are still requiring vendors to implement and support it.
> > There will be a delay both in standardization and implementation.
>
> This will work even if PDSN does not support flow control as RNN does not do flow
> control when it does not receive flow control extension in Registration Reply
> message.
>
> >
> >
> > >> Also, if the R-P interface ever evolves to carry IP packets instead of the
> > >> octet stream for PPP, the flow control will be quite redundant.
> >
> > AS> I do no know about any such plan, so i would rather not comment
> > AS> about this. But are you talking to use SLIP like mechanism ?  If
> > AS> we assume RF link same as serial link we can use existing
> > AS> compression mechanism in this case ?  Comments ?
> >
> > I was talking about one potential evolution step for 3G wireless data
> > that was discussed during development of the R-P interface document.
> > Right now the R-P interface is assumed to carry the PPP octet stream,
> > but it is flexible enough to carry encapsulated IP packets in the
> > future.  In that case the data link would be terminated in the RNN and
> > there would be no need to do the kind of buffering and flow control
> > you are talking about - the whole network between the RNN and PDSN
> > would be (encapsulated) IP traffic.  IP does not have or need flow
> > control between routers.
> >
> > >> If you really think that some kind of flow control is necessary then
> > >> you can always put a buffer in the RNN, since the wireless physical
> > >> link is really terminated there (in fact there is such a buffer
> > >> already in the RNN for RLP).  I don't think propagating the flow
> > >> control back to the PDSN makes sense.
> >
> > AS> I do not believe that any congestion can be taken care by providng
> > AS> buffering.  Buffering delays the congestion does not fix it ,
> > AS> unless end to end feedback mechanism is povided.  Comments ?
> >
> > Exactly my point - you are not doing end-to-end flow control either.
> > You are stopping in the PDSN, which means (I assume) that packets are
> > buffered there until the RNN tells the PDSN it's OK to transmit them.
> > This buffer can overflow as well unless there is a truly end-to-end
> > congestion control scheme - that scheme today is TCP and in the future
> > (for voice-over-IP) it is admission control based on RSVP or some
> > other request/response protocol.  The R-P link is just one hop in a
> > larger end-to-end picture.
> >
>
> I think i have talked about this in my previous replies.
>
> >
> > -Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 24 04:55:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00973
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Mar 2000 04:55:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.658C9B70@standards.nortelnetworks.com>; Fri, 24 Mar 2000 4:49:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101529 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 04:48:01
          -0500
Received: from alemail1.firewall.lucent.com (192.11.221.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.224A21C0@standards.nortelnetworks.com>; Fri, 24 Mar 2000
          4:48:01 -0500
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA21560
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 24 Mar 2000
          04:51:50 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com
          [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id EAA21507 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>;
          Fri, 24 Mar 2000 04:51:29 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service
          (5.5.2448.0) id <GXMK6D4S>; Fri, 24 Mar 2000 09:51:14 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <976F7C55E3B2D111A0720008C728549C04876ADC@en0060exch001u.uk.lucent.com>
Date:         Fri, 24 Mar 2000 09:51:11 -0000
Reply-To: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Casati, Alessio (Alessio)" <acasati@LUCENT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@cig.mot.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> > Ajoy,
> >
> > these considerations are very interesting.
> >
> > > Yes this just moves congestion to PDSN.  But just look at the
> following
> > > points.
> > >
> > > 1. PDSN can drop packets before doing compression.
> > >
> > This is a laudable goal. Have you an estimate of
> > the impact of saving compression in (transient) congestion condition?
> > I assume that there are some compression processing resources that are
> > reserved, not to starve flows in case there happens to be
> > no congestion, right?
> > This appears not to be a big plus on its own right.
>
> I do not have any exact figure about this right now.   Can you explain
> this
> problem in more detail as i do not see any thing here which is a problem ?
>
I have a problem in understanding your question. I believe
I'm not raising any problem, I'm just saying your point 1 doesn't
seem to be a compelling reason/advantage.


> >
> >
> > > 2. The dropping of one LZW compressed frame at RNN can cause mobile
> > > station to
> > > drop all compressed packets of the compression window. So dropping
> packet
> > > at RNN
> > > means, we have to send some frames over air interface which will be
> > > dropped
> > > eventually at mobile station.  This is not desirable as we are wasting
> RF
> > > resources for nothing.
> > >
> > This is a laudable goal. But I start to question the merits of the
> choice
> > that lead to have a PDSN handling the link layer and compression if the
> one
> > you describe is a significant problem due to that choice. The 3GPP
> > architecture is superior from this respect. And also some proposals that
> are
> > aiming at not having link layer terminated at the PDSN should be
> seriously
> > considered, I would guess.
> > Anyway, I'm not going to stir the pot further on this, since
> > I was (and I am) not involved in the dicussion on R-P and I may be
> missing
> > something.
> >
>
> Well i do not think this is a architectural issue in 3GPPP2. I believe it
> is
> perfectly all right to terminate PPP at PDSN and RF at RNN. This makes
> more
> business sense as PDSN is something which is implemented by data
> communication
> companies and RNN is something which is implemented by Cellular Vendors.
>
Well, In standard bodies people define open interfaces.
Generally, no implication is involved by this on who builds
what.

I'm not questioning the need for an open interface, I'm questioning whether
the problems you are trying to solve
could have been avoided with better definition of such an open interface.

If the compression problem you mention affects consitently RF
resource consumption in RNN congestion condition, and this
is expected to happen frequently, then I would state you
are trying to patch a badly designed system. This as far as good
engineering goes.

alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 24 09:57:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14608
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Mar 2000 09:57:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EED1750@standards.nortelnetworks.com>; Fri, 24 Mar 2000 9:51:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101771 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 09:49:42
          -0500
Received: from ans2-pub.dttus.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E150FF30@standards.nortelnetworks.com>; Fri, 24 Mar 2000 9:39:41
          -0500
Received: by ans2-pub.dttus.com id IAA06120 (InterLock SMTP Gateway 3.0 for
          mobile-ip@standards.nortelnetworks.com); Fri, 24 Mar 2000 08:44:20
          -0600
Received: by ans2-pub.dttus.com (Internal Mail Agent-3); Fri, 24 Mar 2000
          08:44:20 -0600
X400-Received: by ans2-pub.dttus.com (Internal Mail Agent-2); Fri, 24 Mar 2000
               08:44:20 -0600
X400-Received: by ans2-pub.dttus.com (Internal Mail Agent-1); Fri, 24 Mar 2000
               08:44:20 -0600
X400-Mts-Identifier: [/c=US/admd=TeleMail/prmd=Deloitte/;
                     00FCE38DB7F0813B-MTAUSBNA1DT]
Content-Identifier: 00FCE38DB7F0813B
Content-Return: Allowed
X400-Content-Type: P2-1988 ( 22 )
Conversion: Allowed
Original-Encoded-Information-Types: IA5-Text
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: rverma@dttus.com
X400-Recipients: non-disclosure;
Message-ID:  <00FCE38DB7F0813B*/c=US/admd=TeleMail/prmd=Deloitte/o=ccMailGW/s=rverma/@MHS>
Date:         Fri, 24 Mar 2000 08:43:20 -0600
Reply-To: Rohit Verma <rverma@DTTUS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Rohit Verma <rverma@DTTUS.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         acasati@LUCENT.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

     I guess the question is not of starving flows, the point is that the
     links on either side of the RNN (Radio and PDSN) are not balanced.
     Therefore there is a situation where RNN will be unable to keep pace
     with forwarding packets from the PDSN to the Radio.
     So somewhere packets will have to be buffered or dropped. From a
     performance standpoint it will be advantageous to drop packets before
     any history specific information is added to them. This history
     specific information could be compression/encryption etc...
     The implementation of the mechanism is optional so it should be
     completely unobtrusive to systems that do not implement it.
     As packets are paced, upper layer protocols will eventually take over
     and adjust their window sizes so that there is end-to-end control.
     The proposed solution is not to replace exiting mechanisms but merely
     is a way to avoid performance degradation.

     Hope this helps
     Regards
     Rohit Verma


______________________________ Reply Separator _________________________________
Subject: Re: [MOBILE-IP] RP Flow Control
Author:  acasati@LUCENT.COM at Internet-USA
Date:    3/24/00 3:56 AM


> > Ajoy,
> >
> > these considerations are very interesting.
> >
> > > Yes this just moves congestion to PDSN.  But just look at the
> following
> > > points.
> > >
> > > 1. PDSN can drop packets before doing compression.
> > >
> > This is a laudable goal. Have you an estimate of
> > the impact of saving compression in (transient) congestion condition?
> > I assume that there are some compression processing resources that are
> > reserved, not to starve flows in case there happens to be
> > no congestion, right?
> > This appears not to be a big plus on its own right.
>
> I do not have any exact figure about this right now.   Can you explain
> this
> problem in more detail as i do not see any thing here which is a problem ?
>
I have a problem in understanding your question. I believe
I'm not raising any problem, I'm just saying your point 1 doesn't
seem to be a compelling reason/advantage.


> >
> >
> > > 2. The dropping of one LZW compressed frame at RNN can cause mobile
> > > station to
> > > drop all compressed packets of the compression window. So dropping
> packet
> > > at RNN
> > > means, we have to send some frames over air interface which will be
> > > dropped
> > > eventually at mobile station.  This is not desirable as we are wasting
> RF
> > > resources for nothing.
> > >
> > This is a laudable goal. But I start to question the merits of the
> choice
> > that lead to have a PDSN handling the link layer and compression if the
> one
> > you describe is a significant problem due to that choice. The 3GPP
> > architecture is superior from this respect. And also some proposals that
> are
> > aiming at not having link layer terminated at the PDSN should be
> seriously
> > considered, I would guess.
> > Anyway, I'm not going to stir the pot further on this, since
> > I was (and I am) not involved in the dicussion on R-P and I may be
> missing
> > something.
> >
>
> Well i do not think this is a architectural issue in 3GPPP2. I believe it
> is
> perfectly all right to terminate PPP at PDSN and RF at RNN. This makes
> more
> business sense as PDSN is something which is implemented by data
> communication
> companies and RNN is something which is implemented by Cellular Vendors.
>
Well, In standard bodies people define open interfaces.
Generally, no implication is involved by this on who builds
what.

I'm not questioning the need for an open interface, I'm questioning whether
the problems you are trying to solve
could have been avoided with better definition of such an open interface.

If the compression problem you mention affects consitently RF
resource consumption in RNN congestion condition, and this
is expected to happen frequently, then I would state you
are trying to patch a badly designed system. This as far as good
engineering goes.

alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 24 11:25:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15372
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Mar 2000 11:25:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F267CFC0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:20:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101864 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 11:18:46
          -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B86706B0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:18:46
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id KAA11736; Fri, 24 Mar 2000 10:23:20 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          862568AC.005A2CD0 ; Fri, 24 Mar 2000 10:24:57 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <862568AC.005A2BBB.00@mwgate02.mw.3com.com>
Date:         Fri, 24 Mar 2000 10:25:28 -0600
Reply-To: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Yingchun Xu <Yingchun_Xu@MW.3COM.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Ajoy Singh <singhak@CIG.MOT.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Ajoy,
RP registration and GRE frame head have a protocol ID let you specifying what
will be tunneled. If you put PPP protocol ID 0x880B,
you will be able to encapsulate the whole PPP frame.

--Yingchun.




Ajoy Singh <singhak@CIG.MOT.COM> on 03/23/2000 01:14:18 PM

Please respond to Ajoy Singh <singhak@CIG.MOT.COM>

Sent by:  Ajoy Singh <singhak@CIG.MOT.COM>


To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] RP Flow Control



"Casati, Alessio (Alessio)" wrote:

> > I do not believe that any congestion can be taken care by providng
> > buffering.
> > Buffering delays the congestion does not fix it , unless end to end
> > feedback
> > mechanism is povided.  Comments ?
> >
> >
> I comment that your mechanism just moves the congestion to the PDSN, If I
> understand your proposal. How do you solve the problem
> of congestion in the PDSN, missing an end to end feedback?
>

Yes this just moves congestion to PDSN.  But just look at the following points.

1. PDSN can drop packets before doing compression.

2. The dropping of one LZW compressed frame at RNN can cause mobile station to
drop all compressed packets of the compression window. So dropping packet at RNN
means, we have to send some frames over air interface which will be dropped
eventually at mobile station.  This is not desirable as we are wasting RF
resources for nothing.

3. Moreover R-P interface tunnels octet stream so RNN might be not able to make
efficient dropping mechanism, unless we say that  GRE packet  encapsulates
complete PPP frame. I do not remember reading any such thing in RP document.
Correct me in case i missed it. RNN might end up dropping some thing which just
contain PPP  frame boundary.  In this case incomplete PPP frame will cause CRC
errors at mobile station.  We do not want to send something over SCH, which we
know is going to be erased by mobile station. Note in case of L2TP framing is
done at LAC, so such problem does not exist.

regards,
ajoy

>
> The best I can see one can do, in IP networks, is to actively manage buffers
> (RED, LQD+WFQ and drop from front ...). There's ECN to be used
> experimentally, but that is anyway ultimately relying on some active queue
> management augmented with ECN capability.
>
> there's a dangerous slip into transport issue here... are we supposed to do
> that here?
>
> alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 24 11:50:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23743
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 24 Mar 2000 11:50:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7441AA40@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:45:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 101943 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 11:43:53
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3A7C8AA0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:43:52
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id JAA17923; Fri, 24 Mar
          2000 09:48:32 -0700 (MST)]
Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA21507; Fri, 24 Mar
          2000 09:48:32 -0700 (MST)]
Received: from dolce.cig.mot.com (dolce [136.182.254.11]) by relay1.cig.mot.com
          (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id KAA29240; Fri, 24 Mar
          2000 10:48:26 -0600 (CST)
Received: from cig.mot.com (d50-6e3b.cig.mot.com [160.44.110.59]) by
          dolce.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with
          ESMTP id KAA10837; Fri, 24 Mar 2000 10:48:31 -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <200003241639.KAA10662@dolce.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <200003241648.KAA10837@dolce.cig.mot.com>
Date:         Fri, 24 Mar 2000 10:03:00 -0600
Reply-To: Ajoy Singh <singhak@CIG.MOT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Ajoy Singh <singhak@CIG.MOT.COM>
Subject:      Re: [MOBILE-IP] RP Flow Control
X-To:         Yingchun_Xu@3com.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Thanks for clarifying this point. I thought this should be done this way. BTW still
we still have issue in case of compression which is the motivation factor of the
current draft.
regards,
ajoy

Yingchun_Xu@3com.com wrote:

> Ajoy,
> RP registration and GRE frame head have a protocol ID let you specifying what
> will be tunneled. If you put PPP protocol ID 0x880B,
> you will be able to encapsulate the whole PPP frame.
>
> --Yingchun.
>
> Ajoy Singh <singhak@CIG.MOT.COM> on 03/23/2000 01:14:18 PM
>
> Please respond to Ajoy Singh <singhak@CIG.MOT.COM>
>
> Sent by:  Ajoy Singh <singhak@CIG.MOT.COM>
>
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> cc:    (Yingchun Xu/MW/US/3Com)
> Subject:  Re: [MOBILE-IP] RP Flow Control
>
> "Casati, Alessio (Alessio)" wrote:
>
> > > I do not believe that any congestion can be taken care by providng
> > > buffering.
> > > Buffering delays the congestion does not fix it , unless end to end
> > > feedback
> > > mechanism is povided.  Comments ?
> > >
> > >
> > I comment that your mechanism just moves the congestion to the PDSN, If I
> > understand your proposal. How do you solve the problem
> > of congestion in the PDSN, missing an end to end feedback?
> >
>
> Yes this just moves congestion to PDSN.  But just look at the following points.
>
> 1. PDSN can drop packets before doing compression.
>
> 2. The dropping of one LZW compressed frame at RNN can cause mobile station to
> drop all compressed packets of the compression window. So dropping packet at RNN
> means, we have to send some frames over air interface which will be dropped
> eventually at mobile station.  This is not desirable as we are wasting RF
> resources for nothing.
>
> 3. Moreover R-P interface tunnels octet stream so RNN might be not able to make
> efficient dropping mechanism, unless we say that  GRE packet  encapsulates
> complete PPP frame. I do not remember reading any such thing in RP document.
> Correct me in case i missed it. RNN might end up dropping some thing which just
> contain PPP  frame boundary.  In this case incomplete PPP frame will cause CRC
> errors at mobile station.  We do not want to send something over SCH, which we
> know is going to be erased by mobile station. Note in case of L2TP framing is
> done at LAC, so such problem does not exist.
>
> regards,
> ajoy
>
> >
> > The best I can see one can do, in IP networks, is to actively manage buffers
> > (RED, LQD+WFQ and drop from front ...). There's ECN to be used
> > experimentally, but that is anyway ultimately relying on some active queue
> > management augmented with ECN capability.
> >
> > there's a dangerous slip into transport issue here... are we supposed to do
> > that here?
> >
> > alessio


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 25 17:25:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05897
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 25 Mar 2000 17:25:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C547DB0@standards.nortelnetworks.com>; Sat, 25 Mar 2000 17:20:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 102850 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Mar 2000 17:19:34
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E33F22A0@standards.nortelnetworks.com>; Sat, 25 Mar 2000 17:09:32
          -0500
Received: from server.goldvi.it (server.goldvi.it [195.103.98.3]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id QAA12805 for
          <mobile-ip@smallworks.com>; Sat, 25 Mar 2000 16:14:10 -0600 (CST)
Received: from showme (ABDE4B95.ipt.aol.com [171.222.75.149]) by
          server.goldvi.it (8.8.4/8.8.4) with SMTP id XAA28342; Sat, 25 Mar
          2000 23:20:42 +0100
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
Message-ID:  <jbuwc.wbxdtjhbaabnymqjqfj@showme>
Date:         Mon, 15 Nov 1999 14:13:10 -0800
Reply-To: spy2@post.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: mailfromspyadmin@post.com
Subject:      [MOBILE-IP] INTERNET SPY!
X-To:         fed@%domain.NORTELNETWORKS.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7BIT

////////////////////////////////////////
one time mailing-
no need to remove
////////////////////////////////////////

CONFIDENTIAL INFORMATION YOU WANT TO KNOW.

This is the software they want banned from the INTERNET!

"The Internet Desktop Spy" shows you how to get the facts on anyone using the
Internet.

LOCATE MISSING PERSONS, find lost relatives, obtain addresses and phone
numbers of old school friends, even skip trace dead beat spouses.  This is
not a Private Investigator, but a SOFTWARE program DESIGNED to automatically
CRACK YOUR CASE with links to thousands of Public Record Databases

Find out SECRETS about your relatives, friends, enemies, and everyone else!
-- even your spouse! With the New - "Internet Desktop SPY"

You will be AMAZED at what you can discover:

LICENSE PLATE NUMBER - Get anyone's name and address with just a license
plate number! (Find that girl you met in traffic!)

DRIVING RECORD - Get anyone's driving record!

SOCIAL SECURITY NUMBER - Trace anyone by social security number!

ADDRESS - Get anyone's address with just a name!

UNLISTED PHONE NUMBERS - Get anyone's phone number with just a name- even
unlisted numbers!

LOCATE - Long lost friends, relatives, a past lover who broke your heart!

E-MAIL - Send anyone anonymous e-mail that's completely untraceable!

DIRTY SECRETS - Discover dirty secrets your in-laws don't want you to know!

INVESTIGATE ANYONE - Use the sources that private investigators use (all on
the Internet) secretly!

EX-SPOUSE - Learn how to get information on an ex-spouse that will help you
win in court! (Dig up old skeletons)

CRIMINAL SEARCH - BACKGROUND CHECK - Find out about your daughter's
boyfriend! (or her husband)

FIND OUT - If you are being investigated!

NEIGHBORS - Learn all about your mysterious neighbors!  Find out what they
have to hide!

PEOPLE YOU WORK WITH - Be astonished by what you'll learn about the people
you work with!

EDUCATION VERIFICATION - Did he really graduate college?  Find out!

"The Internet Desktop Spy" will help you discover ANYTHING about anyone, with
clickable hyperlinks and no typing in Internet addresses!  Just download the
software and go!  You will be shocked and amazed by the secrets that can
be discovered about absolutely everyone!  Find out the secrets they don't
want you to know!  About others, about yourself!

LIMITED TIME OFFER -- ORDER TODAY!  ONLY $20 (US)

You can dowmload the  "The Internet DeskTop Spy" software NOW so you can begin
discovering all the secrets you ever wanted to know!  You can know EVERYTHING
about ANYONE with "The Internet DeskTop Spy" software.

- Works with all browsers and all versions of AOL
- PC Versions available Only!

DON'T WAIT TO GET STARTED… It's as easy as 1, 2, 3.
ORDER TODAY - While this software is still legal!

VISA/MC ONLY


FAX SERVICE-
STEP 1:  Print out the below ORDER FORM
STEP 2:  Type or Print your order information into the form
STEP 3:  FAX Your order to us.

FAX to:415-704-3071

(Order with confidence.  This is a secure fax area. Only our qualified sales team will have access to your order  information)

***************************************************************************************************************************
 "The Internet DeskTop Spy" ORDER FORM - PLEASE WRITE CLEARLY

Name:                   ________________________________

Address:                ________________________________

City, State, ZIP:       ________________________________

Country:                ______________   (International Orders)

Phone Number:           ______________   (In case we can't make out your order)

TOTAL COST OF ORDER IS $20.00

 ALL ORDERS WILL BE PROCESSED WITHIN 48 HOURS OF RECEIPT

METHOD OF PAYMENT – ID Code AXXX

[   ]Visa   [   ]MasterCard

Credit Card #:  __________________________________

Exp Date:               _______________

Signature:              ____________________________ (Required)

 E-Mail Address: ____________________________ *(VERY IMPORTANT-PRINT CLEARLY!!)


 -NOTES: - This program will not work on Windows 3.11 and older.
- Sorry, Mac versions not yet available.
 - DISCLAIMER - The seller of this powerful software resource will not be held  responsible for how the purchaser chooses to use its resources.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Mar 25 17:29:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06761
	for <mobileip-archive@LISTS.IETF.ORG>; Sat, 25 Mar 2000 17:29:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE497360@standards.nortelnetworks.com>; Sat, 25 Mar 2000 17:24:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 102854 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Mar 2000 17:23:09
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63468E70@standards.nortelnetworks.com>; Sat, 25 Mar 2000 17:13:07
          -0500
Received: from unknown (slip-32-101-245-65.tx.us.prserv.net [32.101.245.65]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id QAA12813 for
          <mobile-ip@smallworks.com>; Sat, 25 Mar 2000 16:17:48 -0600 (CST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <138.160623.808409@>
Date:         Sat, 25 Mar 2000 17:23:09 -0500
Reply-To: prof28@LOGON.NET
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: prof28@LOGON.NET
Subject:      [MOBILE-IP] Tired Of Earning What Someone Else Thinks You Are
              Worth?
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Have You Dreamed Of:

-Owning Your Own Time?

-Controlling your Financial Future?

-Feeling Good About What You Do
And Helping Others?

Are you?

-Tired Of Working For Someone Else
  For What "They" Feel You Are Worth?

--Tired Of The MLM Scene?

-Looking For A Legitimate Home-Based
Enterprise That Can Generate You
$10k-20k+ Monthly?

THEN CHECK THIS OUT

-Make $1,000 to $15,000 Profit On Every
Sale And our System Does The Selling
For you.

-Free Enterprise......Not MLM Or Franchise.

-Full Training And Support In An Environment
Of Utmost Integrity.

-Lead Generation System That Brings Qualified
Prospects to You.

-A Multiple 6-Figure Income is Realistically
Attainable in 1st Year.

-2 to3 year Retirement Program...Period!

-This Program Is All About Money...How To
  Make It, How To Keep It, And How to Make
  It Work For you.

CALL:

1-800-320-9895  Ext. 5433
Free Recorded Message


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar 26 10:05:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08948
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 26 Mar 2000 10:05:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19F05070@standards.nortelnetworks.com>; 26 Mar 2000 10:00:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103816 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 09:58:29
          -0500
Received: from mail.iagu.net (203.32.153.69) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6FD955B0@standards.nortelnetworks.com>; 26 Mar 2000 9:48:28 -0500
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247] by
          mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id AAA29906 return
          <giuseppe.ricagni@italtel.it>; Mon, 27 Mar 2000 00:23:04 +0930 (CST)
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38DE8D56.D4C0AD2F@italtel.it>
Date:         Mon, 27 Mar 2000 00:21:10 +0200
Reply-To: Giuseppe Ricagni <giuseppe.ricagni@ITALTEL.IT>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Giuseppe Ricagni <giuseppe.ricagni@ITALTEL.IT>
Subject:      [MOBILE-IP] draft-ricagni-megaco-umts-all-ip-00.txt
X-To:         "MEGACO@STANDARDS.NORTELNETWORKS.COM"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
X-cc:         Antonella Napolitano <antonella.napolitano@cselt.it>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Dear all,

we would like to draw your attention a new I-D: the draft is a very
preliminary work on the analysis and comparison of the diferent call
control protocols foreseen by 3GPP in its "all-IP" scenario.

As we didn't make it for the submission deadline, the I-D is temporarily
available at

http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.txt
http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.ps for
the postscipt version
http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.pdf
for the .pdf version

The choice of the call control protocol is currently a very hot issue in
3GPP,
and we would like to try to support this decision process "in the IETF
way", to say, with open documents and technically-driven discussions.

In this first version of the document, Megaco/H.248 is briefly analysed
and a few scenarios are described (Registration, UMTS Mobile-to-UMTS
Mobile call, UMTS Mobile-to-PSTN call).

Please let us know any comments/remarks

Thanking you in advance
Best Regards
Giuseppe Ricagni

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

Phone: +390243888797
FAX: +390243888405
mailto:giuseppe.ricagni@italtel.it
----------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar 26 10:08:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10124
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 26 Mar 2000 10:08:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62A34E80@standards.nortelnetworks.com>; 26 Mar 2000 10:02:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 103830 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 10:02:01
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EED82B20@standards.nortelnetworks.com>; 26 Mar 2000 9:52:01 -0500
Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id IAA17216 for
          <mobile-ip@smallworks.com>; Sun, 26 Mar 2000 08:56:37 -0600 (CST)
Received: from Lewi (seg28.iti.idsc.gov.eg [163.121.28.10] (may be forged)) by
          iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with SMTP id QAA25014 for
          <mobile-ip@smallworks.com>; Sun, 26 Mar 2000 16:57:32 +0200 (EET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0005_01BF9616.9E9D0240"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <000801bf9605$e61c9920$0a1c79a3@Lewi>
Date:         Sat, 25 Mar 2000 04:57:27 +0200
Reply-To: Hany Louis <habanoub@ITI-IDSC.GOV.EG>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Hany Louis <habanoub@ITI-IDSC.GOV.EG>
Organization: iti
Subject:      [MOBILE-IP] subscribe mobile-ip
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF9616.9E9D0240
Content-Type: text/plain;
        charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

subscribe mobile-ip=20

------=_NextPart_000_0005_01BF9616.9E9D0240
Content-Type: text/html;
        charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1256" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>subscribe mobile-ip =
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01BF9616.9E9D0240--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Mar 26 19:58:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22562
	for <mobileip-archive@LISTS.IETF.ORG>; Sun, 26 Mar 2000 19:58:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.68CEEE40@standards.nortelnetworks.com>; 26 Mar 2000 17:12:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 104340 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 17:11:50
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FA3AEFC0@standards.nortelnetworks.com>; 26 Mar 2000 17:01:50 -0500
Received: from mail.3dnet.com.au (IDENT:qmailr@[210.9.175.3]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id QAA19221 for
          <mobile-ip@smallworks.com>; Sun, 26 Mar 2000 16:06:30 -0600 (CST)
Received: (qmail 7790 invoked from network); 26 Mar 2000 22:06:16 -0000
Received: from abe1acb2.ipt.aol.com (HELO merc) (171.225.172.178) by
          mail.3dnet.com.au with SMTP; 26 Mar 2000 22:06:16 -0000
Message-ID:  <200003262206.QAA19221@hosaka.smallworks.com>
Date:         Sun, 26 Mar 2000 16:06:30 -0600
Reply-To: targeted@BUSINESSWEEKMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: targeted@BUSINESSWEEKMAIL.COM
Subject:      [MOBILE-IP] 3.9 cents per minute long distance
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

No come-ons, no hype, just plain
old fashioned good deals...

Flat Rate Discount
Long Distance
Telephone Service

Individually customized programs available
designed for your individual or business usage

AS LOW AS 3 CENTS PER MINUTE
TO 7.5 CENTS PER MINUTE...

24 hours a day - 7 days a week

Ultra Modern Fiber-Optic Network
Dial 1 Service - No Special 10-10 Codes
Perfect for Residential or Business

Calling cards available at 9.9 to 14.9 cpm
"800" numbers as low as 7.5 cpm
International rates at equally fantastic savings

No contracts to sign - No long term commitment
Outgoing USA numbers only


BUSINESS  OPPORTUNITY  AVAILABLE


To get more info,

Send Your

Name:
U.S. Phone # (required):
and Best time to contact you:

To mailto:telecom20@newmail.net

(Sorry, International phone numbers can not be processed at this time.
U.S. Phone number required to check availability.  We respect your
privacy and will not reveal your information to anyone else.)


Thanks for your time.


To unsubscribe, mailto:unsubscribe318@newmail.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 27 07:17:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02243
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Mar 2000 07:17:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B90256C0@standards.nortelnetworks.com>; Mon, 27 Mar 2000 7:11:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 105604 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 07:10:27
          -0500
Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.873ACF00@standards.nortelnetworks.com>; Mon, 27 Mar 2000 7:10:27
          -0500
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com
          [208.10.75.138]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with
          ESMTP id GAA13007 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon,
          27 Mar 2000 06:15:15 -0600 (CST)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service
          (5.5.2650.21) id <GKPHR774>; Mon, 27 Mar 2000 06:15:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID:  <2D11BCC7FFD8D3118FD70000D1ECDC88BB87F3@pkcexv018.sprintspectrum.com>
Date:         Mon, 27 Mar 2000 06:15:08 -0600
Reply-To: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Lipford, Mark" <MLipfo01@SPRINTSPECTRUM.COM>
Subject:      [MOBILE-IP] Mobile IP AAA Requirements
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

After the presentation today by Tom Hiller on the Mobile IP AAA Requirements
(draft-ietf-mobileip-aaa-reqs-03.txt) I would like to suggest that this I-D
be moved to last call as an informational RFC.  Currently the AAA WG has a
requirements I-D in last call that incorporates these requirements.  Since
it references this I-D we need to move this I-D to last call so it to can
proceed.

As a carrier interested in mobile IP and improvements to AAA I say let's
move these requirements forward as informational.

Thanks,

Mark A. Lipford
Manager, Wireless Industry Standards - Data
Sprint PCS
8001 College Blvd.; Suite 210
Overland Park, KS  66210

(913) 664-8335 (office)
(913) 664-8440 (fax)
(913) 226-9060 (PCS)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Mar 27 07:45:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13167
	for <mobileip-archive@LISTS.IETF.ORG>; Mon, 27 Mar 2000 07:45:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A42C7D30@standards.nortelnetworks.com>; Mon, 27 Mar 2000 7:39:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 105644 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 07:38:49
          -0500
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7A3562D0@standards.nortelnetworks.com>; Mon, 27 Mar 2000 7:38:43
          -0500
Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by
          ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id OAA24453 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Mar 2000 14:37:25
          +0200 (MET DST)
Received: from iseran (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with SMTP id OAA02765 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Mon, 27 Mar 2000 14:43:14
          +0200 (MET DST)
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38DF5762.41B5@inrialpes.fr>
Date:         Mon, 27 Mar 2000 14:43:14 +0200
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Claude Castelluccia <claude.castelluccia@INRIALPES.FR>
Subject:      [MOBILE-IP] -IPCN2000 in France-
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi everybody,

The program of IPCN2000 (the IP Based Cellular Network conference)
that will be held in Paris, France,
is now available online (http://www.upperside.fr/baipcn.htm).
Have a look.
The program is great and will gather speakers from the IETF, 3GPP,
UMTS and IPv6 forums.

Claude.

--

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


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 02:22:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17317
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 02:22:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0D62D60@standards.nortelnetworks.com>; Tue, 28 Mar 2000 2:16:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 106739 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 02:15:10
          -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.71782B90@standards.nortelnetworks.com>; Tue, 28 Mar 2000 2:15:10
          -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Mar
          28 02:19:34 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Mar
          28 02:19:34 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 943C657042 for <mobile-ip@standards.nortelnetworks.com>; Tue, 28
          Mar 2000 01:19:33 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000328071933.943C657042@king.research.bell-labs.com>
Date:         Tue, 28 Mar 2000 01:19:33 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      [MOBILE-IP] Dynamic Address Assignment in Mobile IP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

In light of the discussion following my presentation today, does
anyone want to talk about address assignment?  Here are the issues
as I understand them:

1) The NAI draft allows for a home address to be dynamically assigned
   to the MN if the MN puts 0.0.0.0 as its home address.
2) There is currently no way to specify additional information to the
   home agent that might guide it in choosing an address pool or
   performing other device-specific tasks upon receiving the registration
   request.  Also there is currently no way to keep the address after
   returning home.  Our draft attempts to fix these problems.
   (See draft-mccann-mobileip-sessionid-00.txt).
3) There was a lot of discussion about the proper role of DHCP in a
   Mobile IP network.  My personal feeling is that it is perfectly
   fine to use Mobile IP for address assignment, but any other parameters
   should be configured via DHCP after the registration has completed.
   This is analagous to the way DHCP would be used over a PPP link,
   for example.  That way the MN could be registered and have an address
   in one quick round trip for most cases.
4) For consistency, MNs should be able to get an address from an HA
   even while at home.  This eliminates the confusion about which server
   is managing the state for the address in case the MN later moves to
   a different network but wants to keep the assigned address.  I want
   to add this to the draft.

Comments?

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 03:25:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18100
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 03:25:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.719BA300@standards.nortelnetworks.com>; Tue, 28 Mar 2000 3:19:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 106817 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 03:18:33
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4C09DE90@standards.nortelnetworks.com>; Tue, 28 Mar 2000
          3:18:32 -0500
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se
          [153.88.251.32]) by penguin.wise.edt.ericsson.se
          (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA18226 for
          <MOBILE-IP@standards.nortelnetworks.com>; Tue, 28 Mar 2000 10:23:21
          +0200 (MET DST)
Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with
          Microsoft SMTPSVC(5.0.2172.1); Tue, 28 Mar 2000 10:22:13 +0200
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 28 Mar 2000
          08:22:13 0000 (GMT)
Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id <HQ22C89P>;
          Tue, 28 Mar 2000 10:22:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 28 Mar 2000 08:22:13.0890 (UTC)
                       FILETIME=[B8903620:01BF988E]
Message-ID:  <0DF8FF84C95BD211A9210008C7A433610674842F@esekint290.ki.sw.ericsson.se>
Date:         Tue, 28 Mar 2000 10:22:50 +0200
Reply-To: "Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Dear all,

I'm happy to see that this discussion continues as there is, I would say obvious, a need to support dynamic address assignment also in Mobile IP. And yes the NAI draft gives this possibility, and which would be quite suitable to use in remote access.

In the corporate environment, DHCP is the king (in most networks), and it should definitely be possible to assign address(es) using DHCP, especially as this is the means by which many network administrators like to manage their IP address space.
Using DHCP is by the way not limited just to the corporate environment, also ISPs are using it.

Sorry to say, but I haven't read your draft, but I hope it is possible to also have this option for IP address assignment covered in your draft (and perhaps it already is?).

Cheers,
  /Martin


-----Original Message-----
From: Pete McCann [mailto:mccap@RESEARCH.BELL-LABS.COM]
Sent: den 28 mars 2000 09:20
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] Dynamic Address Assignment in Mobile IP


In light of the discussion following my presentation today, does
anyone want to talk about address assignment?  Here are the issues
as I understand them:

1) The NAI draft allows for a home address to be dynamically assigned
   to the MN if the MN puts 0.0.0.0 as its home address.
2) There is currently no way to specify additional information to the
   home agent that might guide it in choosing an address pool or
   performing other device-specific tasks upon receiving the registration
   request.  Also there is currently no way to keep the address after
   returning home.  Our draft attempts to fix these problems.
   (See draft-mccann-mobileip-sessionid-00.txt).
3) There was a lot of discussion about the proper role of DHCP in a
   Mobile IP network.  My personal feeling is that it is perfectly
   fine to use Mobile IP for address assignment, but any other parameters
   should be configured via DHCP after the registration has completed.
   This is analagous to the way DHCP would be used over a PPP link,
   for example.  That way the MN could be registered and have an address
   in one quick round trip for most cases.
4) For consistency, MNs should be able to get an address from an HA
   even while at home.  This eliminates the confusion about which server
   is managing the state for the address in case the MN later moves to
   a different network but wants to keep the assigned address.  I want
   to add this to the draft.

Comments?

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 04:32:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18848
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 04:32:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D63A1090@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:26:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 106988 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 04:25:21
          -0500
Received: from marvin.axion.bt.co.uk by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3BB598B0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:15:21
          -0500
Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 28
          Mar 2000 09:59:04 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service
          (5.5.2651.88) id <HDS7D0J9>; Tue, 28 Mar 2000 09:58:50 +0100
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Message-ID:  <F66469FCE9C5D311B8FF0000F8FE9E070394B63F@mbtlipnt03.btlabs.bt.co.uk>
Date:         Tue, 28 Mar 2000 09:58:55 +0100
Reply-To: "Ford,M,Mat,NZC5 FORDM5 R" <matthew.ford@BT.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Ford,M,Mat,NZC5 FORDM5 R" <matthew.ford@BT.COM>
Subject:      [MOBILE-IP]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I was concerned with the wording on one of the slides at today's
presentation which suggested that the Attendant MUST be able to
*dynamically* establish a security association with the AAAL. Referring to
the document, I find the following wording: 'The local authority has to
share, or dynamically establish, security relationships with external
authorities that are able to
check client credentials'

This seems fine. The Attendant MUST be able to establish an SA with
AAAL. Whether it does this via pre-shared secrets or some dynamic mechanism
is irrelevant here.

Regards.......Mat
____________________
Matthew D Ford MA MSc
Network Security Design
pp8 MLB1 BT Adastral Park
Martlesham Heath
United Kingdom
Tel:+44 1473 605699
Fax: +44 1473 623910
Mobile: +44 7803 784637


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 10:42:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22380
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 10:42:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E6220E0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 10:36:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 107527 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 10:35:11
          -0500
Received: from eagle.aud.alcatel.com (128.251.96.217) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E583B7E0@standards.nortelnetworks.com>; Tue, 28 Mar 2000
          10:25:10 -0500
Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id
          JAA10612; Tue, 28 Mar 2000 09:29:36 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20000328071933.943C657042@king.research.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38E0CF5D.A7857BDC@usa.alcatel.com>
Date:         Tue, 28 Mar 2000 09:27:25 -0600
Reply-To: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vincent Magret <vincent.magret@USA.ALCATEL.COM>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pete,

Here's one comment.

Pete McCann wrote:

> In light of the discussion following my presentation today, does
> anyone want to talk about address assignment?  Here are the issues
> as I understand them:
>
> 1) The NAI draft allows for a home address to be dynamically assigned
>    to the MN if the MN puts 0.0.0.0 as its home address.
> 2) There is currently no way to specify additional information to the
>    home agent that might guide it in choosing an address pool or
>    performing other device-specific tasks upon receiving the registration
>    request.  Also there is currently no way to keep the address after
>    returning home.  Our draft attempts to fix these problems.
>    (See draft-mccann-mobileip-sessionid-00.txt).

I don't see why the mobile node could not keep the address obtained while
visiting a foreign domain when returning home. Since the mobile host have its
IP stack configured why one address, it should used to inform the HA that he
is now back in the home domain.
If the mobile node returns home without knowledge of its IP address, it
should obtain one by send a registration request to its home agent with his
home address set to 0.0.0.0 just like defined in 1), since the home agent is
the authority that manage the address pool.

>
> 3) There was a lot of discussion about the proper role of DHCP in a
>    Mobile IP network.  My personal feeling is that it is perfectly
>    fine to use Mobile IP for address assignment, but any other parameters
>    should be configured via DHCP after the registration has completed.
>    This is analagous to the way DHCP would be used over a PPP link,
>    for example.  That way the MN could be registered and have an address
>    in one quick round trip for most cases.

When you mention other parameter I suspect that you refer to DNS server
address, gateway.... Why not letting the mobile used the one available in the
visited domain? This will reduce the latency for every DNS request for
instance.

>

>
> 4) For consistency, MNs should be able to get an address from an HA
>    even while at home.  This eliminates the confusion about which server
>    is managing the state for the address in case the MN later moves to
>    a different network but wants to keep the assigned address.  I want
>    to add this to the draft.
>

I agree the MN should not see any difference in the registration process.

>
> Comments?
>
> -Pete

Enjoy Adelaide.

Vincent.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 15:42:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26238
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 15:42:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62A58160@standards.nortelnetworks.com>; Tue, 28 Mar 2000 15:36:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108183 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 15:35:21
          -0500
Received: from snyoneab.oneonta.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D462B3B0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 15:25:20
          -0500
Received: from snyoneva.cc.oneonta.edu by snyoneva.cc.oneonta.edu (PMDF V5.2-31
          #32722) id <01JNKKQU394W90MXCK@snyoneva.cc.oneonta.edu> for
          mobile-ip@standards.nortelnetworks.com; Tue, 28 Mar 2000 15:30:34 EDT
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.PMDF.3.96.1000328152452.545265236A-100000@snyoneva.cc.oneonta.edu>
Date:         Tue, 28 Mar 2000 15:30:34 -0400
Reply-To: robetw23@SNYONEVA.CC.ONEONTA.EDU
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Thomas Robertson <robetw23@SNYONEVA.CC.ONEONTA.EDU>
Subject:      [MOBILE-IP] mobile-ip acronyms
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

        I need definitions of some acronyms for a presentation in my
networking class if someone would be so kind as to help me.

NAI- identify mobile users/nodes
AAA- funtionality to support domain mobility

        Thank you for your time and understanding.

                                                Sincerely,
                                                    Tom Robertson


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Mar 28 16:21:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26729
	for <mobileip-archive@LISTS.IETF.ORG>; Tue, 28 Mar 2000 16:21:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA3F6330@standards.nortelnetworks.com>; Tue, 28 Mar 2000 16:15:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108272 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 16:14:35
          -0500
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.50132F30@standards.nortelnetworks.com>; Tue, 28 Mar 2000 16:04:35
          -0500
Message-ID:  <MOBILE-IP%2000032816143528@STANDARDS.NORTELNETWORKS.COM>
Date:         Tue, 28 Mar 2000 16:03:27 -0500
Reply-To: Govind Krishnamurthi <govind.krishnamurthi@NOKIA.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Govind Krishnamurthi <govind.krishnamurthi@NOKIA.COM>
Subject:      [MOBILE-IP] Sequence Numbers in Binding Updates
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hello:
There is some confusion in the terminology in  the definition of sequence numbers in  binding updates in the Mobility Support for
IPv6 draft.
According to the definition, "Each Binding Update sent by a mobile node MUST use a sequence number greater than the
sequence number value sent in the previous binding update (if any) to  the same destination address ( modulo 2 **16)".
For the sake of clarity, rather than "destination address" a more appropriate phrase might be "Home Address" (a permanent
address). Destination addresses might be understood as the present care-of address of the mobile node, in which case scenarios
can be constructed wherein the wrong address is chosen  as the address of the correspondent node.

Thanks,
Govind Krishnamurthi
Nokia Reseach Center,
Boston,


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 01:24:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07785
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 01:24:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5734E30@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:18:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108952 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 01:17:09
          -0500
Received: from crufty.research.bell-labs.com (204.178.16.49) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.810B7910@standards.nortelnetworks.com>; Wed, 29 Mar 2000
          1:17:09 -0500
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Wed
          Mar 29 01:20:52 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Wed Mar
          29 01:20:51 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id 8C7AC57042; Wed, 29 Mar 2000 00:20:50 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <0DF8FF84C95BD211A9210008C7A433610674842F@esekint290.ki.sw.ericsson.se>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000329062050.8C7AC57042@king.research.bell-labs.com>
Date:         Wed, 29 Mar 2000 00:20:50 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
X-To:         "Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <0DF8FF84C95BD211A9210008C7A433610674842F@esekint290.ki.sw.ericsson.se>
Content-Transfer-Encoding: 7bit

"Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE> (MJ) writes:

MJ> I'm happy to see that this discussion continues as there is, I
MJ> would say obvious, a need to support dynamic address assignment
MJ> also in Mobile IP. And yes the NAI draft gives this possibility,
MJ> and which would be quite suitable to use in remote access.

Good - I hope we have agreement on that.

MJ> In the corporate environment, DHCP is the king (in most networks),
MJ> and it should definitely be possible to assign address(es) using
MJ> DHCP, especially as this is the means by which many network
MJ> administrators like to manage their IP address space.  Using DHCP
MJ> is by the way not limited just to the corporate environment, also
MJ> ISPs are using it.

There is nothing in the draft that precludes the Home Agent from using
DHCP to manage the address pool.  However I think there is a problem
if the MN tries to use DHCP directly to acquire an address.  The problem
is that the MN's DHCP DISCOVER message needs to be reverse-tunneled
to the home network *before* the MN has even acquired an IP address,
and the response needs to be properly encapsulated by the HA - essentially,
the FA and HA are acting in concert as a BOOTP relay, which I am not
sure is supported.  Any comments from DHCP experts?

MJ> Sorry to say, but I haven't read your draft, but I hope it is
MJ> possible to also have this option for IP address assignment
MJ> covered in your draft (and perhaps it already is?).

Assignment of an address by DHCP is outside the scope of the draft.  I
hope we can build upon the NAI-based address assignment, and use DHCP
later for configuring other things.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 01:25:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07788
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 01:24:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5817F00@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:18:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 108955 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 01:18:29
          -0500
Received: from tcm-gw.tcm.hut.fi (130.233.44.1) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B0566810@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:18:28
          -0500
Received: (from smap@localhost) by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id JAA17256
          for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Mar 2000
          09:23:21 +0300
Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap
          (V2.0) id xma017252; Wed, 29 Mar 00 09:23:18 +0300
Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7]) by
          caffeine.tcm.hut.fi (8.9.2/8.9.2) with ESMTP id JAA29932; Wed, 29 Mar
          2000 09:23:38 +0300 (EET DST)
Received: from localhost (lyang@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1)
          with ESMTP id JAA17478; Wed, 29 Mar 2000 09:22:56 +0300 (EET DST)
X-Authentication-Warning: morphine.tcm.hut.fi: lyang owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.SOL.4.10.10003290901230.17292-100000@morphine.tcm.hut.fi>
Date:         Wed, 29 Mar 2000 09:22:56 +0300
Reply-To: Linfeng Yang <lyang@TCM.HUT.FI>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Linfeng Yang <lyang@TCM.HUT.FI>
Subject:      Re: [MOBILE-IP] Sequence Numbers in Binding Updates
X-To:         Govind Krishnamurthi <govind.krishnamurthi@NOKIA.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <MOBILE-IP%2000032816143528@STANDARDS.NORTELNETWORKS.COM>

Hello Govind,

I think the definition in MobileIPv6 draft is right, since mobile node can
also send Binding Update to a correspondent node. In this case the
destination address will be the correspondent node's address, either its
Home Address or its care-of address if the correspondent node is a mobile
node too.

The present care-of address of a mobile node can be used as source
address in order to pass the ingress filtering. In this case, the home
address of the mobile node will be indicated in a destination option.

I hope you were not confused destination option with destination address
:)

Yours,

Lin

On Tue, 28 Mar 2000, Govind Krishnamurthi wrote:

> Hello:
> There is some confusion in the terminology in  the definition of sequence numbers in  binding updates in the Mobility Support for
> IPv6 draft.
> According to the definition, "Each Binding Update sent by a mobile node MUST use a sequence number greater than the
> sequence number value sent in the previous binding update (if any) to  the same destination address ( modulo 2 **16)".
> For the sake of clarity, rather than "destination address" a more appropriate phrase might be "Home Address" (a permanent
> address). Destination addresses might be understood as the present care-of address of the mobile node, in which case scenarios
> can be constructed wherein the wrong address is chosen  as the address of the correspondent node.
>
> Thanks,
> Govind Krishnamurthi
> Nokia Reseach Center,
> Boston,
>

Linfeng Yang
                Helsinki University of Technology
                Telecommunications Software and Multimedia Laboratory
                P.O.Box 9700, 02015 HUT, Finland
                Phone: +358-(0)9-451 5250     Fax: +358-(0)9-451 5351


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 01:30:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08569
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 01:30:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FA1A520@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:24:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109028 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 01:23:08
          -0500
Received: from crufty.research.bell-labs.com (204.178.16.49) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.572EF620@standards.nortelnetworks.com>; Wed, 29 Mar 2000
          1:23:08 -0500
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Wed Mar
          29 01:26:50 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Wed Mar
          29 01:26:49 EST 2000
Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia
          [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP
          id C71EA57042; Wed, 29 Mar 2000 00:26:48 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <20000328071933.943C657042@king.research.bell-labs.com>
            <38E0CF5D.A7857BDC@usa.alcatel.com>
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000329062648.C71EA57042@king.research.bell-labs.com>
Date:         Wed, 29 Mar 2000 00:26:48 -0600
Reply-To: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
X-To:         Vincent Magret <vincent.magret@USA.ALCATEL.COM>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38E0CF5D.A7857BDC@usa.alcatel.com>
Content-Transfer-Encoding: 7bit

Vincent Magret <vincent.magret@USA.ALCATEL.COM> (VM) writes:

VM> I don't see why the mobile node could not keep the address
VM> obtained while visiting a foreign domain when returning
VM> home. Since the mobile host have its IP stack configured why one
VM> address, it should used to inform the HA that he is now back in
VM> the home domain.

Right - this is exactly what our draft tries to accomplish, by assigning
appropriate interpretations to the COA=HomeAddr, Lifetime>0 case.

VM>  If the mobile node returns home without knowledge of its IP
VM> address, it should obtain one by send a registration request to
VM> its home agent with his home address set to 0.0.0.0 just like
VM> defined in 1), since the home agent is the authority that manage
VM> the address pool.

I think so too.  And the Mobile IP Lifetime should be the Lifetime
of the requested address.

VM> When you mention other parameter I suspect that you refer to DNS
VM> server address, gateway....

Yes.

VM> Why not letting the mobile used the
VM> one available in the visited domain? This will reduce the latency
VM> for every DNS request for instance.

Unfortunately that doesn't make sense if the MN has a private address
and its traffic is all being tunneled back to a private network.  In
this case we need to use the services on the home network.

>> 4) For consistency, MNs should be able to get an address from an HA
>> even while at home.  This eliminates the confusion about which server
>> is managing the state for the address in case the MN later moves to
>> a different network but wants to keep the assigned address.  I want
>> to add this to the draft.

VM> I agree the MN should not see any difference in the registration process.

Good.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 03:44:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17634
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 03:44:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F386C10@standards.nortelnetworks.com>; Wed, 29 Mar 2000 3:38:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109254 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 03:36:28
          -0500
Received: from mail.iagu.net (203.32.153.69) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.F6A47970@standards.nortelnetworks.com>; Wed, 29 Mar 2000 3:36:27
          -0500
Received: from dhcp-194-83.ietf.connect.com.au [169.208.194.83] by
          mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id SAA08268 for
          <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM> return
          <giuseppe.ricagni@italtel.it>; Wed, 29 Mar 2000 18:11:02 +0930 (CST)
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------3DDFD15D7932CA84079514FC"
Message-ID:  <38E1C171.BAC4540E@italtel.it>
Date:         Wed, 29 Mar 2000 18:10:18 +0930
Reply-To: Giuseppe Ricagni <giuseppe.ricagni@ITALTEL.IT>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Giuseppe Ricagni <giuseppe.ricagni@ITALTEL.IT>
Subject:      [MOBILE-IP] Analysing MEGACO as a call control protocol for UMTS
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

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

Dear all,

due to a lack of time in the MOBILEIP meeting I' ve not been able to
present our analysis on the  usage of the MEGACO protocol as a call
control protocol for 3GPP UMTS all-IP networks.

I just wanted to inform all the intersted people that a slot for such
presentation has been allocated whithin the Megaco WG meeting, tomorrow
(thursday) morning

Best Regards
Giuseppe Ricagni

Giuseppe Ricagni wrote:

> Subject:
>         Proposed ADELAIDE Agenda (revised)
>    Date:
>         Tue, 28 Mar 2000 19:32:03 -0600
>    From:
>         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
>      To:
>         MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Discussion here in Adelaide and review of activity on the list has
> suggested
> that we need to spend less time on the base protocol document and more
> on
> looking forward.  To that end, here is a revised proposal for the
> meeting
> agenda tomorrow morning.
>
> Broad outline:
>
> 09:00 - 09:05 Agenda bashing
> 09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?)
> 09:15 - 09:45 Looking forward (detailed list of issues below) (Taylor)
> 09:45 - 09:55 Interoperability plans (Rosen, Taylor)
> 09:55 - 10:25 Current work
>     draft-ietf-megaco-ipphone-02.txt        (Blatherwick)
>     draft-ietf-megaco-naspkg-00.txt         (Taylor)
>     draft-ietf-megaco-R2package-00.txt   (??)
>     draft-ietf-megaco-mib-00.txt              (Holdrege, Brown)
> 10:25-10:50 Potential future work
>     draft-brown-supplpkgs-00.txt               (Brown)
>     draft-bouwen-megaco-isdn-00.txt         (Van Doorselaer)
>     draft [ATM]
>     draft-ricagni-megaco-umts-all-ip-00.txt  (Ricagni)
>     Other suggestions?
> 10:50-11:30 Review of proposed corrections to base document
> (Taylor)
>
> Issues looking forward:
>
> (1) Base protocol evolution:
>    -- what process for IETF participation?
>    -- what does the IETF publish?
>    -- do we apply IETF process to take Megaco v1 to Draft Standard?
>
> (2) Packages:
>    -- what track?  Decision on per-case basis?
>    -- what process for publishing ITU-generated packages?
>    -- what process for creating IETF-generated packages?
>
> (3) Profiles:
>    -- who creates?
>    -- registration process?
>
> Bottom line: does IETF wish to continue to participate in Megaco/H.248
> development?  If so, should Megaco continue to exist, should offshoot
> WGs be
> constituted as needed, or should everything be handled at the IESG
> level?
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dear all,
<p>due to a lack of time in the MOBILEIP meeting I' ve not been able to
present our analysis on the&nbsp; usage of the MEGACO protocol as a call
control protocol for 3GPP UMTS all-IP networks.
<p>I just wanted to inform all the intersted people that a slot for such
presentation has been allocated whithin the Megaco WG meeting, tomorrow
(thursday) morning
<p>Best Regards
<br>Giuseppe Ricagni
<p>Giuseppe Ricagni wrote:
<blockquote TYPE=CITE>Subject:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proposed ADELAIDE Agenda
(revised)
<br>&nbsp;&nbsp; Date:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tue, 28 Mar 2000 19:32:03
-0600
<br>&nbsp;&nbsp; From:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom-PT Taylor &lt;taylor@NORTELNETWORKS.COM>
<br>&nbsp;&nbsp;&nbsp;&nbsp; To:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MEGACO@STANDARDS.NORTELNETWORKS.COM
<p>Discussion here in Adelaide and review of activity on the list has
<br>suggested
<br>that we need to spend less time on the base protocol document and more
<br>on
<br>looking forward.&nbsp; To that end, here is a revised proposal for
the
<br>meeting
<br>agenda tomorrow morning.
<p>Broad outline:
<p>09:00 - 09:05 Agenda bashing
<br>09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?)
<br>09:15 - 09:45 Looking forward (detailed list of issues below) (Taylor)
<br>09:45 - 09:55 Interoperability plans (Rosen, Taylor)
<br>09:55 - 10:25 Current work
<br>&nbsp;&nbsp;&nbsp; draft-ietf-megaco-ipphone-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Blatherwick)
<br>&nbsp;&nbsp;&nbsp; draft-ietf-megaco-naspkg-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Taylor)
<br>&nbsp;&nbsp;&nbsp; draft-ietf-megaco-R2package-00.txt&nbsp;&nbsp; (??)
<br>&nbsp;&nbsp;&nbsp; draft-ietf-megaco-mib-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Holdrege, Brown)
<br>10:25-10:50 Potential future work
<br>&nbsp;&nbsp;&nbsp; draft-brown-supplpkgs-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Brown)
<br>&nbsp;&nbsp;&nbsp; draft-bouwen-megaco-isdn-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Van Doorselaer)
<br>&nbsp;&nbsp;&nbsp; draft [ATM]
<br><b><u><font color="#CC0000">&nbsp;&nbsp;&nbsp; draft-ricagni-megaco-umts-all-ip-00.txt&nbsp;
(Ricagni)</font></u></b>
<br>&nbsp;&nbsp;&nbsp; Other suggestions?
<br>10:50-11:30 Review of proposed corrections to base document
<br>(Taylor)
<p>Issues looking forward:
<p>(1) Base protocol evolution:
<br>&nbsp;&nbsp; -- what process for IETF participation?
<br>&nbsp;&nbsp; -- what does the IETF publish?
<br>&nbsp;&nbsp; -- do we apply IETF process to take Megaco v1 to Draft
Standard?
<p>(2) Packages:
<br>&nbsp;&nbsp; -- what track?&nbsp; Decision on per-case basis?
<br>&nbsp;&nbsp; -- what process for publishing ITU-generated packages?
<br>&nbsp;&nbsp; -- what process for creating IETF-generated packages?
<p>(3) Profiles:
<br>&nbsp;&nbsp; -- who creates?
<br>&nbsp;&nbsp; -- registration process?
<p>Bottom line: does IETF wish to continue to participate in Megaco/H.248
<br>development?&nbsp; If so, should Megaco continue to exist, should offshoot
<br>WGs be
<br>constituted as needed, or should everything be handled at the IESG
<br>level?
<p>Tom Taylor
<br>Advisor -- Emerging Carrier IP Standards
<br>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
<br>Phone and FAX: +1 613 736 0961</blockquote>
</html>

--------------3DDFD15D7932CA84079514FC--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 05:42:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18679
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 05:42:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2322290@standards.nortelnetworks.com>; Wed, 29 Mar 2000 5:36:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109401 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 05:35:09
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8BD34A20@standards.nortelnetworks.com>; Wed, 29 Mar 2000
          5:35:09 -0500
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se
          [153.88.251.32]) by penguin.wise.edt.ericsson.se
          (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA13766 for
          <MOBILE-IP@standards.nortelnetworks.com>; Wed, 29 Mar 2000 12:40:02
          +0200 (MET DST)
Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with
          Microsoft SMTPSVC(5.0.2172.1); Wed, 29 Mar 2000 12:39:14 +0200
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 29 Mar 2000
          10:39:14 0000 (GMT)
Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id <HQ22KRDP>;
          Wed, 29 Mar 2000 12:39:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 29 Mar 2000 10:39:14.0359 (UTC)
                       FILETIME=[06C1FC70:01BF996B]
Message-ID:  <0DF8FF84C95BD211A9210008C7A4336106748432@esekint290.ki.sw.ericsson.se>
Date:         Wed, 29 Mar 2000 12:39:55 +0200
Reply-To: "Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
X-To:         Pete McCann <mccap@research.bell-labs.com>
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Regarding the use of DHCP in corporate environment, the idea would be to have the possibility to configure "everything" from the beginning, i.e. both the address of the HA as well as MN's IP address corresponding to the home network, and possibly also the address corresponding to the visited network. This means that tunneling via the HA (And FA) won't begin until you have all this configured in the MN.

We have done this in actual implementation, and it works fine, though there is a need to make some modifications in the DHCP client when you request the IP addresses for both home + visited.

Cheers,
  /Martin


-----Original Message-----
From: Pete McCann [mailto:mccap@research.bell-labs.com]
Sent: den 29 mars 2000 08:21
To: Martin Johnsson (ERA)
Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP



"Martin Johnsson (ERA)" <Martin.Johnsson@ERA.ERICSSON.SE> (MJ) writes:

MJ> I'm happy to see that this discussion continues as there is, I
MJ> would say obvious, a need to support dynamic address assignment
MJ> also in Mobile IP. And yes the NAI draft gives this possibility,
MJ> and which would be quite suitable to use in remote access.

Good - I hope we have agreement on that.

MJ> In the corporate environment, DHCP is the king (in most networks),
MJ> and it should definitely be possible to assign address(es) using
MJ> DHCP, especially as this is the means by which many network
MJ> administrators like to manage their IP address space.  Using DHCP
MJ> is by the way not limited just to the corporate environment, also
MJ> ISPs are using it.

There is nothing in the draft that precludes the Home Agent from using
DHCP to manage the address pool.  However I think there is a problem
if the MN tries to use DHCP directly to acquire an address.  The problem
is that the MN's DHCP DISCOVER message needs to be reverse-tunneled
to the home network *before* the MN has even acquired an IP address,
and the response needs to be properly encapsulated by the HA - essentially,
the FA and HA are acting in concert as a BOOTP relay, which I am not
sure is supported.  Any comments from DHCP experts?

MJ> Sorry to say, but I haven't read your draft, but I hope it is
MJ> possible to also have this option for IP address assignment
MJ> covered in your draft (and perhaps it already is?).

Assignment of an address by DHCP is outside the scope of the draft.  I
hope we can build upon the NAI-based address assignment, and use DHCP
later for configuring other things.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 07:06:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19799
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 07:06:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A5E0710@standards.nortelnetworks.com>; Wed, 29 Mar 2000 7:00:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 109591 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 06:58:52
          -0500
Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D71F8520@standards.nortelnetworks.com>; Wed, 29 Mar 2000 6:48:50
          -0500
Received: from Notes.airtouch.com (ath-irv-smtp1.it.cl.airtouch.com
          [153.114.55.212]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP
          id EAA09849 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Wed, 29 Mar
          2000 04:00:41 -0800 (PST)
Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id
          882568B1.0040F5C2 ; Wed, 29 Mar 2000 03:49:32 -0800
X-Lotus-FromDomain: AIRTOUCH
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <882568B1.0040F3F2.00@Notes.airtouch.com>
Date:         Mon, 27 Mar 2000 21:46:32 -0800
Reply-To: Eric.Jaques@NOTES.AIRTOUCH.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Eric JAQUES <Eric.Jaques@NOTES.AIRTOUCH.COM>
Subject:      [MOBILE-IP] Suggestion to move Mobile IP AAA requirements to last
              call
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I would like to support Mark Lipfords' suggestion to move the Mobile IP AAA
requirements document to last call.

The absence of comments/issues during Tom Hiller's presentation and on the
mailing list, seems to indicate that the document covers the need of the Mobile
IP Working Group.

If there are remaining issues, the last call is a good way to encourage the
interested parties to review the document and have them bring their issues to
the attention of the WG sooner rather than later.

Eric Jaques
Vodafone AirTouch


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 14:13:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23640
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 14:13:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C730280@standards.nortelnetworks.com>; Wed, 29 Mar 2000 14:07:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 110378 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 14:06:07
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.87E6A3D0@standards.nortelnetworks.com>;
          Wed, 29 Mar 2000 13:56:07 -0500
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id LAA03850; Wed, 29 Mar 2000 11:59:42
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          KAA28012; Wed, 29 Mar 2000 10:34:21 -0800 (PST)
Received: from sunray-mpka (sunray-mpka [129.146.1.42]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id KAA10229; Wed, 29 Mar 2000 10:34:20
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: asiy65pv2h69d8wSoXkl5A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Message-ID:  <200003291834.KAA10229@nasnfs.eng.sun.com>
Date:         Wed, 29 Mar 2000 10:34:20 -0800
Reply-To: Vipul Gupta <Vipul.Gupta@Eng.Sun.COM>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Vipul Gupta <Vipul.Gupta@Eng.Sun.COM>
Subject:      Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP
X-To:         mccap@RESEARCH.BELL-LABS.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Date: Tue, 28 Mar 2000 01:19:33 -0600
> From: Pete McCann <mccap@RESEARCH.BELL-LABS.COM>
> Subject: [MOBILE-IP] Dynamic Address Assignment in Mobile IP

> In light of the discussion following my presentation today, does
> anyone want to talk about address assignment?  Here are the issues
> as I understand them:

> 3) There was a lot of discussion about the proper role of DHCP in a
>    Mobile IP network.  My personal feeling is that it is perfectly
>    fine to use Mobile IP for address assignment, but any other parameters
>    should be configured via DHCP after the registration has completed.
>    This is analagous to the way DHCP would be used over a PPP link,
>    for example.  That way the MN could be registered and have an address
>    in one quick round trip for most cases.

  I agree. As people start using Mobile IP in other scenarios, the mobile
  node will need to acquire additional parameters (e.g. it might need
  an "internal" DNS server when using private addresses) and it makes
  sense to reuse DHCP for this purposes. The PPP WG has already been
  down the path of first trying to add lots of DHCP-like functionality
  to PPP and then deciding on reusing DHCP (through the DHCP inform
  message) as the preferred approach.

  [Interestingly enough, the IPSRA working group (IPSec for remote access)
  is also going through a similar debate -- reusing DHCP v/s extending
  IKE for negotiating network parameters relevant to the
  "internal network". For some background on why the former is better,
  see draft-ietf-ipsec-dhcp-04.txt.]

  vipul


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Mar 29 23:57:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01061
	for <mobileip-archive@LISTS.IETF.ORG>; Wed, 29 Mar 2000 23:57:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B0644A0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 23:50:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 111347 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 23:50:13
          -0500
Received: from hruzek.hruzek.cz (194.228.3.26) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.2104EDA0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 23:40:13
          -0500
Received: from localhost (unverified [209.203.247.83]) by hruzek.hruzek.cz
          (EMWAC SMTPRS 0.83) with SMTP id <B0000034023@hruzek.hruzek.cz>; Thu,
          30 Mar 2000 06:48:36 +0200
X-Mailer: Internet Mail Service [12.5.879.96] (Win95; I)
X-Accept-Language: en
Sensitivity: Personal
Content-Type: text/plain
Message-ID:  <p5x24s8t1l2btrw.290320002052@localhost>
Date:         Wed, 29 Mar 2000 23:50:13 -0500
Reply-To: lindia23@EMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: lindia23@EMAIL.COM
Subject:      [MOBILE-IP] Spread the word & take a break on us!!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

We are giving away free hotel nights in Orlando!!
All we ask is that you visit our new children and
Jewerly family website.

Once in our site, you will be able to foward this
link to as many friends as you wish... Remember,
all we are looking for are visitors!


<A HREF="http://picagem.com">



***************************************************
We are terribly sorry if you have received this
message in error. If you wish to be removed, please
type REMOVE in subjets line: freehotel@fiberia.com
Thank you.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 30 00:22:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01425
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Mar 2000 00:22:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.317EA9F0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 0:16:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 111443 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 00:14:55
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.93D6AAF0@standards.nortelnetworks.com>; Thu, 30 Mar 2000
          0:04:54 -0500
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          HAA13016 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30 Mar
          2000 07:09:50 +0200 (MET DST)
Received: from uab.ericsson.se (uabasc2c65 [134.138.21.184]) by
          ms.uab.ericsson.se (8.10.0/8.10.0/uab-evision: 2.24 $) with ESMTP id
          e2U59mP02965 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Thu, 30
          Mar 2000 07:09:48 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en,fr,da
MIME-Version: 1.0
References: <20000328071933.943C657042@king.research.bell-labs.com>
            <38E0CF5D.A7857BDC@usa.alcatel.com>
            <20000329062648.C71EA57042@king.research.bell-labs.com>
Content-Type: multipart/mixed; boundary="------------B032B10EDAEADC9665073547"
Message-ID:  <38E2CEB9.98A37D59@uab.ericsson.se>
Date:         Thu, 30 Mar 2000 05:49:13 +0200
Reply-To: L-F Pau <louis-francois.pau@UAB.ERICSSON.SE>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: L-F Pau <louis-francois.pau@UAB.ERICSSON.SE>
Organization: Ericsson Utvecklings AB
Subject:      [MOBILE-IP] unsubscribe
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------B032B10EDAEADC9665073547
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe

--------------B032B10EDAEADC9665073547
Content-Type: text/x-vcard; charset=us-ascii;
 name="louis-francois.pau.vcf"
Content-Description: Card for L-F Pau
Content-Disposition: attachment;
 filename="louis-francois.pau.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Pau;L-F
tel;cell:+46-70-5901339
tel;work:+46-70-5901339
x-mozilla-html:FALSE
version:2.1
adr;quoted-printable:;;louis-francois.pau@uab.ericsson.se=0D=0Alouis-francois.pau@lme.ericsson.se;;;;
fn:L-F Pau
end:vcard

--------------B032B10EDAEADC9665073547--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 30 02:05:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12332
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Mar 2000 02:05:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9EA9DDC0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 1:59:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 111642 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 01:58:23
          -0500
Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6DF6FA50@standards.nortelnetworks.com>; Thu, 30 Mar 2000 1:58:23
          -0500
Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by
          sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id CAA00827;
          Thu, 30 Mar 2000 02:03:19 -0500 (EST)
Received: (from campbell@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET)
          id SAA29584; Mon, 27 Mar 2000 18:42:47 -0500 (EST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <200003272342.SAA29584@comet.columbia.edu>
Date:         Mon, 27 Mar 2000 18:42:47 -0500
Reply-To: "Andrew T. Campbell" <campbell@COMET.COLUMBIA.EDU>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Andrew T. Campbell" <campbell@COMET.COLUMBIA.EDU>
Subject:      Re: [MOBILE-IP] Mobile IP AAA Requirements
X-To:         MLipfo01@SPRINTSPECTRUM.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <2D11BCC7FFD8D3118FD70000D1ECDC88BB87F3@pkcexv018.sprintspectrum.com> from "Lipford, Mark" at Mar 27,
              2000 06:15:08 am
Content-Transfer-Encoding: 7bit

Sangyho:

Please mail your responses to these very good
questions to the list so that other students
will have the benefit of the answers.

And it will save you answering again.

Andrew
>
> After the presentation today by Tom Hiller on the Mobile IP AAA Requirements
> (draft-ietf-mobileip-aaa-reqs-03.txt) I would like to suggest that this I-D
> be moved to last call as an informational RFC.  Currently the AAA WG has a
> requirements I-D in last call that incorporates these requirements.  Since
> it references this I-D we need to move this I-D to last call so it to can
> proceed.
>
> As a carrier interested in mobile IP and improvements to AAA I say let's
> move these requirements forward as informational.
>
> Thanks,
>
> Mark A. Lipford
> Manager, Wireless Industry Standards - Data
> Sprint PCS
> 8001 College Blvd.; Suite 210
> Overland Park, KS  66210
>
> (913) 664-8335 (office)
> (913) 664-8440 (fax)
> (913) 226-9060 (PCS)
>


--
Andrew
http://www.ctr.columbia.edu/~campbell
(212)-854-3109


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Mar 30 15:49:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21466
	for <mobileip-archive@LISTS.IETF.ORG>; Thu, 30 Mar 2000 15:49:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6330920@standards.nortelnetworks.com>; Thu, 30 Mar 2000 15:44:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 112600 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 15:42:56
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.387F0DF0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 15:32:56
          -0500
Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA18314 for
          <mobile-ip@smallworks.com>; Thu, 30 Mar 2000 14:37:48 -0600 (CST)
Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3])
          by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id VAA01131 for
          <mobile-ip@smallworks.com>; Thu, 30 Mar 2000 21:33:55 +0200 (MET DST)
Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA39113; Thu, 30
          Mar 2000 21:03:28 +0100
Address: Mickiewicza 30, 30-059 Krakow, POLAND
Message-ID:  <10003302003.AA39113@saturn.kt.agh.edu.pl>
Date:         Thu, 30 Mar 2000 21:03:28 +0100
Reply-To: Piotr Pacyna <proms@SATURN.KT.AGH.EDU.PL>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: Piotr Pacyna <proms@SATURN.KT.AGH.EDU.PL>
Organization: University of Mining and Metallurgy
Subject:      [MOBILE-IP] PROMS2000 Call for Papers
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Dear Sir, Dear Madam,

Please find enclosed the Protocols for Multimedia Systems conference CfP.
Please read it and send to your collegues. Thank you for your attention.
We do apologise if you receive multiple copies of this.

With best regards,
Piotr Pacyna

++++++++++++++++++++++++++++++++++++++++++++++++++++++

(Please apologize, if you receive multiple copies of this CfP)

                       Announcement and Call for Papers

                  PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000

                       Cracow, Poland, October 22-25, 2000
Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap.
Lucent Technologies, ZWUT a Siemens Company,
                         http://PROMS2000.kt.agh.edu.pl/

After past successful PROMS conferences held in Berlin, Salzburg,
Madrid, and Santiago de Chile now we cordially invite you to
Cracow/Poland, a lovely university city, with a 1000 year history, today
one of cultural capitals of Europe.

Emerging broadband interactive applications along with a development of
different networking technologies should draw telecom operators' and
service providers' attention to protocols supporting multimedia systems
as an interface between these two environments that has to be still
investigated and modified.

The PROMS2000 conference is intended to contribute to a scientific,
strategical and practical cooperation between research institutes and
industrial companies in the area of distributed multimedia applications,
protocols, and intelligent management tools, with emphasis on their
provision over broadband networks.

PROMS2000 will cover papers and demonstrations on research and
achievements related to the following topics:

TOPICS
* design and implementation of multimedia protocols for public switched
telephony networks, mobile networks, data networks, and satellite
networks using IP, ATM or other connectivity techniques;
* application, media, and protocol integration: synchronization of media
streams;
* multiparty and group communication protocols;
* mobile networking and routing: multimedia communication architectures
for mobile networks;
* multimedia applications: video-on-demand, digital video libraries,
video games, virtual community, teleworking, teleteaching, e-commerce,
telemeeting, virtual reality simulations;
* content based searching and querying;
* techniques for the specification of communication services required by
multimedia applications;
* methods for real-time testing and analysis of service implementations;

* integration of media storage and communication mechanisms, operating
system and high-performance issues;
* experiences with service provisioning using distributed multimedia
applications;
* performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks
* multimedia traffic engineering;
* applications and platforms for service management and provisioning;
* definition, provisioning, and supervision of QoS parameters for
networked applications and services;
* intelligent management tools pertaining to costs and quality of
service, network access, accounting, security, and system resilience;
* service access - security, authentication, privacy;
* accounting and tariff policing for multimedia teleservices.

IMPORTANT DATES
* Full papers due                     June 26, 2000
* Authors notified                    July 24, 2000
* Full paper camera ready due         September 25, 2000

CONFERENCE TIMETABLE
* 1st day       October 22      full-day sightseeing tour (optional)
* 2nd day       October 23      tutorials, welcome reception
* 3rd day       October 24      invited talks, sessions, panel, banquet
* 4th day       October 25      invited talks, sessions

VENUE
Its history rooted deep in the Middle Ages, Cracow, is the most
celebrated city in Poland. UNESCO has added its architectural complex to
the World Heritage List. Cracow's appeal today, however, is no longer
attributable solely to the beauty of its medieval architecture, but to
its strong scientific potential for applied research and development.

The PROMS2000 Conference will be held on the modern premises of the
Department of Telecommunications within walking distance of both the
downtown area and hotels. Direct flights to Cracow are available to and
from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris,
Rome, Tel Aviv, Vienna and Zurich.

SUBMISSION
Submit a full manuscript to the PROMS chair in an electronic form
(MSWord, Postscript or pdf file); editorial requirements can be found at
http://PROMS2000.kt.agh.edu.pl/.

PROCEEDINGS
1. Each participant will receive Proceedings from the conference.
2. Two best papers will be considered for publication in the IEEE Communications
   Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia
   Systems".

CONFERENCE CHAIR
Zdzislaw PAPIR
Department of Telecommunications
University of Mining and Metallurgy
Al. Mickiewicza 30
30-059 Cracow, Poland
E-mail: papir@kt.agh.edu.pl
Phone: +48 12 634 55 82
Fax: +48 12 634 23 72

PROGRAM COMMITTEE
Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp
William Atwood, Univ. Concordia, Bill@cs.Concordia.ca
Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es
Stanislaw Budkowski, INT-Evry, stan@int-evry.fr
Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu
Michel Diaz, LAAS-CNRS, diaz@laas.fr
Wolfgang Effelsberg, Univ. Mannheim,
effelsberg@informatik.uni-mannheim.de
Paolo Fasano, CSELT, Paolo.Fasano@cselt.it
Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt
Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca
Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se
Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at
David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk
Yuji Inoue, NTT, yuji@rd.nttdata.co.jp
Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl
Pedro Lizcano, Telefonica Labs, lizcano@tid.es
John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk
Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl
Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it
Thomas Plagemann, Center for Technology, plageman@unik.no
Radia Perlman, SUN, radia.perlman@sun.com
Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de
Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl
Kazem Sohraby, Lucent, sohraby@lucent.com
Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com
Eduardo Vera, Univ. of Chile, evera@accessnova.cl
Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org

ORGANISING COMMITTEE
Chair: Piotr PACYNA, proms@kt.agh.edu.pl
K. Juszkiewicz, juszkiew@kt.agh.edu.pl
J. Gozdecki, gozdecki@kt.agh.edu.pl
J. Roman, roman@kt.agh.edu.pl


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Mar 31 03:25:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10769
	for <mobileip-archive@LISTS.IETF.ORG>; Fri, 31 Mar 2000 03:25:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E25B0470@standards.nortelnetworks.com>; Fri, 31 Mar 2000 3:19:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 113369 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 31 Mar 2000 03:17:15
          -0500
Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.3723A590@standards.nortelnetworks.com>; Fri, 31 Mar 2000 3:07:14
          -0500
Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id
          RAA27674 for <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>; Fri, 31 Mar
          2000 17:12:25 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <007e01bf9ae8$e582ada0$d012060a@hansol.co.kr>
Date:         Fri, 31 Mar 2000 17:12:10 +0900
Reply-To: "Lee, Jiwoong" <porce@KAIST.AC.KR>
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
From: "Lee, Jiwoong" <porce@KAIST.AC.KR>
Subject:      [MOBILE-IP] RFC2002 Simple editorial error
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Dear,

May I point out a simple editorial error.
RFC2002 page number 60.  The second paragraph of section 4.4 may be
start with "In order to receive" in lieu of "In order receive."

Thanks

Jiwoong Lee