Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27948; 1 Nov 93 3:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27944; 1 Nov 93 3:45 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24708; 1 Nov 93 3:45 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id AAA21036 for mobile-ip-dist; Mon, 1 Nov 1993 00:37:02 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.3/8.6.3) with ESMTP id AAA21013 for ; Mon, 1 Nov 1993 00:36:51 -0800 Received: from vtt.fi (vtt.fi [130.188.1.1]) by loki.ossi.com (8.6.3/8.6.3) with SMTP id AAA03233 for ; Mon, 1 Nov 1993 00:36:48 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hakan.Mitts@vtt.fi Received: by vtt.fi id AA05757 (5.67a8+/IDA-1.5 for mobile-ip@ossi.com); Mon, 1 Nov 1993 10:35:36 +0200 Message-Id: <199311010835.AA05757@vtt.fi> Date: Mon, 1 Nov 93 10:35:02 -0200 To: mobile-ip@ossi.com Subject: (mobile-ip 532) Some comments on draft(s) X-Charset: ASCII X-Char-Esc: 29 X-Popmail-Charset: European X-Orig-Sender: owner-mobile-ip@ossi.com Hello all, I've read the 'official' new version and the J,M&P 'shadow replica' for mobile support. Below some comments to the official version (unless other- wise stated). I know I'm a bit late but other work has had priority over this for a few weeks! Anyway, here goes! First some 'real life' concerns: - No access to home agent Even though the Internet gives the impression that 'everybody' is inter- connected, this in fact is not always the case. Many IP network exist (and will continue to exist) that are not interconnected. It would be nice if mobile IP could be used here as well to request temporary access to a net- work using the mobiles own address even when the two networks are not connected and consequently the home agent cannot be contacted. Functionally this would not change the current proposal much but there could be a few extra codes added to indicate 'service provided, local authorisation'. - Access to home agent but no remote comms allowed It might also be the case that a foreign network would allow a host into the network for local operations but would not support it in communication with other hosts (external to the visited network). Security firewalls or expensive communication lines could be some of the reasons for such a choice. In this case the interaction between foreign and home agent would be mainly used to authenticate the mobile. Again, functionally this is pretty much as is but a new type of foreign/home update without redirection would be needed, i.e a code to say 'pls authenticate but do not forward data'. - Number of home/foreign agents The way the current draft reads to me is that there needs to be one home/ foreign agent per physical subnet. This does seem an awful lot. It would seem that an organisation supporting mobile visitors would only like to have a single foreign agent serving several subnets if possible. I'm not familiar enough with IP routing to be able to say whether to current advertisement/solicit message would support having simple entities on each subnetwork advertising foreign agents on another subnetwork. If such a setup could be supported, the way interaction with routing is handled should be defined also. - Role of home agent when mobile is at home The draft seems to indicate that the home agent offers some service to the mobile when the mobile is at home. If the definition of being 'at home' is that the IP address is 'correct', it seems that the home agent should not be in any way involved in communication. Thus 'registration' with the home agent should more or less be equivalent to telling the home agent to 'shut up'. Here the official draft certainly needs to elaborate on the interaction of the home agent and the 'normal' routing in the home subnetwork as has been done in the the J,M&P version! - Role of foreign agent For the foreign agent as well, the draft needs to detail the role of the foreign agent with respect to the routing functionality of the visited network. - Agent type Also, the role of the agents should be made clearer for the possible confi- gurations that the current draft allows. It seems that there are three cases that should be considered: 1) the agent is a separate 'host' (a router with just one interface), 2) the agent is the only router of a subnetwork (nice optimisations seem possible here) and 3) the agent is hosted by one (of many) routers of a subnetwork. - Mobile with several IP addresses An issue that CDPD seems to bring up is that of a host with a separate address when mobile. CDPD forces a host using CDPD services to use an IP address assigned out of the CDPD service providers address range. How should this be handled by mobile IP? It would seem that in this case the home agent could act as a 'pop-up' agent for the mobile and that the mobile would register with the home agent, this case for a real service, i.e. the address translation needed to support a different 'out of the office' address?? Some general considerations: - Security I must say that I don't really like the security methods proposed in either the official not the J,M&P version. Magic cookie and password security is very flimsy at best and I think that the management effort involved is not justified nor is it a good idea to give a false feeling of security that in fact is not there. Therefore the only thing I would favour is some kind of security protocol between home agent and mobile host (passed thru the foreign agent as proposed) and nothing else unless a strong security mechanism is adopted. - Mobile host involvement I like the new draft because it only involves the mobile in communication with the serving agent. This I think is clearly the right way to do it. I also think that any dog leg elimination should not involve the mobile itself, only fixed network entities. The same certainly goes for any kind of tunneling etc. In this respect I don't like at all the J,M&P draft. I think a good goal could be to establish an mobile-agent protocol that would be 'final' and then enhance only those protocols that involve the agents. This means that focus should be on having the host-agent interactions as extensive as possible, covering most foreseeable needs while the fixed network internal matters could be enhanced later. - Multicast vs. broadcast The draft correctly (in my view) defines multicast protocols for adverti- sing and solicitaion. Some comments on the need to use broadcast makes me wonder whether we have learnt anything in the last 10 years? Should the draft specify multicast addresses for use by the mobile protocols?? Final comment: It's a pity that the Internet does not use ES-IS, as extending it to support mobile functions seems to pose a lot less problems than does supporting IP. Regs, H}kan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01873; 1 Nov 93 11:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01869; 1 Nov 93 11:34 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa04749; 1 Nov 93 11:34 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id IAA01778 for mobile-ip-dist; Mon, 1 Nov 1993 08:28:40 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.3/8.6.3) with SMTP id IAA01755 for ; Mon, 1 Nov 1993 08:28:20 -0800 Via: uk.ac.bristol.comms-research; Mon, 1 Nov 1993 16:27:57 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Mon, 1 Nov 93 16:27:57 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <28229.9311011627@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 533) Wireless addresses To: mobile-ip@ossi.com Date: Mon, 1 Nov 1993 16:27:55 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1191 X-Orig-Sender: owner-mobile-ip@ossi.com > > > The Foreign Agent should, in my opinion, use its wireline > > address for its Foreign Address. I think that the mobile-IP > > specification should not address the assignment of IP addresses > > to the wireless side. If there is one Foreign Address for a > > large pile of wireless Access Points (a la IEEE 802.11 or CDPD), > > then we would be inviting disharmony to require a specific > > means for assigning IP addresses to the Access Points. > > I agree that the wireline seems a cleaner address to choose, but I don't > see what difficulty it could cause to allow that to be an implementation > or configuration choice. Really the only thing IP cares about is that > packets which arrive at the FA have reached an entity which understands > how to forward to the mobile. The particular details are irrelevant > to IP. > I agree with Charles; and I don't think it should be an implementation or configuration choice. Don't mix up your layers. Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05794; 1 Nov 93 19:55 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05789; 1 Nov 93 19:55 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa17259; 1 Nov 93 19:54 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id QAA20852 for mobile-ip-dist; Mon, 1 Nov 1993 16:43:55 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.3/8.6.3) with ESMTP id QAA20829 for ; Mon, 1 Nov 1993 16:43:46 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.3/8.6.3) with SMTP id QAA03799 for mobile-ip; Mon, 1 Nov 1993 16:43:45 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311020043.QAA03799@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: mobile-ip@ossi.com Subject: (mobile-ip 534) Wireless addresses Date: Mon, 01 Nov 93 16:43:44 PST X-Orig-Sender: owner-mobile-ip@ossi.com > > I agree that the wireline seems a cleaner address to choose, but I don't > > see what difficulty it could cause to allow that to be an implementation > > or configuration choice. Really the only thing IP cares about is that > > packets which arrive at the FA have reached an entity which understands > > how to forward to the mobile. The particular details are irrelevant > > to IP. > I agree with Charles; and I don't think it should be an implementation or > configuration choice. Don't mix up your layers. > Alistair I don't understand your objection. What layers are being violated? Why is it bad to violate these layers? The IP address of the Foreign Agent is defined by the protocol as the thing which knows how to decapsulate and deliver packets to the Mobile Host. Which interface the Foreign Agent uses seems to me to depend on the particular hardware and implementation. For example, if I build a Foreign Agent which isn't housed in a router, then I must use an address which is on the network the Mobile Host is using. I might do this on a LAN, where I add one mobile-aware box. On the other hand, I might build a wireless router box which had an ethernet on one side and a wireless i/f on the other. In this case, the ethernet side is probably the Foreign Agent address, and the wireless network has separate addresses. Cheers, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11026; 1 Nov 93 23:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11022; 1 Nov 93 23:38 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22020; 1 Nov 93 23:38 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id UAA26104 for mobile-ip-dist; Mon, 1 Nov 1993 20:36:22 -0800 Reply-To: mobile-ip@ossi.com Received: from MCIGATEWAY.MCIMail.com (mcigateway.mcimail.com [192.147.45.2]) by rara.ossi.com (8.6.3/8.6.3) with SMTP id UAA26055 for ; Mon, 1 Nov 1993 20:36:13 -0800 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id av29120; 2 Nov 93 3:56 GMT Date: Tue, 2 Nov 93 03:07 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Henry Sinnreich <0002498337@mcimail.com> To: mobile ip Subject: (mobile-ip 535) mobile-ip Message-Id: <05931102030750/0002498337MT1EM@mcimail.com> X-Orig-Sender: owner-mobile-ip@ossi.com I had some difficulties with access to the host that I shared today with Steve Deering. Steve suggested you may help. What is the user ID, password, etc. ? Can you post the draft on the InterNIC ? Thanks, Henry Sinnreich MCI Data Services Engineering Richardson, Texas PS: To bad I have to miss out the IETF meetings on mobile IP.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01046; 2 Nov 93 7:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01042; 2 Nov 93 7:38 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa05651; 2 Nov 93 7:38 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id BAA02425 for mobile-ip-dist; Tue, 2 Nov 1993 01:21:39 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.3/8.6.3) with SMTP id BAA02402 for ; Tue, 2 Nov 1993 01:21:25 -0800 Via: uk.ac.bristol.comms-research; Tue, 2 Nov 1993 09:21:11 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Tue, 2 Nov 93 09:21:09 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <5095.9311020921@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 536) Wireless addresses To: mobile-ip@ossi.com Date: Tue, 2 Nov 1993 09:21:07 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2385 X-Orig-Sender: owner-mobile-ip@ossi.com Steve, > > > I agree that the wireline seems a cleaner address to choose, but I don't > > > see what difficulty it could cause to allow that to be an implementation > > > or configuration choice. Really the only thing IP cares about is that > > > packets which arrive at the FA have reached an entity which understands > > > how to forward to the mobile. The particular details are irrelevant > > > to IP. > > > I agree with Charles; and I don't think it should be an implementation or > > configuration choice. Don't mix up your layers. > > I don't understand your objection. What layers are being violated? Why > is it bad to violate these layers? > After some consideration, especially of the case where the FA may not have a wireline address or may have a virtual address, I can see that a configuration choice makes sense so I withdraw that part. I don't know what you mean by "implementation" in this context though. I am concerned with the cases where there are already mobile data networks, possibly public, based on existing infrastructures where mobility is either severely restricted, concealed, or provided in some vendor-specific way, (i.e. this is one interpretation of "implementation"). I think it might be a useful policy to default the FA address to the wireline address; however, like Andrew Myles, I don't think it matters much. *I* am the one who was mixing up the layers - sorry. I was following my usual ISDN/TETRA/GSM train of thought. > > For example, if I build a Foreign Agent which isn't housed in a > router, then I must use an address which is on the network the > Mobile Host is using. I might do this on a LAN, where I add one > mobile-aware box. On the other hand, I might build a wireless > router box which had an ethernet on one side and a wireless i/f > on the other. In this case, the ethernet side is probably the > Foreign Agent address, and the wireless network has separate > addresses. > Or similarly with routing into the ISDN. I would hope that we might be allowed to do things any way we chose, within the extremes of mobility without Mobile-IP through to Mobile-IP without mobility. Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04202; 2 Nov 93 10:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04196; 2 Nov 93 10:53 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa11861; 2 Nov 93 10:53 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id HAA11171 for mobile-ip-dist; Tue, 2 Nov 1993 07:50:07 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.3/8.6.3) with SMTP id HAA11143 for ; Tue, 2 Nov 1993 07:49:57 -0800 Via: uk.ac.bristol.comms-research; Tue, 2 Nov 1993 15:49:39 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Tue, 2 Nov 93 15:49:39 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <10148.9311021549@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 537) CDPD-Spec for mobile data networks? To: mobile-ip@ossi.com Date: Tue, 2 Nov 1993 15:49:36 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 803 X-Orig-Sender: owner-mobile-ip@ossi.com > > anyone interested in obtaining the CDPD specification can acquire it > by calling McCaw Cellular: > > you can obtain the CDPD spec. from McCaw Cellular > > by calling (800)42-MCCAW and asking for Clarissa Jurgenson > > send her your FAX number and she will send back a registration > form to you. unfortunately they are charging for the spec., and > I believe the fee is $150 US. > Can someone give me a real 'phone number for McCaw cellular please - fax too if possible. I can't fool the system into letting me call toll-free from outside the US, roll on IN... Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08779; 2 Nov 93 15:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08775; 2 Nov 93 15:41 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa20141; 2 Nov 93 15:41 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id MAA19192 for mobile-ip-dist; Tue, 2 Nov 1993 12:35:42 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.3/8.6.3) with ESMTP id MAA19084 for ; Tue, 2 Nov 1993 12:35:22 -0800 Received: from netcomsv.netcom.com (uucp2-b.netcom.com [163.179.1.8]) by loki.ossi.com (8.6.3/8.6.3) with SMTP id LAA11855 for ; Tue, 2 Nov 1993 11:28:38 -0800 Received: from nesutil.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA28956; Tue, 2 Nov 93 11:25:05 PST Received: by comarco.com (UUPC/extended 1.11q); Tue, 02 Nov 1993 09:46:10 PST Date: Tue, 02 Nov 1993 09:46:09 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Daniel Mahoney Message-Id: <2cd69ce3.nesutil@comarco.com> Organization: Comarco Advanced Technologies Division To: mobile-ip@ossi.com Subject: (mobile-ip 539) CDPD-Spec for mobile data networks? X-Orig-Sender: owner-mobile-ip@ossi.com On Tue, 2 Nov 1993 15:49:36 +0000 (GMT), "Alistair Munro" wrote: > > > Can someone give me a real 'phone number for McCaw cellular please - fax too > if possible. I can't fool the system into letting me call toll-free from > outside the US, roll on IN... > > Alistair > You can call 206-828-8023. I spoke with McCaw this morning regarding the CDPD spec; the price is $100.00 US. I also asked them to send a copy of the information to the fax number in your signature; you should be receiving it today. Dan Mahoney Comarco Wireless Technologies dan@comarco.com -- -------------------------------------------------------------------------- Dan Mahoney, Software Engineer Comarco Wireless Technologies dan@comarco.com dan@smoggy.speedway.net dmahoney@speedway.net -------------------------------------------------------------------------- ***** Vote NO on 174 - Save public education in California! *****   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09585; 2 Nov 93 16:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09581; 2 Nov 93 16:45 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa21840; 2 Nov 93 16:45 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.3/8.6.3) id NAA20915 for mobile-ip-dist; Tue, 2 Nov 1993 13:44:00 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.3/8.6.3) with ESMTP id NAA20892 for ; Tue, 2 Nov 1993 13:43:45 -0800 Received: from radiomail.net (radiomail.net [192.216.61.11]) by loki.ossi.com (8.6.3/8.6.3) with SMTP id NAA13463 for ; Tue, 2 Nov 1993 13:43:42 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill_Pabst@poqet.com Received: from melonville.radiomail.net (mayberry.radiomail.net) by radiomail.net with SMTP id AA05377 (5.65c+/IDA-1.4.4 for ); Tue, 2 Nov 1993 13:43:10 -0800 Message-Id: <199311022143.AA05377@radiomail.net> Received: from poqet.com by melonville.radiomail.net with CCGW-1.7(930217); Tue, 02 Nov 93 14:44:55 Date: 02 Nov 93 12:32 To: Mobile-IP@ossi.com Cc: Bill_Pabst@ossi.com Subject: (mobile-ip 540) Information about IP Roaming X-Orig-Sender: owner-mobile-ip@ossi.com We have been given this mail address to get more involved in Wireless Roaming System Architecture on IP networks. Could you respond with information? Thanks Bill Pabst Director of Software Development Fujitsu Personal System (POQET) 5200 Patrick Henry Drive Santa Clara, Ca 95054 (408) 764-9359   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02540; 6 Nov 93 15:16 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02536; 6 Nov 93 15:16 EST Received: from [192.240.4.50] by CNRI.Reston.VA.US id aa14277; 6 Nov 93 15:16 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA28697 for mobile-ip-dist; Sat, 6 Nov 1993 12:11:29 -0800 Reply-To: mobile-ip@ossi.com Received: from Zool.PacTel.COM (zool.pactel.com [151.144.254.21]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id MAA28674 for ; Sat, 6 Nov 1993 12:11:21 -0800 Received: from atlas.ccmail.pactel.com ([151.144.81.6]) by Zool.PacTel.COM (4.1/SMI-4.1/PacTel-Zool-Brent-921124-01) id AA13920; Sat, 6 Nov 93 11:54:01 PST Received: from cc:Mail by atlas.ccmail.pactel.com id AA752615248 Sat, 06 Nov 93 11:47:28 PST Date: Sat, 06 Nov 93 11:47:28 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: david zufall Encoding: 1158 Text Message-Id: <9310067526.AA752615248@atlas.ccmail.pactel.com> To: mobile-ip@ossi.com Subject: (mobile-ip 541) CDPD-Spec for mobile data networks? X-Orig-Sender: owner-mobile-ip@ossi.com The CDPD specification should be available from the consultanting company, PRTM. Call Tom Solazzo at 714-545-9400. Regards david.zufall@pactel.com On Tue, 2 Nov 1993 15:49:36 +0000 (GMT), "Alistair Munro" wrote: > > > Can someone give me a real 'phone number for McCaw cellular please - fax too > if possible. I can't fool the system into letting me call toll-free from > outside the US, roll on IN... > > Alistair > You can call 206-828-8023. I spoke with McCaw this morning regarding the CDPD spec; the price is $100.00 US. I also asked them to send a copy of the information to the fax number in your signature; you should be receiving it today. Dan Mahoney Comarco Wireless Technologies dan@comarco.com -- -------------------------------------------------------------------------- Dan Mahoney, Software Engineer Comarco Wireless Technologies dan@comarco.com dan@smoggy.speedway.net dmahoney@speedway.net -------------------------------------------------------------------------- ***** Vote NO on 174 - Save public education in California! *****   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04246; 8 Nov 93 3:20 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04242; 8 Nov 93 3:20 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa25620; 8 Nov 93 3:20 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id AAA14004 for mobile-ip-dist; Mon, 8 Nov 1993 00:14:03 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id AAA13981 for ; Mon, 8 Nov 1993 00:13:46 -0800 Via: uk.ac.bristol.comms-research; Mon, 8 Nov 1993 08:13:38 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Mon, 8 Nov 93 08:13:32 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <17420.9311080813@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 545) Thanks - re: CDPD/PRTM To: mobile-ip@ossi.com Date: Mon, 8 Nov 1993 08:13:29 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 420 X-Orig-Sender: owner-mobile-ip@ossi.com > The CDPD specification should be available from the consultanting company, > PRTM. Call Tom Solazzo at 714-545-9400. > > Regards > david.zufall@pactel.com David, Thanks for the info, AListair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14376; 8 Nov 93 12:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14372; 8 Nov 93 12:25 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa09246; 8 Nov 93 12:24 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA25648 for mobile-ip-dist; Mon, 8 Nov 1993 09:23:31 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id JAA25625 for ; Mon, 8 Nov 1993 09:23:19 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from [130.57.64.146] by wc.novell.com (4.1/smi4.1.1.v91190) id AA14238; Mon, 8 Nov 93 09:19:21 PST Date: Mon, 8 Nov 93 09:19:20 PST Message-Id: <9311081719.AA14238@wc.novell.com> To: "Charles A. Kunzinger" Subject: (mobile-ip 546) Updated Mobility Draft Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Charlie, The draft looks very good. Here are some comments on the second (pre-IETF) draft document: [page; section] [7;2] "A Foreign Agent does not advertise reachability to the served mobile host." I think this would be a purely local matter. An FA *could* advertise reachability within some local domain - it just isn't required. [7;2] There is mention of a "serving agent". Is this the HA or the FA or (gasp!) something new? [9;3] In the definition of FA, it says that the FA "will deliver the inner packet to the mobile host". In fact, the FA will *attempt* to deliver the inner packet to the mobie host. [10;4] "a mobile host will need to register its presence with a router that serves as its agent." I don't think we need to assume that the FA (or HA) is a router. [11;4.1] The requirements here can be met by current practices (manual configuration, etc.). [12;5.1] This was mentioned at the WG meeting in Houston, but it would be *very nice* to have the messages formatted in "RFC standard" notation (791, for example) of 32 bits across on each line, with "tick" marks every 8 bits, etc. Doing this will also help decide on how to align the fields within each message. [13;5.1] For "incarnation number", 1 byte probably isn't big enough for an agent which is using, say, a time-of-day clock as its incarnation number (to not have to keep some extra knowledge, like incarnation number, in stable storage). [17;6.2.2] The "mobile request" needs to include authentication information for the *prior* FA as well as for the current FA. [19;6.2.3] I think that we should specify that the FA will return a 64-bit magic cookie which will be used to authenticate the MH to the FA (in a "prior" message) when the MH moves to another FA. [19;6.2.3] I think we should specify, here and in 6.2.2, the actual algorithm for security between the MH and the HA. It should be private key (password) based, probably with a challenge response. Etc. (I'm *NOT* saying you should generate the actual words, just that the fields should be defined for a specific algorithm.) [23;6.2.6] I think that the authentication stuff here should be MH to prior FA (not new FA to prior FA). (Though, maybe in addition?) [24;6.2.6] The "Forwarding Hold Time" should be a *MAXIMUM* time that the prior FA is to hold information about the current location of the MH. The prior FA should be free to flush that information whenever it chooses. (This is partly because there is no way to *force* it to hold that information and, in fact, it may crash and lose the information; thus, we should design protocols that don't assume a mandatory retention of this information.) (See also [33;8.6].) [25;7.1] There is a paragraph "This document does not constrain the methods by which a mobile host can learn the IP address of an available local agent. One method that could be used is described in 5". I think this should be left out. [25;7.1.1] "If this is the first registration request made by the mobile host ..." What is "first"? Since the creation of the universe? Since it rebooted? Huh? [27;7.1.4] I don't see any reason to have a "mobile host requests home agent to forget about it" in the protocol. (However, something that says "please forget this binding" might be useful.) [28;8.1] I'm not sure it makes sense to distinguish a registration number of 0. Also, this is modular arithmetic, so somewhere you need to say how to deal with wrapping. [30;8.2.2] I think that when the FA says "i will serve you for NN seconds", it means that. If the FA crashes in the middle, the MH will just have to live with that. However, i don't think there needs to be any message that says "I'm the FA, and i am dropping you!". Too much code for a seldom used case. If the FA in question is flakey, it should give low lifetimes during registration. [32;8.3.2] Ditto. [34;9.1] "The advertisement will be carried as part of the routing protocol in force within the Home Agent's Autonomous System." The "will" should be changed to "may". Routing is not the only way to make this happen. [40;11.2] "Foreign Agent Initiated Deregistration" This should not be in the protocol, and the FA shouldn't do it. [40;11.3] "Home Agent Initiated Deregistration" This should NOT be in the protocol. If the HA is going to drop the MH from its list of clients, this should be done outside of the protocol (via phone messages, e'mail, letters) between the system administrator and the end user. And, one place-less item: You *DON'T* want to tell the HA every time the MH re-registers with the FA. (It may well be that the HA "lifetime" is much greater than that of the FA.) Thanks much, Greg Minshall   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23619; 8 Nov 93 20:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23615; 8 Nov 93 20:23 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24322; 8 Nov 93 20:23 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id RAA06988 for mobile-ip-dist; Mon, 8 Nov 1993 17:17:59 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id RAA06901 for ; Mon, 8 Nov 1993 17:17:47 -0800 Received: from mitl.MITL.Research.Panasonic.COM (mitl.MITL.Research.Panasonic.COM [150.169.1.4]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id PAA15364 for ; Mon, 8 Nov 1993 15:27:56 -0800 Received: from kiskeya (kiskeya.MITL.Research.Panasonic.COM) by mitl.MITL.Research.Panasonic.COM (4.1/SMI-4.1) id AA16752; Mon, 8 Nov 93 18:26:06 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ramon Caceres Received: by kiskeya (5.57/MITL_host) id AA26107; Mon, 8 Nov 93 18:26:02 -0500 Date: Mon, 8 Nov 93 18:26:02 -0500 Message-Id: <9311082326.AA26107@kiskeya> To: mobile-ip@ossi.com Subject: (mobile-ip 547) Interaction between TCP and mobile IP X-Orig-Sender: owner-mobile-ip@ossi.com The following report is available for anonymous, binary FTP in compressed, PostScript format from mitl.research.panasonic.com as pub/tr/73-93.Z: The Effects of Mobility on Reliable Transport Protocols, by Ramon Caceres and Liviu Iftode, Technical Report MITL-TR-73-93, Matsushita Information Technology Laboratory, Princeton, New Jersey, November, 1993. The paper describes the effects of host motion on the performance of active transport-level connections. More specifically, it analyzes the behavior of TCP connections when Columbia's Mobile*IP software performs cell handoffs in a WaveLAN radio network. The results make clear the need for the network layer to explicitly notify the transport layer of host motion events. I would suggest that the mobile IP proposal(s) being prepared by this working group make note of this need to guide future implementations. I'm not sure it's necessary for a mobile IP standard to define the exact nature of the information delivered to higher layers, but I think it would be helpful to keep the basic requirement in mind. --Ramon Caceres ramon@mitl.research.panasonic.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14995; 9 Nov 93 16:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14991; 9 Nov 93 16:33 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22088; 9 Nov 93 16:33 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA12274 for mobile-ip-dist; Tue, 9 Nov 1993 13:30:26 -0800 Reply-To: mobile-ip@ossi.com Received: from MANNIX.BBN.COM (MANNIX.BBN.COM [128.89.2.206]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id NAA12251 for ; Tue, 9 Nov 1993 13:30:13 -0800 Message-Id: <199311092130.NAA12251@rara.ossi.com> To: mobile-ip@ossi.com Subject: (mobile-ip 548) Interaction between TCP and mobile IP In-reply-to: Your message of Mon, 08 Nov 93 18:26:02 -0500. <9311082326.AA26107@kiskeya> Date: Tue, 09 Nov 93 16:22:18 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Julio Escobar X-Orig-Sender: owner-mobile-ip@ossi.com Hola Ramon, Muy interesante tu mensaje. Voy a obtener el reporte. Gracias. Saludos, JULIO   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03830; 12 Nov 93 9:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03824; 12 Nov 93 9:32 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa10476; 12 Nov 93 9:32 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id GAA07109 for mobile-ip-dist; Fri, 12 Nov 1993 06:20:42 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk ([137.222.10.38]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id GAA07086 for ; Fri, 12 Nov 1993 06:20:25 -0800 Via: uk.ac.bristol.comms-research; Fri, 12 Nov 1993 14:19:17 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Fri, 12 Nov 93 14:19:11 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <13629.9311121419@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 549) Interaction between TCP and mobile IP To: mobile-ip@ossi.com Date: Fri, 12 Nov 1993 14:19:08 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1673 X-Orig-Sender: owner-mobile-ip@ossi.com > > The Effects of Mobility on Reliable Transport Protocols, > by Ramon Caceres and Liviu Iftode, > Technical Report MITL-TR-73-93, > Matsushita Information Technology Laboratory, > Princeton, New Jersey, November, 1993. > > The paper describes the effects of host motion on the performance of > active transport-level connections. More specifically, it analyzes > the behavior of TCP connections when Columbia's Mobile*IP software > performs cell handoffs in a WaveLAN radio network. > > The results make clear the need for the network layer to explicitly > notify the transport layer of host motion events. I would suggest > that the mobile IP proposal(s) being prepared by this working group > make note of this need to guide future implementations. I'm not sure > it's necessary for a mobile IP standard to define the exact nature > of the information delivered to higher layers, but I think it would > be helpful to keep the basic requirement in mind. > I have read this report and it seems fair enough within the scope it sets itself. I wonder if the authors have any suggestions on implementating their conclusions - I couldn't see a clean way in the TCP/IP stack. In other wireless environments, (maybe this includes WaveLAN?) where access is contention based, one may find fairly wide variation in packet transit times anyway. Is this variation likely to cause more disruption than handoff? Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08127; 12 Nov 93 12:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08120; 12 Nov 93 12:33 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa15707; 12 Nov 93 12:33 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA11563 for mobile-ip-dist; Fri, 12 Nov 1993 09:30:37 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id JAA11540 for ; Fri, 12 Nov 1993 09:30:23 -0800 Received: from tenet.ICSI.Berkeley.EDU (root@tenet.ICSI.Berkeley.EDU [128.32.201.65]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id JAA08888 for ; Fri, 12 Nov 1993 09:30:21 -0800 Received: from lemma by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA14918; Fri, 12 Nov 93 09:30:18 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Bruce A. Mah" Received: by lemma (Sun-5.57/CLIENT$Revision: 1.4 $) id AA04442; Fri, 12 Nov 93 09:30:17 -0800 Date: Fri, 12 Nov 93 09:30:17 -0800 Message-Id: <9311121730.AA04442@lemma> To: mobile-ip@ossi.com Subject: (mobile-ip 550) (mobile-ip 549) Interaction between TCP and mobile IP References: <13629.9311121419@boycott.comms-research.bristol.ac.uk> X-Orig-Sender: owner-mobile-ip@ossi.com Alistair Munro writes: > In other wireless environments, (maybe this includes WaveLAN?) where access > is contention based, one may find fairly wide variation in packet transit times > anyway. Is this variation likely to cause more disruption than handoff? IMHO, I don't think so. Consider that when a MH moves between cells, there is a lot of handshaking between the MH and both the old and new MSSs in order to adjust routing tables within the wired network. I think this will add more delay during a handoff (and hence variation from the average end-to-end delay) than contention at the data link layer. Bruce.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13304; 12 Nov 93 16:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13300; 12 Nov 93 16:26 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22651; 12 Nov 93 16:26 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA17409 for mobile-ip-dist; Fri, 12 Nov 1993 13:24:00 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA17385 for ; Fri, 12 Nov 1993 13:23:51 -0800 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA09904 for ; Fri, 12 Nov 1993 13:23:48 -0800 Received: from via.rmm3.merit.edu by volitans.MorningStar.Com (5.65a/93052901) id AA08296; Fri, 12 Nov 93 16:23:13 -0500 Date: Fri, 12 Nov 93 15:29:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1640.bill.simpson@um.cc.umich.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 551) (mobile-ip 549) Interaction between TCP and mobile IP X-Orig-Sender: owner-mobile-ip@ossi.com Will somebody please get rid of these awful (...) subject modifications!!! Make a separate header line "X-Message" or something. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10196; 15 Nov 93 15:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10192; 15 Nov 93 15:19 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa20596; 15 Nov 93 15:19 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA17013 for mobile-ip-dist; Mon, 15 Nov 1993 12:08:32 -0800 Reply-To: mobile-ip@ossi.com Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id MAA16988 for ; Mon, 15 Nov 1993 12:08:21 -0800 Message-Id: <199311152008.MAA16988@rara.ossi.com> Received: from RALVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1116; Mon, 15 Nov 93 15:08:02 EST Date: Mon, 15 Nov 93 14:46:47 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Charles A. Kunzinger" X-Addr: (919)-254-4142; FAX (919)-254-5410 IBM Corp (C70/673) PO Box 12195 RTP, NC 27709 E-MAIL: kunzinger@vnet.ibm.com To: mobile-ip@ossi.com Subject: (mobile-ip 552) An Update on Mobility Draft.... X-Orig-Sender: owner-mobile-ip@ossi.com Last week, Jim Solomon sent me a note asking for a few words on what my plans and target dates are for a revised draft. There were a lots of ideas on what could be done, some ideas conflicted with others, and some we never really reached any firm conclusions about. However, I will do my best to get out a revised draft by no later than December 10 so that there will be time to review it before the January interim meeting. This draft will include text for all three areas of the mobility support: beaconing, registration, and route optimization. Here's a rough outline of the things (according to my notes) that we decided to look at. I'll try to incorporate them into the draft in a consistent manner. My mode of operation will be to follow the suggestions as closely as I can, but where necessary, I may have to modify things so that the draft is internally consistent. a) I'll handle most of the editorial stuff (pictures, packet formats, etc.) as I put the revision together b) Several people mentioned that we need a way to decide when a attempt by a mobile host has failed. I'm going to add the method outlined by Pierre Dupont--add a "request pending" message from Foreign Agent to host, along with appropriate timers. c) Several people asked to be able to accommodate addresses larger than 4 bytes. I'll accommodate this by using variable length address fields. d) Several people asked to allow separate re-registration procedures between MH and its FA, and MH and is HA. Since Home Service Lifetime and Foreign Service Lifetime are separately specified, it seems reasonable to do so. I'll add a flag to the Mobile Request message to denote "full registration, re-confirm with HA, or re-confirm with FA". e) There was a request to look at whether a mobile host can support several concurrent bindings simultaneously. I think this might be feasible--I'll add a flag to say if multiiple bindings are supported, in the Mobile Request message. However, this means that we can no longer necessarily flush an old binding as soon as a new one is received. This may mean that the mobile Host itself will need to terminate old bindings by sending a Mobile Request that specifically calls out the binding to be terminated (when several may be active). (==>I think I can work out the details, but if it gets too complicated, I may abandon this function) f) There was a request to add text saying that if a mobile host acquires a local address dynamically (a pop-up), that it's OK for the mobile host to serve as its own Foreign Agent. I'll add this text to the draft. g) We agreed to specify an encapsulation technique to be used for supporting mobility. When I left the IETF, I believe that Charlie Perkins was going to talk to Tony Li to reconcile concerns about the two proposals that were discussed at the IETF. I'll wait to hear their recommendations; if no agreement is reached, I'll simply pick a method and include it in the draft. h) We agreed to carry the mobility messages as UDP messages, and I've changed the packet formats accordingly. i) Triangle Route Elimination: I spent some time with Perkins and Johnson outside the meeting to try to decide what to do. Here's a rough outline of what seemed reasonable to me: 1) I'll add messages for Binding Updates and Binding Acknowledgements 2) Home Agent will send out Binding Updates, including a 'time-to-live" field. NOTE: I DON'T BELEIVE THAT WE'VE COME UP WITH ANY WAY FOR A CH TO INDICATE THAT IT CAN HANDLE SUCH BINDING UPDATES===> If anyone has a suggestion, let me know. 3) No cache functions in intermediate routers 4) I'll add a flag to Mobility Request message so a host can indicate if it will allow its binding to be advertised for route optimization pruposes. 5) OPEN ISSUE: Should Home Agent be required to retract any previously advertised binding when the binding becomes invalid? I don't recall that this issue was discussed either at the meeting or in the IMHP paper? k) Broken Subnet Model: I believe that the resolution for this concern was for us to do nothing in the mobility draft. Yakov Rekhter was going to follow up with the IAB on this general topic. l) I'll add methods to break the Foreign Agent/Home Agent loop that several people commented on. m) We need to add a section on "weak security" somewhere in the draft. I'll probably lift the basic text from the IMHP paper and put it into our draft. o) I lifted some of the introductory text from IMHP and added it to draft paper. p) I'll generate state tables/diagrams for each of the three protocol areas: beaconing, registration, and route optimization. ...Charlie   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10989; 15 Nov 93 15:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10985; 15 Nov 93 15:54 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa21638; 15 Nov 93 15:54 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA17672 for mobile-ip-dist; Mon, 15 Nov 1993 12:51:31 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id MAA17647 for ; Mon, 15 Nov 1993 12:51:23 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.4/8.6.4) with SMTP id MAA25407; Mon, 15 Nov 1993 12:51:21 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311152051.MAA25407@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: Ramon Caceres Cc: mobile-ip@ossi.com Subject: (mobile-ip 553) Interaction between TCP and mobile IP Date: Mon, 15 Nov 93 12:51:21 PST X-Orig-Sender: owner-mobile-ip@ossi.com Hi Ramon, I'm confused as to why your pauses in communication, shown in Figure 3 of your paper, are so long. For example, you show a 0.9 second loss of communication during a cell hand-off in the overlapping cell case. This seems quite long, and I don't think the Columbia protocol requires this. Is this a deficiency in the code you are using? I would hope that in overlapping cell hand-offs we would see _no_ communication loss, or at least minimal values. Cheers, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04465; 16 Nov 93 10:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04461; 16 Nov 93 10:04 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa09600; 16 Nov 93 10:04 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id HAA14125 for mobile-ip-dist; Tue, 16 Nov 1993 07:00:52 -0800 Reply-To: mobile-ip@ossi.com Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id HAA14102 for ; Tue, 16 Nov 1993 07:00:41 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: fratezi@vnet.ibm.com Message-Id: <199311161500.HAA14102@rara.ossi.com> Received: from GDLVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 5696; Tue, 16 Nov 93 10:00:22 EST Date: Tue, 16 Nov 93 09:57:38 EST To: MOBILE-IP@ossi.com Subject: (mobile-ip 554) Subscribe X-Orig-Sender: owner-mobile-ip@ossi.com Thank you FRATEZI@vnet.ibm.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06137; 16 Nov 93 11:00 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06133; 16 Nov 93 11:00 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa11237; 16 Nov 93 11:00 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id HAA15279 for mobile-ip-dist; Tue, 16 Nov 1993 07:58:37 -0800 Reply-To: mobile-ip@ossi.com Received: from mitl.MITL.Research.Panasonic.COM (mitl.MITL.Research.Panasonic.COM [150.169.1.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id HAA15255; Tue, 16 Nov 1993 07:58:26 -0800 Received: from kiskeya (kiskeya.MITL.Research.Panasonic.COM) by mitl.MITL.Research.Panasonic.COM (4.1/SMI-4.1) id AA01837; Tue, 16 Nov 93 10:57:52 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ramon Caceres Received: by kiskeya (5.57/MITL_host) id AA01073; Tue, 16 Nov 93 10:57:50 -0500 Date: Tue, 16 Nov 93 10:57:50 -0500 Message-Id: <9311161557.AA01073@kiskeya> To: sparker@ossi.com Subject: (mobile-ip 555) Interaction between TCP and mobile IP Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Steve, > I'm confused as to why your pauses in communication, shown in Figure 3 > of your paper, are so long. For example, you show a 0.9 second loss > of communication during a cell hand-off in the overlapping cell case. > This seems quite long, and I don't think the Columbia protocol requires > this. Is this a deficiency in the code you are using? Columbia's mobile IP software is not directly responsible for the long pauses you mention. Mobile IP protocols in general introduce relatively short interruptions in network-level communication, but TCP's congestion avoidance and control procedures amplify these interruptions into the much longer pauses shown in the paper. We can and should tune mobile IP to minimize the length of network-level interruptions during cell handoffs. However, as the paper argues early on, some interruptions are unavoidable. Current TCP cannot distinguish between congestion- and motion-related interruptions based only on its end-to-end delay measurements. Future versions of transport protocols need to distinguish between the two cases in order to avoid the problems described in the paper. --Ramon   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09858; 16 Nov 93 13:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09854; 16 Nov 93 13:36 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa15931; 16 Nov 93 13:36 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA03374 for mobile-ip-dist; Tue, 16 Nov 1993 10:33:41 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id KAA03351 for ; Tue, 16 Nov 1993 10:33:32 -0800 Received: from uswat.advtech.uswest.com (firewall-user@uswat.advtech.uswest.com [130.13.16.1]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id KAA01054 for ; Tue, 16 Nov 1993 10:33:30 -0800 Received: from atqm.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA00259 (5.65c/IDA-1.4.4 for ); Tue, 16 Nov 1993 11:33:22 -0700 Message-Id: <199311161833.AA00259@uswat.advtech.uswest.com> Date: 16 Nov 1993 11:05:35 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Penners Subject: (mobile-ip 556) Draft Document To: Charlie_Kunzinger.APM#u#NAS@atqm.advtech.uswest.com Cc: mobileip X-Orig-Sender: owner-mobile-ip@ossi.com Subject: Time:11:05 AM OFFICE MEMO Draft Document Date:11/16/93 Charlie K, You have a tough job! You work hard to produce a draft that will create consensus and then some jerk (myself) comes along and complains. Here goes: Ideas are being included in the draft with little discussion. For example, the soft hand-off suggestion from Phil and the multi-address suggestion from Tony (I think) were first voiced at the last IETF. Regardless of merit, if this is all it takes to get things in the draft, we're going to have a complex protocol. I would prefer convincing arguments to add features to the protocol, instead of convincing arguments to take them out. No offense intended and I hope none taken. Regards, John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11098; 16 Nov 93 14:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11094; 16 Nov 93 14:25 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa17757; 16 Nov 93 14:25 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA04659 for mobile-ip-dist; Tue, 16 Nov 1993 11:21:33 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id LAA04632 for ; Tue, 16 Nov 1993 11:21:25 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.4/8.6.4) with SMTP id LAA08904; Tue, 16 Nov 1993 11:21:24 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311161921.LAA08904@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: Ramon Caceres Cc: mobile-ip@ossi.com Subject: (mobile-ip 557) Interaction between TCP and mobile IP Date: Tue, 16 Nov 93 11:21:23 PST X-Orig-Sender: owner-mobile-ip@ossi.com - Columbia's mobile IP software is not directly responsible for the long - pauses you mention. Mobile IP protocols in general introduce relatively - short interruptions in network-level communication, but TCP's congestion - avoidance and control procedures amplify these interruptions into the - much longer pauses shown in the paper. Hmm. I think a *good* mobile IP allows uninterrupted communication in the case of overlapping cells which is why my question. I would like the mobile to keep receiving from the old foreign agent until the new foreign agent is validated to start sending packets. As I understand what you've said, the Columbia stack you used didn't provide uninterrupted packet flow, which caused a substantial TCP back-off. Correct? While I agree that there certainly will be unavoidable delays during hand-offs at times, this group's protocol allows for the possibility of uninterrupted communication. Cheers, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13968; 16 Nov 93 15:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13964; 16 Nov 93 15:43 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa20192; 16 Nov 93 15:43 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA06180 for mobile-ip-dist; Tue, 16 Nov 1993 12:34:00 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id MAA06157 for ; Tue, 16 Nov 1993 12:33:51 -0800 Received: from avalon.mpce.mq.edu.au ([137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id MAA02530 for ; Tue, 16 Nov 1993 12:33:44 -0800 Message-Id: <199311162033.MAA02530@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA10402; Wed, 17 Nov 93 07:36:51 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 558) An Update on Mobility Draft.... To: mobile-ip@ossi.com Date: Wed, 17 Nov 93 7:36:49 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day Charlie, Some comments... > c) Several people asked to be able to accommodate addresses larger > than 4 bytes. I'll accommodate this by using variable length > address fields. I don't recall this being decided and I think it is a terrible idea. There are enough varible length, unaligned fields in there already without adding more with unproven utility. > e) There was a request to look at whether a mobile host can support > several concurrent bindings simultaneously. I think this might be > feasible--I'll add a flag to say if multiiple bindings are supported, > in the Mobile Request message. However, this means that we can no > longer necessarily flush an old binding as soon as a new one is > received. This may mean that the mobile Host itself will need to > terminate old bindings by sending a Mobile Request that specifically > calls out the binding to be terminated (when several may be active). > (==>I think I can work out the details, but if it gets too > complicated, I may abandon this function) This has not been fully specified by anyone and so should be left out. As a side note: I am not sure it the editor should be adding features. If he should then it defeats the original purpose of having an editor - to take it out the hands of those that really care. (This is not a swipe at you Charlie) > f) There was a request to add text saying that if a mobile host acquires > a local address dynamically (a pop-up), that it's OK for the > mobile host to serve as its own Foreign Agent. I'll add this > text to the draft. This is discussed in the IMHP document - along with its associated problems. > g) We agreed to specify an encapsulation technique to be used for > supporting mobility. When I left the IETF, I believe that Charlie > Perkins was going to talk to Tony Li to reconcile concerns about > the two proposals that were discussed at the IETF. I'll wait to > hear their recommendations; if no agreement is reached, I'll > simply pick a method and include it in the draft. Actually, we (myself, Dave and Charlie) are going to be writing the encapsulation protocol up as a draft RFC. > h) We agreed to carry the mobility messages as UDP messages, and I've > changed the packet formats accordingly. I asume you are using ICMP for at least some of the packets. > i) Triangle Route Elimination: I spent some time with Perkins and > Johnson outside the meeting to try to decide what to do. ^^^^^^^ Myles > Here's a rough outline of what seemed reasonable to me: > 1) I'll add messages for Binding Updates and Binding > Acknowledgements What about Binding Request/Reply as in IMHP. > 2) Home Agent will send out Binding Updates, including a > 'time-to-live" field. NOTE: I DON'T BELEIVE THAT WE'VE > COME UP WITH ANY WAY FOR A CH TO INDICATE THAT IT CAN > HANDLE SUCH BINDING UPDATES===> If anyone has a suggestion, > let me know. Actually this is not what you want. You really want an indication that you cannot habdle them. > 3) No cache functions in intermediate routers I can live with this but ... > 4) I'll add a flag to Mobility Request message so a host can > indicate if it will allow its binding to be advertised for > route optimization pruposes. > 5) OPEN ISSUE: Should Home Agent be required to retract any > previously advertised binding when the binding becomes invalid? > I don't recall that this issue was discussed either at the > meeting or in the IMHP paper? This is not an open issue. The Sony protocol proved the folly of attempting this. > l) I'll add methods to break the Foreign Agent/Home Agent loop that > several people commented on. Would you like to tell us what they are? I suggested two methods in my talk at the IETF - do you have any other ideas? Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00568; 17 Nov 93 2:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00564; 17 Nov 93 2:41 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa01187; 17 Nov 93 2:41 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id XAA24225 for mobile-ip-dist; Tue, 16 Nov 1993 23:26:01 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id XAA24189 for ; Tue, 16 Nov 1993 23:25:51 -0800 Received: from localhost (uucp@localhost) by loki (8.6.4/8.6.4) with UUCP id VAA05683 for mobile-ip; Tue, 16 Nov 1993 21:45:04 -0800 Received: from ncrhub1.NCR.COM (via h192-127-251-3.NCR.COM) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AC24026; Tue, 16 Nov 93 17:39:40 -0500 Received: from ncrcom by ncrhub1.NCR.COM id aj22994; 16 Nov 93 14:40 EST Received: from ncrned by ncrcom.DaytonOH.NCR.COM id aa09715; 16 Nov 93 14:35 EST Received: by ncrned.Netherlands.NCR.COM; 16 Nov 93 20:31:38 EST Received: by pcsmtp.netherlands.ncr.com with Microsoft Mail id <2CE9A8E2@pcsmtp.netherlands.ncr.com>; Tue, 16 Nov 93 20:30:26 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Tony Desimone, SSD" To: mobile-ip Subject: (mobile-ip 560) Interaction between TCP and mobile IP Date: Tue, 16 Nov 93 20:30:00 PST Message-Id: <2CE9A8E2@pcsmtp.netherlands.ncr.com> Encoding: 60 TEXT X-Mailer: Microsoft Mail V3.0 X-Orig-Sender: owner-mobile-ip@ossi.com Ramon> We can and should tune mobile IP to minimize the length of network-level Ramon> interruptions during cell handoffs. However, as the paper argues early Ramon> on, some interruptions are unavoidable. Current TCP cannot distinguish Ramon> between congestion- and motion-related interruptions based only on its Ramon> end-to-end delay measurements. Future versions of transport protocols Ramon> need to distinguish between the two cases in order to avoid the problems Ramon> described in the paper. Oddly, this was just the topic of some private email, independent of the list. I agree with Ramon's conclusion, but more generally, future transport protocols will have to deal with situations when losses due to congestion aren't the dominant problem (when routers do resource reservation, etc.) In the interests of fanning the flames (is van on this list?) here's my comment on the topic: Tony> ocyue> In our Globecom paper, section 5 talks about the slow-start behavior. Tony> ocyue> Is that how TCP deals with perceived congestion, by closing the window? Tony> Tony> ocyue> The problem is that the delay increase may be due a new route taken by Tony> ocyue> by the IP packets. Tony> Tony> That's right. Any timeout, due to errors, rerouting, whatever, causes Tony> the window to be shut, and then grow again until either a loss, or Tony> until the window hits the maximum. This is of course really awful, Tony> but works well in practice because errors and rerouting are Tony> exceedingly rare compared to losses due to congestion. The important Tony> thing to realize about TCP congestion control is that it is used Tony> widely not because it is optimal in any way, but because there was a Tony> desperate need for some congestion control mechanisms on the Internet Tony> and the TCP controls could be implemented quickly in the hosts, in a Tony> backward-compatable manner and with no changes to the network routers Tony> (as would have been required for a DECbit-like scheme, for example, Tony> that requires the routers to update packets with congestion Tony> indications). Tony> Tony> Note that Internet routing is really pretty simple-minded, at least Tony> the way telephony people think about routing. In practice, all the Tony> routing protocols do is find a single path from source to destination. Tony> There is no traffic-sensitive routing or ability to exploit alternate Tony> paths in the event of congestion. (Sibal and I made this point in the Tony> paper we wrote last summer. Have you seen that?) The upshot is that Tony> rerouting happens only when a facility or a node along the path fails, Tony> and that does not happen very often. Now mobility and CDPD change Tony> that, so there is an interesting question about how TCP will behave in Tony> that environment... Tony> I haven't gotten Ramon's paper yet, because I'm in temoporarily in a networking nightmare in Amsterdam here as far as ftp is concerned. And apologies if MS Mail has done anything evil to this message...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08180; 17 Nov 93 12:56 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08176; 17 Nov 93 12:56 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa15833; 17 Nov 93 12:56 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA08382 for mobile-ip-dist; Wed, 17 Nov 1993 09:53:19 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id JAA08358 for ; Wed, 17 Nov 1993 09:53:12 -0800 Received: from alink-gw.apple.com (alink-gw.apple.com [17.255.0.18]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id JAA08053 for ; Wed, 17 Nov 1993 09:53:10 -0800 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA07345; Wed, 17 Nov 93 09:52:28 -0800 for MOBILE-IP@OSSI.COM Date: 17 Nov 93 17:47 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ritter, Mike" Subject: (mobile-ip 561) Charlie's thankless task To: MOBILE-IP@ossi.com Message-Id: <753558748.9129352@AppleLink.Apple.COM> X-Orig-Sender: owner-mobile-ip@ossi.com Andrew Myles responded to Charlie's progress report as follows: >> c) Several people asked to be able to accommodate addresses larger >> than 4 bytes. I'll accommodate this by using variable length >> address fields. > >I don't recall this being decided and I think it is a terrible idea. There >are enough varible length, unaligned fields in there already without adding >more with unproven utility. I like the idea of supporting multiple address types, however, I would point out that the 'unalignment' of the packet fields is something that was definitely left open and to be decided later. >> e) There was a request to look at whether a mobile host can support >> several concurrent bindings simultaneously. > >This has not been fully specified by anyone and so should be left out. I am convinced that this is an extrememly valuable feature to have in the protocol. At the very least, the protocol should be specified so that this is NOT ruled out. >> 3) No cache functions in intermediate routers > >I can live with this but ... I think this sort of defeats the whole purpose of IMHP, which looked like a great addition to the Mobile-IP draft. I think if state diagrams were written up to prove that this stuff would work, people wouldn't be hesitant to include it. It looks reasonable, but it looks too complicated to be included in a basic protocol. If someone would volunteer...maybe we could get the whole thing in. I would also like to say that I think Charlie is doing a great job at a thankless task. Remember, nothing gets in the final draft that the Working Group Chairs don't think they can produce rough consensus for. -Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10890; 17 Nov 93 14:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10886; 17 Nov 93 14:53 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa19705; 17 Nov 93 14:53 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11258 for mobile-ip-dist; Wed, 17 Nov 1993 11:49:48 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11234 for ; Wed, 17 Nov 1993 11:49:37 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB19291; Wed, 17 Nov 93 11:46:05 PST Date: Wed, 17 Nov 93 11:46:05 PST Message-Id: <9311171946.AB19291@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 562) draft minutes for IETF X-Orig-Sender: owner-mobile-ip@ossi.com Here is the draft minutes for the IETF. Thanks very much to Pierre Dupont for taking the minutes and writing them up. However, given that *I* am very late in forwarding this to the list, we only have a couple of days to comment on it. I will need to send it to the secretariat on Friday. Greg Minshall ----------------------------------------------------------------------- Mobile-IP WG Minutes 28th IETF - Houston, November 1993 Chairs(s) Steve Deering Greg Minshall General The Mobile-IP WG convened at the 27th IETF in Amsterdam. This group is chartered to develop or adopt architectures and protocols to support mobility within the Internet. Tuesday Nov 2. Greg Minshall provided opening remarks and a brief history of the mobile IP working group. Charlie Kunzinger gave a short presentation on the current mobile IP draft. A question/answer discussion session followed the presentation. [Note: I've included the initials of some persons next to their qestions or comments...] CK= Charlie Kunsinger SD= Steve deering GM= Greg Minshall CP= Charlie Perkins AM= Andrew Myles YR= Yakov Rekhter PK= Phil Karn TL= Tony Li DJ= Dave Johnson Q: Why not two IP addresses for MH? A:(CK) No need for two addresses A:(SD) MH can acquire pop-up address to act as its own FA Q:(TL) Does FA decrement TTL in IP header before forwarding message to MH? Will this interfere with traceroute and MH location privacy? A: general discussion ensued on security requirements and the pors/cons of TTL being decremented by FA. Issue was left for further discussion on mailing list. Q: How do two hosts with same subnet address communicate (one local, other mobile)? A: Proxy-ARP can be used to resolve addresses Q: why not use source routing instead of tunneling? A: too many problems with source routing, so it was agreed in NJ to use encapsulation Q:(PK) Can an MH be registered with more than one FA at the same time? This would allow MH to use either FA, and prevent continuous registration flip/flop between FAs when MH is on a cell boundary. A: general discussion followed, with no clear consensus on whether this would be beneficial. For further discussion on mailing list? Q:(YR) Draft document should be clear about how mobile IP breaks the IP subnet model. A: Deferred for later discussion. Q: Why use IP for registration protocol? why not use UDP? A: Discussion on 'architectural purity' vs ease of implementation followed. Some IP implementations do not provide an IP interface, while all have a UDP interface. Deferred for further discussion. Q: Can Yakov expand on subnet model question? A:(YR) The IP over Shared Media draft addresses similar problem. The traditional model assumes that only hosts with same subnet address can talk directly to each other. Mobile IP means that some hosts with same subnet ID cannot communicate directly. Also, how do mobile hosts with different subnet IDs but on same physical subnet communicate? Q: Request that an authorization type be included before all authorization fields in mobile IP messages. A: Agreed. Q:(TL) Question on Incarnation number in Agent Advertisement message. Some MH may not have non-volatile storage. Also, how is it used? A:(DJ) It is so that visiting MH can tell if FA has crashed, an therefore if it must re-register with FA. Q: Why not use Internet Security Protocol? A: No decision has been reached on this yet. Adopt a wait&see attitude with respect to IP security. It is not the mobile-ip wg's job to solve IP security problems. A suggestion was made to not include any security fields in mobile IP messages. Q: Are timer values defined? A: The units and field sizes are defined, but not the recommended values. There may be dependancies between timers that need to be considered. Q: How and when does HA advertise reachability by proxy-arp? A:(AM) HA should never advertise unless its a router also. A HA that is not a router uses proxy-ARP to intercept messages for MH. A discussion followed on whether the HA should always be a router. Q: Would like to see characteristics and behaviour of HA included in draft. A: Agreed. Q:(SD) When tunneling to FA, what happens when the MH is not being served by the FA? Does packet go back to HA? A: IMHP deals with this. Q: If address resolution mechanism is not ARP, there may be a problem using proxy-ARP. Q: Why wait for a Home-Foreign confirm before sending notification to the prior foreign agent? A: The new FA is not authorized to serve the MH until it receives the confirm message from the HA. A message to the prior FA may not be required in this case, since the HA will direct messages to the new FA as soon as it has authorized it, therefore there is no need for the old FA to inform prior FA (the HA can inform the prior FA, after it has authorized the new FA). Andew Myles gave a presentation on the IMHP draft. Topics included a definition of the MH, FA and HA elements, the HA configuration (i.e. HA is not necessarily a router), and a new element, the Cache Agent, which keeps track of [MH, FA] bindings. Other topics were security (rationale for weak security), Home subnet communication (performance reqs, routing options), and notification to the prior FA. On this final point it was mentioned that: - notification to the prior FA must be fast so that it does not become a black hole for packets - the protocol should allow the new FA to accept packets from the prior FA before the MH is authorized to use the new FA. - the MH must inform the prior FA as soon as it moves to a new FA. Q:(SD) How are loops eliminated? A: A number of alternative mechanisms exist to break routing loops. Q:(SD) How does routing work when a FA crashes? (Black Hole) A: A timeout will occur on cache entries, causing polling to the destination FA (the Cache Agent polls the FA every timeout secs) Q: How does Cache Agent get bindings? A: Snooping can be used for dumb hosts. This can be turned off in the Cache agent is desired. Q:What if MH moves from an authorized FA to an unauthorized FA? The MH will be temporarily using an unauthorized FA. A: During discussion it was pointed out that the FA may want to bill someone (HA) for the service to the MH. Therefore the new FA may not want to provide service to the MH until it is authorized to do so by the HA. Q: The Cache Agent may send redirect packets to any host. This could compromise security/privacy (e.g. location information) A: A flag could be used to prohibit route forwarding Q: What about ad-hoc networking? A: for further study Q: The cache timeout/polling mechanism may generate too much network traffic. A: Polling wouild only occur when the route is "active". ---------------------------------------------------------- Wed Nov 3 Charlie Kunzinger presented a list of outstanding issues for discussion 1. Encapsulation method. Generic or Home-grown? - We need at least one required method. - SD: argued against negotiation. - TL: mentioned there already exists an Internet Draft on encapsulation (Generic Routing Encapsulation) - DJ: stated that it had a large overhead and may not be compatible with ICMP (in terms of header size) - YR: stated that GRE was already implemented and being deployed. - SD: generic encapsulation can be used with a reason encoding (e.g. mobile IP host) - GM: Recommended group continue discussion on mailing list and will pick an encapsulation method later. 2. Foreign Agent receives forwarded message to MH for which it has no binding. What does it do with message? - issue was discussed already at last session 3. Should address fields be expanded to include address type & length? -SD: may depend upon how often packets are sent -DJ: the protocol is IP specific, address must fit into 64 ICMP bits -TL: recommends addresses be TLV fields to support multi protocols (e.g. mobile appletalk) No consensus reached. 4. Do we need to control the number or frequency of registration requests? A discussion followed on whether to allow MH to register in multiple cells (i.e. with more than one FA) and have HA duplicate messages to both FAs SD suggested that protocol should not disallow this, but recommended it be defred to advanced functionality issue list. Issue 4 left unresolved? 5. Is there a need for a retransmission timer on registration request by MH? It was suggested that the MH be allowed to retransmit request and that the FA could respond with an in-progress message if it is awaiting a response from the HA on a previous request for the MH. 6. ? [must have missed this one] 7. State diagrams in draft document? will be included in next revision 8. Should protocol allow a hierarchy of HA? should not preclude this option in draft 9. CAN TOS bit in IP header be used to identify mobile hosts? DJ: RFC 1122 suggests this is not possible Other issues raised: 10. Why can a FA terminate service to a MH? Also, HA can deregister MH. Suggested that there is no need to include FA to MH deregistration since it will time out eventually? 11. Several comments on style, packet format and byte alignment in the draft. 12. Should ICMP or UDP be used for registration protocol? After some discussion, a poll was taken on prefered method. UDP was selected by a majority of those responding. 13. Weak security: def'n needs to be included in draft 14. To what degree do we break the subnet model? Similar to problem with large public data networks (e.g. ATM). Yakov Rekhter volunteered to communicate to IAB how mobile IP will break the subnet model (and write an Internet Draft?) A discussion on the pros/cons of the intermediate Cache Agent model followed, with no consensus reached on how to proceed. Some argued it should be left out of initial draft while others argued we are close to a solution on triangle routing and we should continue with plans to merge IMHP into the draft. Documentation and Implementation milestones: the group needs a specification which can be used to implement test systems (would like spec before Christmas) Charlie Kunzinger to continue work as document editor. An Interim meeting of the mobile IP working group was proposed for January at Xerox PARC. It was suggested that implementors and spec writers should convene for 2 days.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10905; 17 Nov 93 14:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10901; 17 Nov 93 14:54 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa19718; 17 Nov 93 14:54 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11289 for mobile-ip-dist; Wed, 17 Nov 1993 11:50:31 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11265 for ; Wed, 17 Nov 1993 11:50:23 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB19291; Wed, 17 Nov 93 11:47:11 PST Date: Wed, 17 Nov 93 11:47:11 PST Message-Id: <9311171947.AB19291@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 563) Interaction between TCP and mobile IP X-Orig-Sender: owner-mobile-ip@ossi.com Ramon, etc., > Columbia's mobile IP software is not directly responsible for the long > pauses you mention. Mobile IP protocols in general introduce relatively > short interruptions in network-level communication, but TCP's congestion > avoidance and control procedures amplify these interruptions into the > much longer pauses shown in the paper. Maybe i'm fuzzyheaded on this, but my take on things is that there are going to be mobility solutions at various levels. Using wireless LAN as an example, at the lowest level, there are likely to be a number of "link layer access points" per "foreign agent". Handoffs between these LLAPs (gasp!) will be invisible to the FA. However, it is *possible* (802.11?) that the LLAPs will provide smooth handoffs for an MH by bufferring a packet when the MH goes "out of range" and then forwarding it to the new LLAP when the MH comes within range of another LLAP. Now, when you move between wires, then the FA needs to get involvded. How it gets involved is an interesting matter. For rough handoffs, the previous FA doesn't learn about the new FA (or, at least in time to forward any in-flight packets). For smoother handoffs, the previous FA knows fairly soon and can forward in-flight packets. For the smoothest handoffs, the old FA, on learning about the new FA, will engage in the *LLAP smooth handoff protocol* and acquire any packets being bufferred by LLAP's for delivery to the MH. The old FA would then readdress these packets to the new FA, and forward them along. Now, WE ARE ONLY DOING A LITTLE PIECE OF ALL THIS. In particular, we are NOT doing the piece of how the old FA engages in the LLAP smooth handoff protocol. That assumes that such a protocol exists, and even then is an implementation issue. There is another side to all of this, which is that at the link layer, there can be (somewhat) broader conspiracy to keep the transport layer (primarily) happy. For example, if a link layer only supports 143 byte packets, it may have its own (subnet) fragmentation and reassembly protocol to provide the illusion of a somewhat larger MTU (576, 1518, whatever). If a link layer has bad loss characteristics (1% drop rate, say), then it may use some sort of error correction/retransmission scheme to bring the loss characteristics up to a level that is going to make TCP (or other transports) happy. Similarly, around the issue we are discussing here, if a host keeps flipping back and forth between two cells, the link layer (for example a CDMA or CDPD) can try to provide the *illusion* to the network layer that the host isn't moving, and handle mobility at its level. (Actually, for TCP, if the host is flipping back and forth fairly rapidly, then with minimal bufferring at the LLAPs, mightn't the MH get all the packets with no retransmission?) Greg Minshall   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13456; 17 Nov 93 16:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13452; 17 Nov 93 16:11 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22291; 17 Nov 93 16:11 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA13219 for mobile-ip-dist; Wed, 17 Nov 1993 13:08:08 -0800 Reply-To: mobile-ip@ossi.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id NAA13195 for ; Wed, 17 Nov 1993 13:07:58 -0800 Received: by lager.cisco.com id AA03506 (5.67a/IDA-1.5 for MOBILE-IP@ossi.com); Wed, 17 Nov 1993 13:07:19 -0800 Date: Wed, 17 Nov 1993 13:07:19 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311172107.AA03506@lager.cisco.com> To: "Ritter, Mike" Cc: MOBILE-IP@ossi.com Subject: (mobile-ip 564) Charlie's thankless task X-Orig-Sender: owner-mobile-ip@ossi.com From: MWRITTER@applelink.apple.com (Ritter, Mike) Andrew Myles responded to Charlie's progress report as follows: >> c) Several people asked to be able to accommodate addresses larger >> than 4 bytes. I'll accommodate this by using variable length >> address fields. > >I don't recall this being decided and I think it is a terrible idea. There >are enough varible length, unaligned fields in there already without adding >more with unproven utility. I like the idea of supporting multiple address types, however, I would point out that the 'unalignment' of the packet fields is something that was definitely left open and to be decided later. I'd like to ask what the problem is here. Is someone planning on performance testing the rate at which a home agent can accept registration packets? Is 200,000 registrations per second important to ANYONE? I would make the following points and suggestions: - we don't know what we're doing - we're gonna learn by deploying - it makes sense to make the protocol sufficiently flexibile and extensible that we don't have to rev the protocol to add features - thus, the registration protocol should have maximum flexibility - we know how to build extensible protocols - we should do this for the registration protocol - to do this, all fields in the registration protocol should be encoded as TLV's - this may have the beneficial effect of actually making the registration packet smaller, as unused fields can now be simply ommitted >> e) There was a request to look at whether a mobile host can support >> several concurrent bindings simultaneously. > >This has not been fully specified by anyone and so should be left out. I am convinced that this is an extrememly valuable feature to have in the protocol. At the very least, the protocol should be specified so that this is NOT ruled out. Ditto. I would also like to say that I think Charlie is doing a great job at a thankless task. Remember, nothing gets in the final draft that the Working Group Chairs don't think they can produce rough consensus for. Double ditto. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13635; 17 Nov 93 16:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13631; 17 Nov 93 16:17 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22468; 17 Nov 93 16:17 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA13253 for mobile-ip-dist; Wed, 17 Nov 1993 13:14:09 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA13228 for ; Wed, 17 Nov 1993 13:14:02 -0800 Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA09189 for ; Wed, 17 Nov 1993 13:14:00 -0800 Received: by lager.cisco.com id AA03983 (5.67a/IDA-1.5 for mobile-ip@ossi.com); Wed, 17 Nov 1993 13:13:12 -0800 Date: Wed, 17 Nov 1993 13:13:12 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311172113.AA03983@lager.cisco.com> To: minshall@wc.novell.com Cc: mobile-ip@ossi.com Subject: (mobile-ip 565) draft minutes for IETF X-Orig-Sender: owner-mobile-ip@ossi.com Greg, One thing: the secretariat explicitly requests that the minutes NOT be in a Q/A or "he said this" format. I suggest that this be massaged into an "Issue"/"Resolution" format, and that personal references be removed. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13976; 17 Nov 93 16:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13972; 17 Nov 93 16:33 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa22967; 17 Nov 93 16:33 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA13661 for mobile-ip-dist; Wed, 17 Nov 1993 13:30:04 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id NAA13600 for ; Wed, 17 Nov 1993 13:29:52 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perk@watson.ibm.com Message-Id: <199311172129.NAA13600@rara.ossi.com> Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9505; Wed, 17 Nov 93 16:29:50 EST Date: Wed, 17 Nov 93 16:28:24 EST To: mobile-ip@ossi.com Subject: (mobile-ip 566) TLVs for mobile-IP packets X-Orig-Sender: owner-mobile-ip@ossi.com Surely this issue is not unique to the mobile-IP working group. Has there been any direction, hints, or guidelines issued by the directorate, IAB, IESG, ??? Charlie P.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16877; 17 Nov 93 20:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16873; 17 Nov 93 20:44 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa28772; 17 Nov 93 20:44 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id RAA22739 for mobile-ip-dist; Wed, 17 Nov 1993 17:41:00 -0800 Reply-To: mobile-ip@ossi.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id RAA22715 for ; Wed, 17 Nov 1993 17:40:49 -0800 Received: by lager.cisco.com id AA23187 (5.67a/IDA-1.5 for mobile-ip@ossi.com); Wed, 17 Nov 1993 17:40:14 -0800 Date: Wed, 17 Nov 1993 17:40:14 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311180140.AA23187@lager.cisco.com> To: perk@watson.ibm.com Cc: mobile-ip@ossi.com Subject: (mobile-ip 567) TLVs for mobile-IP packets X-Orig-Sender: owner-mobile-ip@ossi.com Surely this issue is not unique to the mobile-IP working group. Has there been any direction, hints, or guidelines issued by the directorate, IAB, IESG, ??? I've never seen anything from them. As it is a purely technical issue and should be dealt with by the WG, I'm not entirely surprised. In any case, I would suggest that since it's not something in the switching path of the packets, it's not a big performance hit. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17225; 17 Nov 93 21:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17221; 17 Nov 93 21:44 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa00144; 17 Nov 93 21:44 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id SAA24186 for mobile-ip-dist; Wed, 17 Nov 1993 18:43:18 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id SAA24162 for ; Wed, 17 Nov 1993 18:43:10 -0800 Received: from avalon.mpce.mq.edu.au (avalon.mpce.mq.edu.au [137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id SAA12726 for ; Wed, 17 Nov 1993 18:42:32 -0800 Message-Id: <199311180242.SAA12726@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA11405; Thu, 18 Nov 93 13:45:15 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 568) TLVs for mobile-IP packets To: mobile-ip@ossi.com Date: Thu, 18 Nov 93 13:45:14 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day Steve Parker, I seem to not get all the mailing list messages. Please to something about it as it is driving me crazy Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22277; 17 Nov 93 23:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22273; 17 Nov 93 23:23 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa02394; 17 Nov 93 23:23 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id UAA26069 for mobile-ip-dist; Wed, 17 Nov 1993 20:06:09 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id UAA26045 for ; Wed, 17 Nov 1993 20:06:00 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.4/8.6.4) with SMTP id UAA23702; Wed, 17 Nov 1993 20:05:59 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311180405.UAA23702@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: mobile-ip@ossi.com Cc: cds@ossi.com Subject: (mobile-ip 569) TLVs for mobile-IP packets Date: Wed, 17 Nov 93 20:05:58 PST X-Orig-Sender: owner-mobile-ip@ossi.com - G'day Steve Parker, - - I seem to not get all the mailing list messages. - - Please to something about it as it is driving me crazy - - Andrew - In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Even as you wrote this it was driving me crazy. For reasons that aren't clear to me, sometime between Nov 16 23:38 and Nov 17 09:56, the file containing the mailing list came up short some 200+ addresses. If you receive a second message from me directly, it means you were on the list of people who were missing from the file. The message will contain the messages you missed. Sorry for the inconvenience, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00848; 18 Nov 93 4:14 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00844; 18 Nov 93 4:14 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa02819; 18 Nov 93 4:14 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id BAA02583 for mobile-ip-dist; Thu, 18 Nov 1993 01:13:24 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id BAA02551 for ; Thu, 18 Nov 1993 01:13:11 -0800 Via: uk.ac.bristol.comms-research; Thu, 18 Nov 1993 09:12:59 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Thu, 18 Nov 93 09:12:55 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <17157.9311180912@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 570) Some thoughts on registration and handoff To: mobile-ip@ossi.com Date: Thu, 18 Nov 1993 09:12:53 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6938 X-Orig-Sender: owner-mobile-ip@ossi.com Dear all, I just received a clutch of messages that went astray - thanks to Steve Parker. There were several points related to handover and registration that I want to respond to. I've extracted the relevant bits of text: # >> e) There was a request to look at whether a mobile host can support # >> several concurrent bindings simultaneously. # > # >This has not been fully specified by anyone and so should be left out. # # I am convinced that this is an extrememly valuable feature to have in the # protocol. At the very least, the protocol should be specified so that this is # NOT ruled out. # # # Q:(PK) Can an MH be registered with more than one FA at the same time? # This would allow MH to use either FA, and prevent continuous registration # flip/flop between FAs when MH is on a cell boundary. # A: general discussion followed, with no clear consensus on whether this # would be beneficial. For further discussion on mailing list? # I am convinced that it is a useful feature as well. It *may* help to reduce the loss of service reported by Ramon when a MH has multiple candidate serving cells. This is not just a wireless LAN issue. Registration "flip-flop" may happen anyway under less favourable radio conditions. # # 4. Do we need to control the number or frequency of registration requests? # Are we able to control this? Depending on your environment and equipment one may be able to set thresholds and restrict knowledge of the available cells as far as individual MHs are concerned but the balance would be difficult to strike. # A discussion followed on whether to allow MH to register in multiple cells # (i.e. with more than one FA) and have HA duplicate messages to both FAs # SD suggested that protocol should not disallow this, but recommended it # be defred to advanced functionality issue list. # I like the term "should not disallow"! Following from the above, I think it should definitely be allowed. The capability is already present in several of the radio networks and it would be a natural implementation choice to use the facility. # # Maybe i'm fuzzyheaded on this, but my take on things is that there are # going to be mobility solutions at various levels. # No you aren't fuzzyheaded, Greg. Some time ago I said I was frustrated by some of the discussion in this area, (sorry Charles (Perkins) - I meant to reply to your private question and I hope this does the trick), because it seemed to me that several levels of mobility were being mixed in an attempt to provide an integrated solution for a particular environment (i.e the wireless LAN). I'm still not convinced that this isn't happening. # Using wireless LAN as an example, at the lowest level, there are likely to # be a number of "link layer access points" per "foreign agent". Handoffs # between these LLAPs (gasp!) will be invisible to the FA. However, it is # *possible* (802.11?) that the LLAPs will provide smooth handoffs for an MH # by bufferring a packet when the MH goes "out of range" and then forwarding # it to the new LLAP when the MH comes within range of another LLAP. # # Now, when you move between wires, then the FA needs to get involvded. How # it gets involved is an interesting matter. For rough handoffs, the # previous FA doesn't learn about the new FA (or, at least in time to forward # any in-flight packets). For smoother handoffs, the previous FA knows # fairly soon and can forward in-flight packets. # # For the smoothest handoffs, the old FA, on learning about the new FA, will # engage in the *LLAP smooth handoff protocol* and acquire any packets being # bufferred by LLAP's for delivery to the MH. The old FA would then # readdress these packets to the new FA, and forward them along. # # Now, WE ARE ONLY DOING A LITTLE PIECE OF ALL THIS. # # In particular, we are NOT doing the piece of how the old FA engages in the # LLAP smooth handoff protocol. That assumes that such a protocol exists, # and even then is an implementation issue. # # There is another side to all of this, which is that at the link layer, # there can be (somewhat) broader conspiracy to keep the transport layer # (primarily) happy. # # For example, if a link layer only supports 143 byte packets, it may have # its own (subnet) fragmentation and reassembly protocol to provide the # illusion of a somewhat larger MTU (576, 1518, whatever). # # If a link layer has bad loss characteristics (1% drop rate, say), then it # may use some sort of error correction/retransmission scheme to bring the # loss characteristics up to a level that is going to make TCP (or other # transports) happy. # # Similarly, around the issue we are discussing here, if a host keeps # flipping back and forth between two cells, the link layer (for example a # CDMA or CDPD) can try to provide the *illusion* to the network layer that # the host isn't moving, and handle mobility at its level. (Actually, for # TCP, if the host is flipping back and forth fairly rapidly, then with # minimal bufferring at the LLAPs, mightn't the MH get all the packets with # no retransmission?) # # My take is: 1. Yes, we are only doing a little piece of this. It seems to me that protocol (UDP, ICMP, SNMP - I don't mind much) should be standardised for the link layer handoff and some rules/scenarios should be devised to illustrate the relationship between link layer mobility (carrier, cell, location area, registration area), and network mobility. It is an implementation or operator decision on the strategy for a specific environment, i.e. how illusory the mobility is. 2. You have to get your handoff terminology sorted out. I now see we are talking about "rough" and "smooth". I have collected many more: fast, slow, prepared, unprepared, announced, unannounced, mobile assisted for a start. 3. The transport layer should be kept happy up to a point. From Ramon's paper it seems that you have an end-to-end problem with TCP that you can avoid with, say, X.25 PLP. Changing TCP would seem to be a tricky political problem! Are there other solutions? Some link layers may do more than others as far as residual BER, PUEM, missequencing, etc. is concerned and they *may* do enough to keep TCP happy. I wouldn't rely on it! Remember also, that while some applications are going to get it in the neck, others can cope quite happily with transport problems. Don't try too hard. 4. (From above) Registration (at network level) with multiple FAs and simultaneous transmission to/reception from those FAs should be included. It is an implementation/operator choice to use it. That'll do for now, Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02064; 18 Nov 93 8:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02060; 18 Nov 93 8:28 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa07606; 18 Nov 93 8:28 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id FAA07920 for mobile-ip-dist; Thu, 18 Nov 1993 05:27:37 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id FAA07896 for ; Thu, 18 Nov 1993 05:27:29 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perk@watson.ibm.com Message-Id: <199311181327.FAA07896@rara.ossi.com> Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5661; Thu, 18 Nov 93 08:27:25 EST Date: Thu, 18 Nov 93 08:20:08 EST To: mobile-ip@ossi.com Subject: (mobile-ip 571) Comments on minutes X-Orig-Sender: owner-mobile-ip@ossi.com The minutes seem generally fairly complete and useful. There is a discussion towards the last which confuses intermediate Cache Agents and general route optimization. > A discussion on the pros/cons of the intermediate Cache Agent model > followed, with no consensus reached on how to proceed. Some argued > it should be left out of initial draft while others argued we are > close to a solution on triangle routing and we should continue with > plans to merge IMHP into the draft. I suggest that it is reasonable to incorporate the general mechanisms for enabling route optimizations, separately from any discussion about intermediate Cache Agents. I thought that this was also the general sense of the discussion at the Working Group meeting. Is it agreeable to change the minutes to reflect this? Thanks, Charlie P.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05901; 18 Nov 93 11:16 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05897; 18 Nov 93 11:16 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12939; 18 Nov 93 11:16 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA11229 for mobile-ip-dist; Thu, 18 Nov 1993 08:15:05 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id IAA11205 for ; Thu, 18 Nov 1993 08:14:57 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311181614.IAA11205@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8101; Thu, 18 Nov 93 11:14:45 EST Date: Thu, 18 Nov 93 11:13:41 EST To: andrewm@avalon.mpce.mq.edu.au cc: mobile-ip@ossi.com Subject: (mobile-ip 572) An Update on Mobility Draft X-Orig-Sender: owner-mobile-ip@ossi.com > >> c) Several people asked to be able to accommodate addresses larger >> than 4 bytes. I'll accommodate this by using variable length >> address fields. > >I don't recall this being decided and I think it is a terrible idea. There >are enough varible length, unaligned fields in there already without adding >more with unproven utility. > Andrew, It would help if you'll elaborate on why this is a "terrible idea". >> f) There was a request to add text saying that if a mobile host acquires >> a local address dynamically (a pop-up), that it's OK for the >> mobile host to serve as its own Foreign Agent. I'll add this >> text to the draft. > >This is discussed in the IMHP document - along with its associated problems. Let me just point out that pure pragmatic considerations suggest that a mobile-ip scheme should minimize the number of *additional* components that have to be implemented and deployed in order to support mobile IP. Using DHCP and co-located MH/FA allows: (a) to eliminate the need to deploy FAs on every subnet to which a mobile host could be attached, (b) eliminate the need for the MH to FA protocol. Given the level of support for DHCP (at the recent interoperability testing some of the companies that demonstrated DHCP are Microsoft, Sun, HP, Boeing, DEC, SGI, FTP Software) and the benefits that can be achieved with DHCP and colocated FA/MH, I would suggest us to give a *very* serious consideration for placing a high priority on fully specifying a scheme for mobile IP support in conjunction with DHCP and colocated MH/FA. >Actually, we (myself, Dave and Charlie) are going to be writing the >encapsulation protocol up as a draft RFC How is that going to be related to the work within the mobile-ip WG ? Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06790; 18 Nov 93 11:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06786; 18 Nov 93 11:49 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa14122; 18 Nov 93 11:49 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA11742 for mobile-ip-dist; Thu, 18 Nov 1993 08:48:29 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id IAA11718 for ; Thu, 18 Nov 1993 08:48:21 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311181648.IAA11718@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8825; Thu, 18 Nov 93 11:48:20 EST Date: Thu, 18 Nov 93 11:47:19 EST To: tli@cisco.com cc: mobile-ip@ossi.com Subject: (mobile-ip 573) Charlie's thankless task X-Orig-Sender: owner-mobile-ip@ossi.com > >- we don't know what we're doing >- we're gonna learn by deploying Just want to add to Tony's comment the following points: 1) it would be *very unwise* (I am trying to be polite) to draw any serious conclusions about a feasibility of a particular feature based on some lab experiments that involve just few machines. The only conclusion that can be drawn from a lab experiment is that certain feature *doesn't work*. Mobile IP is a distributed routing problem complicated by its dynamic nature (due to mobility). Folks who've been working on routing learned (sometimes hard way) the relation between the lab testing (with few routers) and operational deployment (with hundreds of routers). 2) we need to learn how to "walk" before we'll learn how "to run". That argues in favor of reaching a rapid closure on the base solution, implementing it, getting experience with it, then learning what is needed to improve it, and enhancing the base (based on experience). 3) we need to focus on a solution that "maximizes return on investment". That implies, that we need to focus on a solution that while may not be perfect, minimizes the initial start-up cost, while providing sufficient functionality for a *majority* of cases. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08141; 18 Nov 93 13:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08137; 18 Nov 93 13:03 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa16226; 18 Nov 93 13:02 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA13672 for mobile-ip-dist; Thu, 18 Nov 1993 09:59:03 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id JAA13648 for ; Thu, 18 Nov 1993 09:58:55 -0800 Received: from alink-gw.apple.com (alink-gw.apple.com [17.255.0.18]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id JAA15209 for ; Thu, 18 Nov 1993 09:58:54 -0800 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA12549; Thu, 18 Nov 93 09:58:11 -0800 for MOBILE-IP@OSSI.COM Date: 18 Nov 93 17:47 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ritter, Mike" Subject: (mobile-ip 574) Comments o To: MOBILE-IP@ossi.com Message-Id: <753645491.1529393@AppleLink.Apple.COM> X-Orig-Sender: owner-mobile-ip@ossi.com Charlie, That was also my impression, but then you always remember what you want to hear. -Mike PS: I still think that intermediate cache agents are the way to go, if they really work. ---------------------------------------------------------------------------- I suggest that it is reasonable to incorporate the general mechanisms for enabling route optimizations, separately from any discussion about intermediate Cache Agents. I thought that this was also the general sense of the discussion at the Working Group meeting. Is it agreeable to change the minutes to reflect this? Thanks, Charlie P.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10821; 18 Nov 93 14:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10817; 18 Nov 93 14:44 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa19068; 18 Nov 93 14:44 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA15710 for mobile-ip-dist; Thu, 18 Nov 1993 11:42:39 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id LAA15686 for ; Thu, 18 Nov 1993 11:42:31 -0800 Received: from uswat.advtech.uswest.com (firewall-user@uswat.advtech.uswest.com [130.13.16.1]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id LAA15782 for ; Thu, 18 Nov 1993 11:42:29 -0800 Received: from atqm.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA11553 (5.65c/IDA-1.4.4 for ); Thu, 18 Nov 1993 12:42:26 -0700 Message-Id: <199311181942.AA11553@uswat.advtech.uswest.com> Date: 18 Nov 1993 12:39:31 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Penners Subject: (mobile-ip 575) Extension to the Draft To: mobileip X-Orig-Sender: owner-mobile-ip@ossi.com Subject: Time:12:37 PM OFFICE MEMO Extension to the Draft Date:11/18/93 Hi all, I apologize if my comments the other day seemed disrespectful of Charlie K's work. It was not my intention. He has played a key role in our progress. A point that I was trying to make was similar to Yakov's, just not nearly as elegant. >2) we need to learn how to "walk" before we'll learn how "to run". >That argues in favor of reaching a rapid closure on the base >solution, implementing it, getting experiencewith it, then learning >what is needed to improve it, >and enhancing the base (based on experience). ^^^^ One of the points I was trying to make was that we need a solid base. To me, this means having the hooks necessary to allow new enhancements, not adding a lot of features. >3) we need to focus on a solution that "maximizes return on >investment". That implies, that we need to focus on a solution that >while may not be perfect, minimizes the initial start-up cost, while >providing sufficient functionality for a *majority* of cases. Here are a few of the features that have been proposed. 1) Triangle Leg Elimination 2) Temporary Home Agents (T-HAs) 3) Pop-Ups 4) Soft hand-off If we add them all to the base protocol we will have a complex protocol, but if we identify the hooks necessary to implement them, we may have a nice protocol that can be enhanced with new unforeseen features. John P.S. I personally like Temporary Home Agents and Soft Hand-off.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12105; 18 Nov 93 15:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12101; 18 Nov 93 15:38 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa20611; 18 Nov 93 15:38 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA17502 for mobile-ip-dist; Thu, 18 Nov 1993 12:32:51 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id MAA17476 for ; Thu, 18 Nov 1993 12:32:35 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311182032.MAA17476@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2419; Thu, 18 Nov 93 15:32:32 EST Date: Thu, 18 Nov 93 15:31:02 EST To: jpenners@atqm.advtech.uswest.com cc: mobile-ip@ossi.com Subject: (mobile-ip 576) Extension to the draft X-Orig-Sender: owner-mobile-ip@ossi.com >Here are a few of the features that have been proposed... When evaluating these features, we need to take a very careful look at how they'll impact TCP behavior. While conceptually TCP is prepared to deal with lost data and variances in the round-trip time, in practice TCP performance may be *less than satisfactory* in presence of packet losses and/or sufficiently wide variance of the round-trip time (for some of the data on this subject see "The Effects of Mobility on Reliable Transport Protocols" by Ramon Caceres and Livin Iftode). So, let me suggest that while evaluating any particular feature for its suitability for mobile IP, an essential component of such an evaluation should be the analysis of the feature's impact on packet losses and round-trip time variance. Yakov Rekhter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12576; 18 Nov 93 16:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12572; 18 Nov 93 16:13 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa21722; 18 Nov 93 16:13 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA19301 for mobile-ip-dist; Thu, 18 Nov 1993 13:12:13 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA19277 for ; Thu, 18 Nov 1993 13:12:04 -0800 Received: from avalon.mpce.mq.edu.au (avalon.mpce.mq.edu.au [137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA16205 for ; Thu, 18 Nov 1993 13:12:00 -0800 Message-Id: <199311182112.NAA16205@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA11886; Fri, 19 Nov 93 08:15:02 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 577) Re: An Update on Mobility Draft To: yakov@watson.ibm.com Date: Fri, 19 Nov 93 8:15:01 EDT Cc: mobile-ip@ossi.com Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day Yakov, Re: fixed length vs variable length address fields > It would help if you'll elaborate on why this is a "terrible idea". Many parts of the IMHP have been constrained by IPv4. IMHP will look very different with other protocols. Indeed with SIPP loose source routing will be used. Therefore I am positive that what we come up with will only be used with IPv4. Any flexibility we put into the design will be a waste of time and only makes life more complicated for no gain. Re:popups > Let me just point out that pure pragmatic considerations suggest > that a mobile-ip scheme should minimize the number of *additional* > components that have to be implemented and deployed in order to > support mobile IP. Yes, and this is one of the criteria in my comparison papers. > Using DHCP and co-located MH/FA allows: (a) to > eliminate the need to deploy FAs on every subnet to which a mobile > host could be attached, (b) eliminate the need for the MH to FA protocol. > Given the level of support for DHCP (at the recent interoperability > testing some of the companies that demonstrated DHCP are Microsoft, Sun, > HP, Boeing, DEC, SGI, FTP Software) and the benefits that can > be achieved with DHCP and colocated FA/MH, I would suggest us to > give a *very* serious consideration for placing a high priority > on fully specifying a scheme for mobile IP support > in conjunction with DHCP and colocated MH/FA. Yes, I agree with all this. > >Actually, we (myself, Dave and Charlie) are going to be writing the > >encapsulation protocol up as a draft RFC > > How is that going to be related to the work within the mobile-ip WG ? Good question! But we have been talking to the Chairs about it and will also be talking to Tony Li. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12625; 18 Nov 93 16:16 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12621; 18 Nov 93 16:16 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa21847; 18 Nov 93 16:16 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA19341 for mobile-ip-dist; Thu, 18 Nov 1993 13:16:06 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA19317 for ; Thu, 18 Nov 1993 13:15:57 -0800 Received: from avalon.mpce.mq.edu.au (avalon.mpce.mq.edu.au [137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA16209 for ; Thu, 18 Nov 1993 13:15:49 -0800 Message-Id: <199311182115.NAA16209@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA11898; Fri, 19 Nov 93 08:18:58 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 578) Extension to the Draft To: mobile-ip@ossi.com Date: Fri, 19 Nov 93 8:18:57 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day John, > One of the points I was trying to make was that we need a solid > base. To me, this means having the hooks necessary to allow new > enhancements, not adding a lot of features. Yes, but as I understood Houston the base include TLE. > Here are a few of the features that have been proposed. > 1) Triangle Leg Elimination > 2) Temporary Home Agents (T-HAs) > 3) Pop-Ups > 4) Soft hand-off > If we add them all to the base protocol we will have a complex > protocol, but if we identify the hooks necessary to implement them, > we may have a nice protocol that can be enhanced with new unforeseen > features. Trouble with the hooks approach is that you invariably get them wrong unless you fully specify the feature to start with - if you do that you may as well include them. > P.S. I personally like Temporary Home Agents and Soft Hand-off. Personally I like Triangle Leg Elimination and Pop-Ups :) Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12811; 18 Nov 93 16:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12807; 18 Nov 93 16:40 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22559; 18 Nov 93 16:40 EST Received: from rara.ossi.com by IETF.CNRI.Reston.VA.US id aa12802; 18 Nov 93 16:40 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA19981 for mobile-ip-dist; Thu, 18 Nov 1993 13:36:14 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id NAA19933 for ; Thu, 18 Nov 1993 13:36:05 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311182136.NAA19933@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3423; Thu, 18 Nov 93 16:35:52 EST Date: Thu, 18 Nov 93 16:34:08 EST To: andrewm@avalon.mpce.mq.edu.au cc: mobile-ip@ossi.com Subject: (mobile-ip 579) An Update on Mobility Draft X-Orig-Sender: owner-mobile-ip@ossi.com Ref: Your note of Fri, 19 Nov 93 8:15:01 EDT >Many parts of the IMHP have been constrained by IPv4. IMHP will >look very different with other protocols. Andrew, We are talking about two different things. I am talking about the document of the mobile-ip WG with Charlie Kunzinger as the editor. You are talking about IMHP. It wasn't my intention to get into the IMHP discussion. >Indeed with SIPP loose soure routing will be used. The fact that SIPP is currently planning to use loose source routing as a packet forwarding mechanism is completely orthogonal to the discussion about how location information is acquired and passed between various entities. You are confusing packet forwarding with routing information distribution (after all, location information is nothing more than routing information). >Therefore, I am positive that what we come up with will only >be used with IPv4. There are other *existing* network layer protocols, besides IPv4 (*regardless* of whether people acknowledge their existence or not). Therefore, it would certainly be nice (at least from a vendor's point of view) if the mobile-ip working group would come up with a solution that could be easily adoptable to other existing network layer protocols, as well as to IPng. >Any flexibility we put into the design will be >a waste of time and only makes life more complicated for no gain. It may be "waste of time" for folks who choose to claim IPv4 as *the only* network layer protocol that has relevance in the networking marketplace. It will be quite a gain, though, for vendors who build products to be sold in the networking market. Yakov Rekhter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13943; 18 Nov 93 17:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13939; 18 Nov 93 17:37 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24462; 18 Nov 93 17:37 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA21495 for mobile-ip-dist; Thu, 18 Nov 1993 14:35:16 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id OAA21439 for ; Thu, 18 Nov 1993 14:34:57 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB24620; Thu, 18 Nov 93 14:31:40 PST Date: Thu, 18 Nov 93 14:31:40 PST Message-Id: <9311182231.AB24620@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 581) An Update on Mobility Draft.... X-Orig-Sender: owner-mobile-ip@ossi.com Andrew, >> e) There was a request to look at whether a mobile host can support >> several concurrent bindings simultaneously. I think this might be >> feasible--I'll add a flag to say if multiiple bindings are supported, >> in the Mobile Request message. However, this means that we can no >> longer necessarily flush an old binding as soon as a new one is >> received. This may mean that the mobile Host itself will need to >> terminate old bindings by sending a Mobile Request that specifically >> calls out the binding to be terminated (when several may be active). >> (==>I think I can work out the details, but if it gets too >> complicated, I may abandon this function) > >This has not been fully specified by anyone and so should be left out. > >As a side note: I am not sure it the editor should be adding features. If he >should then it defeats the original purpose of having an editor - to take it >out the hands of those that really care. (This is not a swipe at you >Charlie) The point of the editor is to edit. This includes generating text where necessary (in order to have something to edit!). This includes generating protocol where necessary (in order to have some text to write about to then edit!). >> f) There was a request to add text saying that if a mobile host acquires >> a local address dynamically (a pop-up), that it's OK for the >> mobile host to serve as its own Foreign Agent. I'll add this >> text to the draft. > >This is discussed in the IMHP document - along with its associated problems. If you have a point to make, please make it on the list. >> g) We agreed to specify an encapsulation technique to be used for >> supporting mobility. When I left the IETF, I believe that Charlie >> Perkins was going to talk to Tony Li to reconcile concerns about >> the two proposals that were discussed at the IETF. I'll wait to >> hear their recommendations; if no agreement is reached, I'll >> simply pick a method and include it in the draft. > >Actually, we (myself, Dave and Charlie) are going to be writing the >encapsulation protocol up as a draft RFC. Good. I'd like to make sure that Tony Li is involved in this process, if only to say "yes, the requirements *ARE* different, so GRE doesn't work. This is a group process. Tony is part of the group. You are part of the group. So, group. >> h) We agreed to carry the mobility messages as UDP messages, and I've >> changed the packet formats accordingly. >I asume you are using ICMP for at least some of the packets. Which ones? >> i) Triangle Route Elimination: I spent some time with Perkins and >> Johnson outside the meeting to try to decide what to do. > ^^^^^^^ > Myles Wonderful. >> Here's a rough outline of what seemed reasonable to me: >> 1) I'll add messages for Binding Updates and Binding >> Acknowledgements >What about Binding Request/Reply as in IMHP. Who cares what we *call* the messages? >> 2) Home Agent will send out Binding Updates, including a >> 'time-to-live" field. NOTE: I DON'T BELEIVE THAT WE'VE >> COME UP WITH ANY WAY FOR A CH TO INDICATE THAT IT CAN >> HANDLE SUCH BINDING UPDATES===> If anyone has a suggestion, >> let me know. >Actually this is not what you want. You really want an indication that >you cannot habdle them. I assume that what you are (cryptically!) saying is that if the "binding update" message is sent to a UDP port, and an ICMP "port unreachable" comes back, or a UDP "binding update not supported" message comes back, then the sender of the binding update can cache the fact that that host doesn't grok binding update messages? If so, i think this is a *VERY GOOD POINT*. >> 5) OPEN ISSUE: Should Home Agent be required to retract any >> previously advertised binding when the binding becomes invalid? >> I don't recall that this issue was discussed either at the >> meeting or in the IMHP paper? >This is not an open issue. The Sony protocol proved the folly of attempting >this. One possibility here would be to have the *MH* send the updates when a binding changes. Thoughts? What, if anything, in the Sony protocol might invalidate that approach? (In fact, how did the Sony protocol prove the folly of having the HA invalidate the bindings?) >> l) I'll add methods to break the Foreign Agent/Home Agent loop that >> several people commented on. >Would you like to tell us what they are? I suggested two methods in my talk >at the IETF - do you have any other ideas? I think it is reasonable to let Charlie write up some text and then comment on what is in the text. Greg Minshall   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13953; 18 Nov 93 17:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13949; 18 Nov 93 17:37 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24469; 18 Nov 93 17:37 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA21677 for mobile-ip-dist; Thu, 18 Nov 1993 14:35:52 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id OAA21592 for ; Thu, 18 Nov 1993 14:35:38 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB24620; Thu, 18 Nov 93 14:32:27 PST Date: Thu, 18 Nov 93 14:32:27 PST Message-Id: <9311182232.AB24620@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 582) draft minutes for IETF X-Orig-Sender: owner-mobile-ip@ossi.com Tony, At 1:13 PM 11/17/93 -0800, Tony Li wrote: >One thing: the secretariat explicitly requests that the minutes NOT be >in a Q/A or "he said this" format. I suggest that this be massaged >into an "Issue"/"Resolution" format, and that personal references be >removed. In the future, i will try to remember to ask the notetaker(s) to use this format. I actually *know* this, but it slips my mind. Thanks for reminding me. Unfortunately, i think *THIS* set of notes is going to go in in the current format (just due to my own time constraints between now and tomorrow am). Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13963; 18 Nov 93 17:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13959; 18 Nov 93 17:37 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24476; 18 Nov 93 17:37 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA21846 for mobile-ip-dist; Thu, 18 Nov 1993 14:36:28 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id OAA21818 for ; Thu, 18 Nov 1993 14:36:17 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB24620; Thu, 18 Nov 93 14:33:06 PST Date: Thu, 18 Nov 93 14:33:06 PST Message-Id: <9311182233.AB24620@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 583) Charlie's thankless task X-Orig-Sender: owner-mobile-ip@ossi.com All, At 11:47 AM 11/18/93 -0500, yakov@watson.ibm.com wrote: >> >>- we don't know what we're doing >>- we're gonna learn by deploying > >Just want to add to Tony's comment the following points: I heartily endorse Yakov's comments (lab tests vs. real life; walk before run; minimize initial start-up cost). And, then i'll use Yakov's comments to suggest that we ditch using TLV's to represent network addresses in packets. TLV's are more complicated. We should be striving for simple. What if the receiver doesn't grok the TLV format? So, you need new error replies. Etc. Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14016; 18 Nov 93 17:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14012; 18 Nov 93 17:39 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa24526; 18 Nov 93 17:39 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA22021 for mobile-ip-dist; Thu, 18 Nov 1993 14:38:15 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id OAA21996 for ; Thu, 18 Nov 1993 14:38:05 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB24620; Thu, 18 Nov 93 14:34:30 PST Date: Thu, 18 Nov 93 14:34:30 PST Message-Id: <9311182234.AB24620@wc.novell.com> To: Alistair Munro Subject: (mobile-ip 585) Some thoughts on registration and handoff Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Alistair, ># 4. Do we need to control the number or frequency of registration requests? >Are we able to control this? Depending on your environment and equipment >one may be able to set thresholds and restrict knowledge of the available >cells as far as individual MHs are concerned but the balance would be >difficult to strike. One question is whether in designing the protocol we can add mechanisms which would reduce the frequency of registration requests, especially to the home agent. Yakov Rekhter and John Penners have suggested one way of doing this, using (if i remember correctly) a "temporary home agent" that a mobile host would bind to in a given domain. Steve Deering and i each have a slightly different slant. I will describe my idea (i think that Steve's is reasonably close). The suggestion is that the "care of address" (COA) be decoupled from the address of the "foreign agent" (FA) in all registration, etc., packets. The home agent, and any "mobile aware" "correspondent hosts" (CHs) would keep a binding of (home address, care of address), rather than the current (home address, foreign agent address). By doing this decoupling, a system can be implemented which sets COA := FA address. This results in a system in which equivalent to the currently proposed system, in which every change of FA requires a registration with the HA. But, a site can also generate a system in which the COA is not tied to a given FA, but rather addresses (some agent or agents at) the site itself. In this method, the MH can sequentially register with different FA's at the site without having to send a registration update back to the HA. (To implement this at a site would require using a protocol which we aren't specifying. One possibility would be to use host routes in the site. The other is to have a registration protocol between the foreign agent and the care of address agent so that packets arriving at the latter would be forwarded to the former.) This concept was briefly discussed at the interim WG meeting in September and the consensus there was that it didn't seem that important. (I humbly disagree!) >3. The transport layer should be kept happy up to a point. From Ramon's > paper it seems that you have an end-to-end problem with TCP that you can > avoid with, say, X.25 PLP. Changing TCP would seem to be a tricky > political problem! Are there other solutions? I (in my supreme ignorance!) would be interested in hearing how X.25 PLP would deal with this. > Some link layers may do more than others as far as residual BER, PUEM, > missequencing, etc. is concerned and they *may* do enough to keep TCP happy. > I wouldn't rely on it! I wouldn't rely on those link layers being all that successful for general purpose mobile computing! > Remember also, that while some applications are going to get it in the > neck, others can cope quite happily with transport problems. Don't try too > hard. Well, yes, this is the other side of the argument. Some link layers may only support a small percentage of applications running over specialized transport protocols (things like pagers, etc.). Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14702; 18 Nov 93 19:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14698; 18 Nov 93 19:15 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa26918; 18 Nov 93 19:15 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id QAA25000 for mobile-ip-dist; Thu, 18 Nov 1993 16:14:06 -0800 Reply-To: mobile-ip@ossi.com Received: from avalon.mpce.mq.edu.au (avalon.mpce.mq.edu.au [137.111.238.12]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id QAA24976 for ; Thu, 18 Nov 1993 16:13:39 -0800 Message-Id: <199311190013.QAA24976@rara.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12113; Fri, 19 Nov 93 11:15:14 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 591) An Update on Mobility Draft To: mobile-ip@ossi.com Date: Fri, 19 Nov 93 11:15:11 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day Yakov, > >Many parts of the IMHP have been constrained by IPv4. IMHP will > >look very different with other protocols. > We are talking about two different things. I am talking about > the document of the mobile-ip WG with Charlie Kunzinger as the editor. > You are talking about IMHP. It wasn't my intention to get into > the IMHP discussion. I was under the impression the WG decided that merging them was a good idea??? Even so I will restate what I said before as "the official draft design has been constrained by IPv4" > >Indeed with SIPP loose soure routing will be used. > > The fact that SIPP is currently planning to use loose source routing > as a packet forwarding mechanism is completely orthogonal to the > discussion about how location information is acquired and passed > between various entities. You are confusing packet forwarding > with routing information distribution (after all, location > information is nothing more than routing information). I agree with you in part only. Loose source routes can contain information that can be used on the reverse path. So in fact the two functions can be combined in certain situations - but not in IPv4. So in actual fact I was not confused at all :) > >Therefore, I am positive that what we come up with will only > >be used with IPv4. > > There are other *existing* network layer protocols, besides > IPv4 (*regardless* of whether people acknowledge their existence > or not). Therefore, it would certainly be nice (at least from > a vendor's point of view) if the mobile-ip working group would come > up with a solution that could be easily adoptable to other existing network > layer protocols, as well as to IPng. Elements will be transferable but I doubt the whole will be. It would be nice if I was wrong however. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14763; 18 Nov 93 19:24 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14759; 18 Nov 93 19:24 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa27097; 18 Nov 93 19:24 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id QAA25304 for mobile-ip-dist; Thu, 18 Nov 1993 16:23:34 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id QAA25279 for ; Thu, 18 Nov 1993 16:23:17 -0800 Received: from avalon.mpce.mq.edu.au (avalon.mpce.mq.edu.au [137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id QAA16928 for ; Thu, 18 Nov 1993 16:23:00 -0800 Message-Id: <199311190023.QAA16928@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12135; Fri, 19 Nov 93 11:26:00 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 594) An Update on Mobility Draft.... To: mobile-ip@ossi.com Date: Fri, 19 Nov 93 11:25:59 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day Greg, > >Actually, we (myself, Dave and Charlie) are going to be writing the > >encapsulation protocol up as a draft RFC. > > Good. I'd like to make sure that Tony Li is involved in this process, if > only to say "yes, the requirements *ARE* different, so GRE doesn't work. > This is a group process. Tony is part of the group. You are part of the > group. So, group. We have already agreed with you (in Houston) that is what we are going to do and I promise (cross my heart) that we will. In fact we have already talked in Tony informally about it. > >What about Binding Request/Reply as in IMHP. > > Who cares what we *call* the messages? The issue is not what we call them but how many there are. I think we need four message types, others only want two or three. I don't care what we call things either > >> 2) Home Agent will send out Binding Updates, including a > >> 'time-to-live" field. NOTE: I DON'T BELEIVE THAT WE'VE > >> COME UP WITH ANY WAY FOR A CH TO INDICATE THAT IT CAN > >> HANDLE SUCH BINDING UPDATES===> If anyone has a suggestion, > >> let me know. > > >Actually this is not what you want. You really want an indication that > >you cannot habdle them. > > I assume that what you are (cryptically!) saying is that if the "binding > update" message is sent to a UDP port, and an ICMP "port unreachable" comes > back, or a UDP "binding update not supported" message comes back, then the > sender of the binding update can cache the fact that that host doesn't grok > binding update messages? If so, i think this is a *VERY GOOD POINT*. That is one way to do it that we have discussed at various times. Another was Peirre Duponts method of using the TOS bits (this has backward compatibility problems) > One possibility here would be to have the *MH* send the updates when a > binding changes. Thoughts? Assuming the MH knew who had bindings? This is not possible in general. > What, if anything, in the Sony protocol might > invalidate that approach? (In fact, how did the Sony protocol prove the > folly of having the HA invalidate the bindings?) The main problem was the update did not work in the general case reducing the protocol to one that is very dependent on timers. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15235; 18 Nov 93 20:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15231; 18 Nov 93 20:48 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa28690; 18 Nov 93 20:48 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id RAA27797 for mobile-ip-dist; Thu, 18 Nov 1993 17:47:03 -0800 Reply-To: mobile-ip@ossi.com Received: from eegw.ee.sunysb.edu (sbee3b.eng.sunysb.edu [129.49.27.5]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id RAA27773 for ; Thu, 18 Nov 1993 17:46:54 -0800 Received: from roger.ee.sunysb.edu by eegw.ee.sunysb.edu (4.0/SMI-4.0) id AA03329; Thu, 18 Nov 93 20:46:14 EST Received: from jessica.ee.sunysb.edu by roger.ee.sunysb.edu (4.1/SMI-4.1) id AA02211; Thu, 18 Nov 93 20:45:11 EST Date: Thu, 18 Nov 93 20:45:11 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jiang Hua Message-Id: <9311190145.AA02211@roger.ee.sunysb.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 595) Charlie's thankless task X-Orig-Sender: owner-mobile-ip@ossi.com sorry, a test   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15439; 18 Nov 93 21:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15435; 18 Nov 93 21:39 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa29659; 18 Nov 93 21:39 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id SAA29030 for mobile-ip-dist; Thu, 18 Nov 1993 18:37:44 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id SAA29006 for ; Thu, 18 Nov 1993 18:37:36 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB25442; Thu, 18 Nov 93 18:34:25 PST Date: Thu, 18 Nov 93 18:34:25 PST Message-Id: <9311190234.AB25442@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 596) Minutes X-Orig-Sender: owner-mobile-ip@ossi.com All, With respect to the following note i sent regarding the minutes: >Unfortunately, i think *THIS* set of notes is going to go in in the current >format (just due to my own time constraints between now and tomorrow am). After sending the above, i am worried that i may have conveyed the wrong impression. Pierre Dupont, the taker of the minutes, was *very* punctual in getting the draft minutes to me. I, because of being out of town, etc., was very remiss in going over them, making minor corrections, and getting them out in a timely manner to the list for everyone's review. Thus, that the minutes are late, and can't be re-done, is solely my fault. Greg Minshall, co-chair for administrivia   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00538; 19 Nov 93 2:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00534; 19 Nov 93 2:47 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa01155; 19 Nov 93 2:37 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id XAA04896 for mobile-ip-dist; Thu, 18 Nov 1993 23:34:59 -0800 Reply-To: mobile-ip@ossi.com Received: from vtt.fi (vtt.fi [130.188.1.1]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id XAA04872 for ; Thu, 18 Nov 1993 23:34:52 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hakan.Mitts@vtt.fi Received: by vtt.fi id AA06853 (5.67a8+/IDA-1.5 for mobile-ip@ossi.com); Fri, 19 Nov 1993 09:31:09 +0200 Message-Id: <199311190731.AA06853@vtt.fi> Date: Fri, 19 Nov 93 09:30:05 -0200 To: mobile-ip@ossi.com Subject: (mobile-ip 597) Comment on decoupling COA and FA X-Charset: LATIN1 X-Char-Esc: 29 X-Popmail-Charset: European X-Orig-Sender: owner-mobile-ip@ossi.com Hello Greg proposed in a mail: >The suggestion is that the "care of address" (COA) be decoupled from >the address of the "foreign agent" (FA) in all registration, etc., >packets. The home agent, and any "mobile aware" "correspondent hosts" >(CHs) would keep a binding of (home address, care of address), rather >than the current (home address, foreign agent address). >But, a site can also generate a system in which the COA is not tied to >a given FA, but rather addresses (some agent or agents at) the site >itself. In this method, the MH can sequentially register with different >FA's at the site without having to send a registration update back to >the HA. >(To implement this at a site would require using a protocol which we >aren't specifying. One possibility would be to use host routes in the >site. The other is to have a registration protocol between the foreign >agent and the care of address agent so that packets arriving at the >latter would be forwarded to the former.) I heartyly agree with this as this seems to be a way to get around having one FA per subnet as (in addition to the POP-UP/FA thing). But then the protocols between COA-agent/FA :-) and the MH gets more compli- caed I guess? R, Hakan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01086; 19 Nov 93 4:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01082; 19 Nov 93 4:45 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa03402; 19 Nov 93 4:45 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id BAA07612 for mobile-ip-dist; Fri, 19 Nov 1993 01:41:05 -0800 Reply-To: mobile-ip@ossi.com Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id BAA07588 for ; Fri, 19 Nov 1993 01:40:52 -0800 Via: uk.ac.bristol.comms-research; Fri, 19 Nov 1993 09:40:39 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Fri, 19 Nov 93 09:40:34 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alistair Munro Message-Id: <5468.9311190940@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 598) Keeping the transport layer happy To: mobile-ip@ossi.com Date: Fri, 19 Nov 1993 09:40:30 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3873 X-Orig-Sender: owner-mobile-ip@ossi.com Grep, Thanks for your comments on registration and the transport layer. Here's a response on keeping the transport layer happy. > >3. The transport layer should be kept happy up to a point. From Ramon's > > paper it seems that you have an end-to-end problem with TCP that you can > > avoid with, say, X.25 PLP. Changing TCP would seem to be a tricky > > political problem! Are there other solutions? > > I (in my supreme ignorance!) would be interested in hearing how X.25 PLP > would deal with this. > At the risk of causing some astonishment, the X.25 PLP is functionally much the same as TCP in the "established" state. (By which I mean that the differences aren't relevant to the argument). The sliding window is packet-based in X.25 PLP so there is a coarser level of granularity. It's used for the same goals of keeping transmission going efficiently and achieving flow control. Architecturally, the PLP is defined only between the end system (ES) and the first intermediate system (IS): what goes on between the ISs is their own business. In particular, part of their business is congestion management: the ES is only aware that its window hasn't been updated when the IS is battling with the rest of the network. In the absence of any external intervention, the ES may carry on and retransmit to the IS or it may not (this is a user-requested, implementor/operator choice). Duplicate packets received by the IS are not forwarded, just discarded. In the case of a MH link failure, the only relationship that is affected is the ES - IS that used the link. An indication of link failure can be used to freeze the internal timers at the ES or IS until the link comes back (if it does). The indication doesn't need to be propagated through the network - but ISs may choose to between themselves for internal management if it's possible in the infrastructure. There *are* end-to-end aspects of an X.25 PLP connection which would cause problems; however these can be negotiated out when the connection is connection is established. > > Some link layers may do more than others as far as residual BER, PUEM, > > missequencing, etc. is concerned and they *may* do enough to keep TCP happy. > > I wouldn't rely on it! > > I wouldn't rely on those link layers being all that successful for general > purpose mobile computing! > > > Remember also, that while some applications are going to get it in the > > neck, others can cope quite happily with transport problems. Don't try too > > hard. > > Well, yes, this is the other side of the argument. Some link layers may > only support a small percentage of applications running over specialized > transport protocols (things like pagers, etc.). > I don't want to bore you too much again with TETRA but it's partly my baby so I'll take the liberty. The link service provides BREAK (when MAC traffic is no longer possible) and RESUME (when the MAC is available again) indications to its client users at the MH and the base-station. These users can do something with the indications or not: we don't care. It was a battle to get this view put across: there was an opinion that behaviour should be more constrained, that the link layer should flounder around doing retransmissions, etc. Against this was the view that we don't really know what is going to happen, and should do the minimum necessary until we understand the constraints properly. I would be interested to hear suggestions for TCP or IP. A comparison with ISO CLNP + TP class 4 might be useful? I could make several suggestions, but I'd like to hear what people think. Regards, Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02140; 19 Nov 93 8:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02136; 19 Nov 93 8:18 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa07606; 19 Nov 93 8:18 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id FAA12671 for mobile-ip-dist; Fri, 19 Nov 1993 05:06:53 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id FAA12647 for ; Fri, 19 Nov 1993 05:06:45 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311191306.FAA12647@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0235; Fri, 19 Nov 93 08:06:42 EST Date: Fri, 19 Nov 93 08:04:38 EST To: minshall@wc.novell.com cc: mobile-ip@ossi.com Subject: (mobile-ip 599) Charlie's thankless task X-Orig-Sender: owner-mobile-ip@ossi.com >I think the sense of the WG was that fields should be aligned. Greg, I tend to disagree with you on this. It is certainly *nice* when fields are aligned, however, I don't think this should be a hard requirement. To give you an example, if it is possible to get an alignment by just rearranging fields within a packet, then I go for it. However, if the alignment is used as an argument against any variable length field, then I would disagree with this argument. I also think that using padding as a way to get the alignment is not a good idea in general. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03016; 19 Nov 93 9:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03012; 19 Nov 93 9:06 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa09201; 19 Nov 93 9:06 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id GAA13835 for mobile-ip-dist; Fri, 19 Nov 1993 06:05:26 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id GAA13811 for ; Fri, 19 Nov 1993 06:05:18 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311191405.GAA13811@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0645; Fri, 19 Nov 93 09:05:11 EST Date: Fri, 19 Nov 93 09:03:58 EST To: minshall@wc.novell.com cc: mobile-ip@ossi.com Subject: (mobile-ip 600) TLV's X-Orig-Sender: owner-mobile-ip@ossi.com >And, then I'll use Yakov's comments to suggest that we ditch >using TLV's to represent network addresses in packets. TLV's >are more complicated. We should be striving for simple. What >if the receiver doesn't grok the TLV format ? So, you need >new error replies. Etc. Greg, You may be correct that TLV's are more complicated. However, their complexity should be analysed within the specific context they are used. So, let's first talk about using TLV's to carry network addresses. This would allow the same routing protocol (like the registration protocol within mobile-ip) to be used in conjunction with different network layer protocols. So, here we have a trade-off between re-using the same protocol, but paying extra complexity for TLV's or using multiple protocols and have network addresses encoded as fixed length fields. With respect to the example you gave when "the receiver doesn't grok the TLV", I'd like to understand how is that different from the receiver that "doesn't grok" a particular fixed length field (e.g. due to bad/invalid semantics of the field). The second point I'd like to make is that TLV's allow a rather straightforward mechanism for protocol extensibility. That is, extensibility is achieved by allowing optional parameters, where each parameter is encoded as a TLV entity. Any proponents of outlawing TLV's all together, should indicate alternative mechanisms for extensibility (or make an explicit disclaimer that the extensibility is viewed as a non-goal). Finally, going back to your original argument that processing of TLV's are more complicated, as compared to fixed format packets. While this assertion may be correct, the assertion should not be taken in a vacuum. The actual impact of this extra complexity depends *very much* on the environment. For example, the impact on processing overhead of using TLV's for encoding routing information carried by a routing protocol is *significantly less* than the impact of using TLV's carried by data packets (this is because the volume of routing information is significantly lower than the volume of data traffic). So, one may wonder whether the impact of processing TLV's for encoding routing information in mobile-ip should be taken into the consideration or not. I am aware of at least one routing protocol (which is widely deployed in the Internet for quite a while) that *extensively* uses TLV's for encoding routing information. So far we didn't hear any complains about TLV's causing problems in this protocol. Since the IETF believes in the *operational* experience, I would suggest that the experience with this protocol should be used to ditch the discussion about the additional overhead associated with using TLV's for encoding routing information. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08662; 19 Nov 93 13:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08658; 19 Nov 93 13:32 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa23580; 19 Nov 93 13:32 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA18944 for mobile-ip-dist; Fri, 19 Nov 1993 10:28:47 -0800 Reply-To: mobile-ip@ossi.com Received: from picard.comdex.cellular.com ([155.174.28.50]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA18920 for ; Fri, 19 Nov 1993 10:28:37 -0800 Received: from mccaw22 (think2.comdex.cellular.com) by picard.comdex.cellular.com with SMTP id AA07626 (5.67a/IDA-1.5 for ); Fri, 19 Nov 1993 10:28:05 -0800 Message-Id: <199311191828.AA07626@picard.comdex.cellular.com> Date: Sat, 28 Aug 1993 10:03:34 -0700 To: mobile-ip@ossi.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mohsen Banan Subject: (mobile-ip 601) Initial CDPD Systems operating in Las Vegas during Comdex 93 Cc: mohsen@neda.com, mark.s.taylor@mccaw.com, mohsen@comdex.cellular.com X-Mailer: X-Orig-Sender: owner-mobile-ip@ossi.com During the week of Nov. 15th at Comdex in Las Vegas McCaw Cellular Wireless Division demonstrated the first live CDPD network. Applications included: - Well Known Internet Services - Telnet - FTP - Wais - Chelo -Ping - .... - Electronic Mail - POP based agents - IMAP based agents - SMTP (native and gateways) - Credit Card Authorization - Position Tracking Systems A truck equipped with GPS and CDPD network interface travelling in Las Vegas was monitored at the show floor. - Vending Machine Reporting its inventory and status - .... This message is being sent to you from Comdex 93 show floor using McCaw's AirData service. Please do NOT reply to this message. If interested, for additional information contact: Mark Taylor mark.s.taylor@mccaw.com or Mohsen Banan mohsen@neda.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16938; 19 Nov 93 18:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16934; 19 Nov 93 18:51 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa04795; 19 Nov 93 18:51 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id PAA26445 for mobile-ip-dist; Fri, 19 Nov 1993 15:49:38 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id PAA26418 for ; Fri, 19 Nov 1993 15:49:21 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB28936; Fri, 19 Nov 93 15:46:01 PST Date: Fri, 19 Nov 93 15:46:01 PST Message-Id: <9311192346.AB28936@wc.novell.com> To: mobile-ip@ossi.com, mobile-ip@ossi.com Subject: (mobile-ip 602) Keeping the transport layer happy X-Orig-Sender: owner-mobile-ip@ossi.com Alistair, Thanks for the short tutorial on X.25 PLP. >I don't want to bore you too much again with TETRA but it's partly my baby >so I'll take the liberty. The link service provides BREAK (when MAC traffic >is no longer possible) and RESUME (when the MAC is available again) indications >to its client users at the MH and the base-station. These users can do >something with the indications or not: we don't care. Don't think that you are in danger of boring me. BREAK and RESUME sound quite reasonable (in some sense, we've asked 802.11 for the option of getting these). >I would be interested to hear suggestions for TCP or IP. A comparison with >ISO CLNP + TP class 4 might be useful? I could make several suggestions, but >I'd like to hear what people think. I doubt that in any of this, TCP or IP are any different from TP4 or CLNP. I think we need to try to design systems that don't drop packets too often. I think this involves various layers. I think i'm repeating myself. Phil Karn has suggested some sort of signal from MH (or the FA) back towards recently active correspondents when moving from BREAK state to RESUME state. I (and probably Phil and probably others) worry about the extra network load for packets that may be totally unnecessary and may fly quite frequently. In some sense, Yakov's (constant) comment applies: we don't know what we are going to build until we build it. Greg Minshall   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17369; 19 Nov 93 19:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17365; 19 Nov 93 19:28 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa05841; 19 Nov 93 19:28 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id QAA27563 for mobile-ip-dist; Fri, 19 Nov 1993 16:24:39 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id QAA27537 for ; Fri, 19 Nov 1993 16:24:31 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB29084; Fri, 19 Nov 93 16:21:12 PST Date: Fri, 19 Nov 93 16:21:12 PST Message-Id: <9311200021.AB29084@wc.novell.com> To: yakov@watson.ibm.com Subject: (mobile-ip 603) Re: Charlie's thankless task Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Yakov, >I tend to disagree with you on this. It is certainly *nice* when >fields are aligned, however, I don't think this should be a hard >requirement. To give you an example, if it is possible to get >an alignment by just rearranging fields within a packet, then I >go for it. However, if the alignment is used as an argument >against any variable length field, then I would disagree with >this argument. I also think that using padding as a way to get >the alignment is not a good idea in general. I wasn't using alignment as an argument against TLV. TLV can come at the end. I think the sense was to not have structs like {long; char; long; short; char; long}, but to try to rearrange for alignment. I tend to think that a byte or two of padding, if it significantly helps alignment, is a good thing. Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17392; 19 Nov 93 19:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17388; 19 Nov 93 19:31 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa05926; 19 Nov 93 19:31 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id QAA27765 for mobile-ip-dist; Fri, 19 Nov 1993 16:30:51 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id QAA27736 for ; Fri, 19 Nov 1993 16:30:33 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from watson.ibm.com by wc.novell.com (4.1/smi4.1.1.v91190) id AB29277; Fri, 19 Nov 93 16:26:28 PST Date: Fri, 19 Nov 93 16:26:28 PST Message-Id: <9311200026.AB29277@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 604) TLV's Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Yakov, >You may be correct that TLV's are more complicated. However, their >complexity should be analysed within the specific context they are >used. I *am* correct. The question is "is the added complexity worth the benefit?". >With respect to the example you gave when "the receiver doesn't grok >the TLV", I'd like to understand how is that different from the >receiver that "doesn't grok" a particular fixed length field (e.g. due >to bad/invalid semantics of the field). If the fixed length field is an IP address, it is an IP address. >The second point I'd like to make is that TLV's allow a rather >straightforward mechanism for protocol extensibility. That is, >extensibility is achieved by allowing optional parameters, where each >parameter is encoded as a TLV entity. Any proponents of outlawing TLV's >all together, should indicate alternative mechanisms for extensibility >(or make an explicit disclaimer that the extensibility is viewed as a >non-goal). You only get protocol extensibility with TLVs if you have rules for either negotiating the use of "new" TLVs, or preset rules for how to deal with unknown TLVs (drop TLV, pass along, drop packet, whatever). Both of these mechanisms come at an increased complexity cost. >I am aware of at least one routing protocol (which is widely deployed >in the Internet for quite a while) that *extensively* uses TLV's for >encoding routing information. So far we didn't hear any complains about >TLV's causing problems in this protocol. Since the IETF believes in >the *operational* experience, I would suggest that the experience with >this protocol should be used to ditch the discussion about the additional >overhead associated with using TLV's for encoding routing information. Routing protocols are run by *ROUTERS*, which tend to be largish things, at least as compared to things mobile. Things mobile of the host variety should be confronted with the simplest protocol possible. (I am *NOT* arguing against TLVs in general. I think their use in, for example, routing protocols makes a lot of sense. I am just presenting an argument about why NOT using TLVs for the mobile-ip work will make for a simpler protocol.) Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01213; 20 Nov 93 5:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01209; 20 Nov 93 5:22 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa04144; 20 Nov 93 5:22 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id CAA13553 for mobile-ip-dist; Sat, 20 Nov 1993 02:19:19 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id CAA13529 for ; Sat, 20 Nov 1993 02:19:10 -0800 Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id CAA22529 for ; Sat, 20 Nov 1993 02:19:08 -0800 Received: by lager.cisco.com id AA21224 (5.67a/IDA-1.5 for mobile-ip@ossi.com); Sat, 20 Nov 1993 02:18:32 -0800 Date: Sat, 20 Nov 1993 02:18:32 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311201018.AA21224@lager.cisco.com> To: minshall@wc.novell.com Cc: mobile-ip@ossi.com Subject: (mobile-ip 605) TLV's X-Orig-Sender: owner-mobile-ip@ossi.com >With respect to the example you gave when "the receiver doesn't grok >the TLV", I'd like to understand how is that different from the >receiver that "doesn't grok" a particular fixed length field (e.g. due >to bad/invalid semantics of the field). If the fixed length field is an IP address, it is an IP address. How does the receiver of a FUBAR address know how long it is? Or how to parse the rest of the packet? Or if it is a FUBAR address and not an IP addres? You only get protocol extensibility with TLVs if you have rules for either negotiating the use of "new" TLVs, or preset rules for how to deal with unknown TLVs (drop TLV, pass along, drop packet, whatever). Both of these mechanisms come at an increased complexity cost. True. These rules are NOT difficult. Let's see, here's a sketch of what we need to do: One byte "Type", one byte "Length". Save the high order bit of the type field to indicate "Required" attributes, which, if set, indicate that the TLV MUST be understood by all parties for the binding to be effective. If the bit is clear, the TLV is "optional". Some TLV's for registration: Type 0: Mobile host home address. Variable length, first octet is an AFI. Always required. Type 1: Home agent authentication. Variable length, first octet indiates authentication mechanism. Normally required if present. May be omitted. Used by the HA to authenticate the MH. Type 2: Foreign agent authentication. Variable length, first octet indicates authentication mechanism. Normally required if present. May be omitted. Used by the FA to authenticate the MH. Authentication mechanisms are presently unclear, as the general case requires a general security architecture for the Internet. Type 3: Privacy requested. Length 0. If present, this TLV indicates that the MH would like location privacy. Always required. May be omitted. Type 4: TLE requested. Length 0. If present, this TLV indicates that the MH would like triangle leg routing eliminated. Optional. Never (?) present if privacy is requested. May be omitted. Type 5: Timestamp. Length 8. A timestamp in NTP format supplied by the MH to prevent playback attacks. Normally only included for "interesting" home agent authentication mechanisms. Normally required if included. May be omitted. Type 6: COA. Variable length, first octet is an AFI. May be added by the FA, always seen by HA. Type 7: End of MH TLVs. Length 0. This is the last TLV included by the MH. Additional TLV's may be appended by the FA. Authentication mechanisms should compute authentication from the start of the registration message (end of UDP header) to the end of this TLV. Type 8: Tunnel termination address. Variable length, first octet is an AFI. Always required if present. Indicates the 'mobile' end of the tunnel. If not present, the COA is used as the tunnel termination address. Normally used if the FA and MH are not colocated. Type 127: Reserved for future expansion. And I'm sure I've forgotten some that you will remind me of. ;-) Now, it's taken me about 10 minutes to write this down. Do you think a MH can generate it? I should point out that a REALLY dumb device could just have a template that it bcopy's and then fills in. Not tough. Routing protocols are run by *ROUTERS*, which tend to be largish things, at least as compared to things mobile. Things mobile of the host variety should be confronted with the simplest protocol possible. I was unaware that physical size had anything to do with programmability. ;-) [Momentary divergence: I am convinced that routers need not be large. I cite the DECbrouter 90 as an example. I will take the opportunity to point out that I intend to do a Home Agent implementation for this box (assuming of course, DEC continues to pick up cisco software for their box -- and that I get to ship this code, now that I've given away this vital corporate secret ;-) and that this box is smaller than most mobile hosts will be (well, ok, at least the ones with decent keyboards ;-). Oh, and yes, it is computationally much less powerful than almost all of the laptops that I see floating around. Certainly it has less oomph than those things you see doing handwriting recognition. ;-)] (I am *NOT* arguing against TLVs in general. I think their use in, for example, routing protocols makes a lot of sense. Good. Since the mobile host protocol is a routing protocol (for passing around a single host route), I'm glad you're seeing our way. ;-) I am just presenting an argument about why NOT using TLVs for the mobile-ip work will make for a simpler protocol.) And one where we've painted ourselves into a corner. ;-( Let me flip this argument around: the vendors of the mobile hosts will not have a problem securing a sufficient programming staff to accept this additional programming burden. After all, they are deploying at LEAST a complete TCP/IP stack in a mobile host. The marginal engineering resources to parse TLV's are not an issue given the volume of units to be shipped. Thus, the engineers who are not well leveraged are those where there are small number of units to be shipped into this market: the home agent. Thus, I would expect to see the home agent vendors want to minimize complexity in the protocol. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01875; 20 Nov 93 9:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01871; 20 Nov 93 9:36 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa08499; 20 Nov 93 9:36 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id GAA18456 for mobile-ip-dist; Sat, 20 Nov 1993 06:28:24 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id GAA18432 for ; Sat, 20 Nov 1993 06:28:16 -0800 Received: from tristan.electrum.kth.se (tristan.electrum.kth.se [130.237.215.3]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id GAA22842 for ; Sat, 20 Nov 1993 06:28:13 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: maguire@it.kth.se Received: by tristan.electrum.kth.se (5.61-bind 1.4+ida/4.0) id AA17422; Sat, 20 Nov 93 15:28:11 +0100 Date: Sat, 20 Nov 93 15:28:11 +0100 Message-Id: <9311201428.AA17422@tristan.electrum.kth.se> To: mobile-ip@ossi.com Cc: minshall@wc.novell.com, mobile-ip@ossi.com Subject: (mobile-ip 607) small routers X-Orig-Sender: owner-mobile-ip@ossi.com To follow up the point that routers may be small - the current experimental MINT (Mobile INTernet) router that we (KTH and HPlabs) have been working on could be fit on less that 1/2 of a PCMCIA card [and this includes adding support for audio input and output, vidio output, SCSI, serial, ethernet, and a single chip radio!]. True that this requires chip on board mounting, but even using packaged chips only requires 1.5 the single side surface area. Chip   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04268; 20 Nov 93 21:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04264; 20 Nov 93 21:11 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa21300; 20 Nov 93 21:11 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id SAA03155 for mobile-ip-dist; Sat, 20 Nov 1993 18:01:06 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id SAA03131 for ; Sat, 20 Nov 1993 18:00:56 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199311210200.SAA03131@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4153; Sat, 20 Nov 93 21:00:54 EST Date: Sat, 20 Nov 93 20:58:11 EST To: andrewm@avalon.mpce.mq.edu.au cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Subject:merging IHMP with the draft >I was under the impression that WG decided merging them (IHMP >and the draft) was a good idea. Andrew, Here is the relevant paragraph I found from the WG minutes: "A discussion on the pros/cons of the intermediate Cache Agent model followed, with no consensus reached on how to proceed. Some argued it should be left out of initial draft while others argued we are close to a solution on triangle routing and we should continue with plans to merge IMHP into the draft." That clearly contradicts your impression. The documents shall not be merged unless there is a consensus on this within the WG. Yakov   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14091; 21 Nov 93 11:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14087; 21 Nov 93 11:25 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa06142; 21 Nov 93 11:25 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA15201 for mobile-ip-dist; Sun, 21 Nov 1993 08:13:41 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id IAA15177 for ; Sun, 21 Nov 1993 08:13:33 -0800 Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id IAA02104 for ; Sun, 21 Nov 1993 08:13:32 -0800 Received: by research.att.com; Sun Nov 21 11:13 EST 1993 Received: from hoh-1.hoh.att.com by big.l1135.att.com (4.1/4.7) id AA21330; Sun, 21 Nov 93 11:08:11 EST Posted-Date: Sun, 21 Nov 93 11:12:32 EST Message-Id: <9311211608.AA21330@big.l1135.att.com> Received: by hoh-1.hoh.att.com (4.1/4.7) id AA07963; Sun, 21 Nov 93 11:12:32 EST Date: Sun, 21 Nov 93 11:12:32 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Richard D. Gitlin" To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Please remove me from the mobile-ip e-mail distribution. Thanks. Rich Gitlin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02957; 22 Nov 93 10:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02953; 22 Nov 93 10:42 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa04404; 22 Nov 93 10:42 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id HAA06051 for mobile-ip-dist; Mon, 22 Nov 1993 07:38:02 -0800 Reply-To: mobile-ip@ossi.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id HAA06027 for ; Mon, 22 Nov 1993 07:37:54 -0800 Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <14434(1)>; Mon, 22 Nov 1993 07:37:12 PST Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58388>; Mon, 22 Nov 1993 07:37:00 -0800 Received: from dir.bris.ac.uk ([137.222.10.38]) by alpha.xerox.com with SMTP id <14492(2)>; Mon, 22 Nov 1993 07:36:20 PST Via: uk.ac.bristol.comms-research; Mon, 22 Nov 1993 15:35:28 +0000 Received: from arlott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Mon, 22 Nov 93 15:35:17 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Liu Liangqiu Message-Id: <3317.9311221535@arlott.comms-research.bristol.ac.uk> Subject: (mobile-ip 613) mobile-ip and PCN To: mobile-ip@parc.xerox.com Date: Mon, 22 Nov 1993 07:35:15 PST X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1042 X-Orig-Sender: owner-mobile-ip@ossi.com --------------------------- start of message -------------------------------- Hi, I have just set to the research on automatic uniform mobility management under the supervision of Dr A. Munro. My special research interest so far is to develop a reasonably perfect algorithm to satisfy the basic requirements for a MHP. From some papers' references, the following papers are available from mobile-ip mailing list. If possible, would you put me in the mobile-ip mailing list. Or would you please send them with related materials to me by email or by post: 1.[Myles, 92]Andrew Myles, Macquarie University, IP Options 29 July 1992. 2.[Ioannidis, 92b] John Ioannidis, Columbia University, Source Routing Experi- ments, 27 July 1992. I should be grateful for a reply to the address below. L.Q. Liu 1.3 Queen's Building, University Walk, Bristol BS8 1TR Email: liangqiu@comms-research.bristol.ac.uk Bye, Liangqiu ----------------------------- end of message ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03530; 22 Nov 93 11:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03526; 22 Nov 93 11:11 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa05280; 22 Nov 93 11:11 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA06704 for mobile-ip-dist; Mon, 22 Nov 1993 08:08:16 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id IAA06680 for ; Mon, 22 Nov 1993 08:08:09 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perk@watson.ibm.com Message-Id: <199311221608.IAA06680@rara.ossi.com> Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1963; Mon, 22 Nov 93 11:08:07 EST Date: Mon, 22 Nov 93 11:02:04 EST To: mobile-ip@ossi.com Subject: (mobile-ip 614) Your note of Sat, 20 Nov 93 20:58:11 EST X-Orig-Sender: owner-mobile-ip@ossi.com I have already registered my request to have that wording from WG minutes changed. Now I see that the disputed wording is being used to try to resolve what has become a pretty important issue. What happened at the meeting, as best I can remember, was that there was a consensus to get a finished first draft out there, which included consideration about how to accomplish route optimization as long as it was simple and offered at least weak security. I also remember that intermediate Cache Agents were felt by many people to offer significant new unresolved issues and, thus, should be considered as "future work". They're not the same thing, though specifying the operation of Intermediate Cache Agents depends on having already specified a means for route optimization. What happened to my request for a change to the minutes? Charlie P.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08706; 22 Nov 93 14:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08702; 22 Nov 93 14:02 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa10301; 22 Nov 93 14:02 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA11477 for mobile-ip-dist; Mon, 22 Nov 1993 10:59:16 -0800 Reply-To: mobile-ip@ossi.com Received: from uswat.advtech.uswest.com (firewall-user@uswat.advtech.uswest.com [130.13.16.1]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA11424 for ; Mon, 22 Nov 1993 10:59:04 -0800 Received: from atqm.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA01564 (5.65c/IDA-1.4.4 for ); Mon, 22 Nov 1993 11:59:00 -0700 Message-Id: <199311221859.AA01564@uswat.advtech.uswest.com> Date: 22 Nov 1993 11:54:21 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Penners Subject: (mobile-ip 615) Simplicity To: mobileip X-Orig-Sender: owner-mobile-ip@ossi.com Subject: Time:11:43 AM OFFICE MEMO Simplicity Date:11/22/93 Tony, >Let me flip this argument around: the vendors of the ^^^^^^^ >mobile hosts will not have a problem securing a >sufficient programming staff to accept this additional >programming burden. After all, they are deploying at >LEAST a complete TCP/IP stack in a mobile host. The >marginal engineering resources to parse TLV's are not >an issue given the volume of units to be shipped. Thus, >the engineers who are not well leveraged are those ^^^^^^^^^ >where there are small number of units to be shipped >into this market: the home agent. Thus, I would expect >to see the home agent vendors want to minimize ^^^^^^^ >complexity in the protocol. Flipping your argument around another way. What about the customer? If I am a customer (user, service provider, system administrator), does the added "vendor" flexabilility provide me with added value or does it allow the vendor to sell me more "stuff"? If I were a technically ingnorant customer, such as a hotel manager, I would want something that just about anybody off the street could manage. Therefore, I would want somthing *SIMPLE*. * Minimum "required" features * Stable software (few versions) * A minimum number of protocols to support. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10176; 22 Nov 93 14:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10172; 22 Nov 93 14:47 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa11986; 22 Nov 93 14:47 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA14260 for mobile-ip-dist; Mon, 22 Nov 1993 11:47:01 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA14236 for ; Mon, 22 Nov 1993 11:46:49 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from [130.57.64.146] by wc.novell.com (4.1/smi4.1.1.v91190) id AA03238; Mon, 22 Nov 93 11:43:15 PST Date: Mon, 22 Nov 93 11:43:14 PST Message-Id: <9311221943.AA03238@wc.novell.com> To: Tony Li Subject: (mobile-ip 616) Re: TLV's Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Tony, With my response, this is getting fairly silly, but... >How does the receiver of a FUBAR address know how long it is? Or how >to parse the rest of the packet? Or if it is a FUBAR address and not >an IP addres? The receiver of a packet with a FUBAR address knows how long it is (or, at least, that it isn't an IP address of length 4) by the fact that it is being received over a different protocol, different packet type, etc. >One byte "Type", one byte "Length". Save the high order bit of the >type field to indicate "Required" attributes, which, if set, indicate >that the TLV MUST be understood by all parties for the binding to be >effective. If the bit is clear, the TLV is "optional". Some TLV's >for registration: If a required one is not understood, how to propagate that fact back to the sender. How the two parties arrive at some commonly understood subset of understood tags. Etc. >Type 0: Mobile host home address. Variable length, first octet is an >AFI. Always required. Then, this should be 128? >Type 1: Home agent authentication. Variable length, first octet >indiates authentication mechanism. Normally required if present. May >be omitted. Used by the HA to authenticate the MH. Etc. >Type 127: Reserved for future expansion. And, the rules for use are? >I was unaware that physical size had anything to do with >programmability. ;-) Turing machine completeness, yes. But, power, memory constraints, etc., are real problems, and more severe problems on smaller machines. >[Momentary divergence: I am convinced that routers need not be large. I certainly don't think that routers have to be large. >Good. Since the mobile host protocol is a routing protocol (for >passing around a single host route), I'm glad you're seeing our way. ;-) Sorry. The mobile host protocol is a protocol between two entities, which may involve changes in the underlying routing topology. It is *NOT* the case that either of the entities (in the 3 or 4 pairs of entities) is necessarily a router. And, in my definition, a "routing protocol" is that which is spoken between routers, not any protocol in the world which, when executed, may affect routing. (Thus, SNMP and/or telnet, when used to manage a router, don't qualify as routing protocols.) Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10902; 22 Nov 93 15:24 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10898; 22 Nov 93 15:24 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa13395; 22 Nov 93 15:24 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id MAA15410 for mobile-ip-dist; Mon, 22 Nov 1993 12:23:45 -0800 Reply-To: mobile-ip@ossi.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id MAA15386 for ; Mon, 22 Nov 1993 12:23:33 -0800 Received: by lager.cisco.com id AA05242 (5.67a/IDA-1.5 for mobile-ip@ossi.com); Mon, 22 Nov 1993 12:22:55 -0800 Date: Mon, 22 Nov 1993 12:22:55 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311222022.AA05242@lager.cisco.com> To: minshall@wc.novell.com Cc: mobile-ip@ossi.com Subject: (mobile-ip 617) TLV's X-Orig-Sender: owner-mobile-ip@ossi.com With my response, this is getting fairly silly, but... Understatement of the week. The receiver of a packet with a FUBAR address knows how long it is (or, at least, that it isn't an IP address of length 4) by the fact that it is being received over a different protocol, different packet type, etc. Falls apart when you try to do multiprotocol support. If a required one is not understood, how to propagate that fact back to the sender. How the two parties arrive at some commonly understood subset of understood tags. Etc. The agent that objects returns an error message with a pointer to the offensive tag. The mobile host is free to change things and retry, probably with the help of a human: "I'm sorry, but we cannot provide privacy from this location, would you like to use an unsecured connection?" >Type 0: Mobile host home address. Variable length, first octet is an >AFI. Always required. Then, this should be 128? No. The high order bit is its own field. >Type 127: Reserved for future expansion. And, the rules for use are? You don't get to use it. Period. >I was unaware that physical size had anything to do with >programmability. ;-) Turing machine completeness, yes. But, power, memory constraints, etc., are real problems, and more severe problems on smaller machines. And since my machine is smaller than yours... >Good. Since the mobile host protocol is a routing protocol (for >passing around a single host route), I'm glad you're seeing our way. ;-) Sorry. The mobile host protocol is a protocol between two entities, which may involve changes in the underlying routing topology. It is *NOT* the case that either of the entities (in the 3 or 4 pairs of entities) is necessarily a router. I vehemently disagree. At the very least, the home agent fits the definition of a router (at least while it is tunneling): 12 A router is connected to two or more networks, appearing to 13 each of these networks as a connected host. Thus, it has (at 14 least) one physical interface and (at least) one IP address on 15 each of the connected networks. Forwarding an IP datagram 16 generally requires the router to choose the address of the 17 next-hop router or (for the final hop) the destination host. 18 This choice, called "routing", depends upon a routing database 19 within the router. This routing database should be maintained 20 dynamically to reflect the current topology of the Internet 21 system; a router normally accomplishes this by participating in 22 distributed routing and reachability algorithms with other 23 routers. Routers provide datagram transport only, and they 24 seek to minimize the state information necessary to sustain 25 this service in the interest of routing flexibility and 26 robustness. And, in my definition, a "routing protocol" is that which is spoken between routers, not any protocol in the world which, when executed, may affect routing. (Thus, SNMP and/or telnet, when used to manage a router, don't qualify as routing protocols.) Well, your definition is broken. ARP is clearly a "routing protocol". It affects routing between the router and the host. I would classify mobility protocols also as routing protocols for the same reason. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12296; 22 Nov 93 16:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12292; 22 Nov 93 16:33 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa15507; 22 Nov 93 16:32 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA18992 for mobile-ip-dist; Mon, 22 Nov 1993 13:28:57 -0800 Reply-To: mobile-ip@ossi.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id NAA18968 for ; Mon, 22 Nov 1993 13:28:44 -0800 Received: by lager.cisco.com id AA10084 (5.67a/IDA-1.5 for "mobileip" ); Mon, 22 Nov 1993 13:28:10 -0800 Date: Mon, 22 Nov 1993 13:28:10 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311222128.AA10084@lager.cisco.com> To: John Penners Cc: mobileip X-Orig-Sender: owner-mobile-ip@ossi.com What about the customer? If I am a customer (user, service provider, system administrator), does the added "vendor" flexabilility provide me with added value or does it allow the vendor to sell me more "stuff"? Hopefully it allows you to a) get a simple product to start with, and b) get more features when the technology evolves, and c) not have to perform forklift upgrades to get new features. If I were a technically ingnorant customer, such as a hotel manager, I would want something that just about anybody off the street could manage. Therefore, I would want somthing *SIMPLE*. * Minimum "required" features * Stable software (few versions) * A minimum number of protocols to support. I see nothing inconsistent with an argument for TLV's here. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12947; 22 Nov 93 16:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12943; 22 Nov 93 16:54 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa16167; 22 Nov 93 16:54 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA19581 for mobile-ip-dist; Mon, 22 Nov 1993 13:53:02 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA19557 for ; Mon, 22 Nov 1993 13:52:52 -0800 Received: from sgigate.sgi.com (sgigate.SGI.COM [192.82.208.1]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA04721 for ; Mon, 22 Nov 1993 13:52:50 -0800 Received: from relay.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) id AA13860; Mon, 22 Nov 93 13:52:49 -0800 Received: from cobalt.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgigate.sgi.com:mobile-ip@ossi.com id AA26718; Mon, 22 Nov 93 13:52:48 -0800 Received: by cobalt.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:mobile-ip@ossi.com id AA18713; Mon, 22 Nov 93 13:53:15 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chuck Clay Message-Id: <9311221353.ZM18711@cobalt.corp.sgi.com> Date: Mon, 22 Nov 1993 13:53:13 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: mobile-ip@ossi.com Subject: (mobile-ip 619) Unsubscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Orig-Sender: owner-mobile-ip@ossi.com Please remove me from this list. Thanks in advance, Chuck. chuckc@sgi.com --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13691; 22 Nov 93 17:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13687; 22 Nov 93 17:27 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa17040; 22 Nov 93 17:27 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA20487 for mobile-ip-dist; Mon, 22 Nov 1993 14:25:09 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id OAA20462 for ; Mon, 22 Nov 1993 14:25:02 -0800 Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id OAA04896 for ; Mon, 22 Nov 1993 14:25:00 -0800 Received: by research.att.com; Mon Nov 22 17:25 EST 1993 Received: from hoh-1.hoh.att.com by big.l1135.att.com (4.1/4.7) id AA05767; Mon, 22 Nov 93 17:19:34 EST Posted-Date: Mon, 22 Nov 93 17:24:03 EST Message-Id: <9311222219.AA05767@big.l1135.att.com> Received: by hoh-1.hoh.att.com (4.1/4.7) id AA25555; Mon, 22 Nov 93 17:24:03 EST Date: Mon, 22 Nov 93 17:24:03 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Richard D. Gitlin" To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Please remove me from this list. Thanks. Rich Gitlin rich@hoh-1!att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13789; 22 Nov 93 17:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13785; 22 Nov 93 17:40 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa17322; 22 Nov 93 17:40 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id OAA21015 for mobile-ip-dist; Mon, 22 Nov 1993 14:38:24 -0800 Reply-To: mobile-ip@ossi.com Received: from whistler.cs.washington.edu (whistler.cs.washington.edu [128.95.2.51]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id OAA20991 for ; Mon, 22 Nov 1993 14:38:16 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: zahorjan@cs.washington.edu Received: from localhost (localhost [127.0.0.1]) by whistler.cs.washington.edu (8.6.4/7.1ws+) with SMTP id OAA05564 for ; Mon, 22 Nov 1993 14:38:37 -0800 Message-Id: <199311222238.OAA05564@whistler.cs.washington.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 621) please unsubscribe me from this list Date: Mon, 22 Nov 93 14:38:36 -0800 X-Orig-Sender: owner-mobile-ip@ossi.com Thanks, zahorjan@cs.washington.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05828; 23 Nov 93 9:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05824; 23 Nov 93 9:17 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa03719; 23 Nov 93 9:17 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id GAA03488 for mobile-ip-dist; Tue, 23 Nov 1993 06:15:34 -0800 Reply-To: mobile-ip@ossi.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id GAA03427 for ; Tue, 23 Nov 1993 06:15:24 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perk@watson.ibm.com Message-Id: <199311231415.GAA03427@rara.ossi.com> Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0329; Tue, 23 Nov 93 08:56:39 EST Date: Tue, 23 Nov 93 08:44:59 EST To: mobile-ip@ossi.com Subject: (mobile-ip 623) Are Home Agents routers? X-Orig-Sender: owner-mobile-ip@ossi.com In my mental model, Home Agents are routers. However, I don't think they need to have an address on the Mobile Network. From: Tony Li Message-Id: <199311222022.AA05242@lager.cisco.com> > > ...... At the very least, the home agent fits the > definition of a router (at least while it is tunneling): > > 12 A router is connected to two or more networks, appearing to > 13 each of these networks as a connected host. Thus, it has (at > 14 least) one physical interface and (at least) one IP address on > 15 each of the connected networks. .......... In the other respects, Tony's quoted section fits Home Agents very well. Interestingly, the use of the word "connected" in the quoted passage illustrates the source of our difficulties for mobile-IP. Even if other people disagree with me, and the Working Group requires that the Home Agent have an address on the Home Network, I still don't think we could always call it a "connected host" on the Home Network. Charlie P.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09216; 23 Nov 93 11:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09212; 23 Nov 93 11:18 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa06711; 23 Nov 93 11:18 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA05502 for mobile-ip-dist; Tue, 23 Nov 1993 08:09:17 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id IAA05478 for ; Tue, 23 Nov 1993 08:09:09 -0800 Received: from vtt.fi (vtt.fi [130.188.1.1]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id IAA07815 for ; Tue, 23 Nov 1993 08:09:06 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hakan.Mitts@vtt.fi Received: by vtt.fi id AA29912 (5.67a8+/IDA-1.5 for mobile-ip@ossi.com); Tue, 23 Nov 1993 18:05:54 +0200 Message-Id: <199311231605.AA29912@vtt.fi> Date: Tue, 23 Nov 93 18:05:02 -0200 To: mobile-ip@ossi.com Subject: (mobile-ip 624) Simplicity and extensibility, was: Re: TLV's X-Charset: LATIN1 X-Char-Esc: 29 X-Popmail-Charset: European X-Orig-Sender: owner-mobile-ip@ossi.com Hello, In the recent debate over simplicity, extensibility, TLVs etc., I'd like to chip in just ever so slightly. First of all, simplicity of management is, when implemented in a good way, more or less orthogonal to complexity of the protocols, especially with respect to the coding scheme used. Indeed, customers will want a system that is very easy to manage. But functionally simple systems can be painful to manage and functionally complex system can be easy to manage, it all depends on the implementation of the 'management' frills that surround the core functionality! In my humble view, if mobile ip requires customers to support one FA per subnetwork this will be a much greater management hassle than having to manage on FA that uses a protocol can support a multitude of 'host' protocols in a mobile environment. Next, extensibility (and TLVs). Experience shows that once we have networking function 'A' available, the customers (of commercial implementations thereof) will immediately start to ask: 'Well, I don't have a TCP/IP machine, I have this *abc* networking system, how do I support it with your FA?'. And any reasonable manufacturer would just love to say: 'Well, mister customer, we can throw in support for *abc* if you can find yxz dollars for us.' Let's face it, it's gonna be asked for. If we plan for it in advance we will have interworking systems, if not, a number of manufacturers will do their own 'optimisation' and we run a risk of diverging for anything but TCP/IP? So what's involved in supporting *abc*? Well, mobile-ip must be able to carry other registration information than just IP addresses and the protocols between the MH and the FA need to be defined. I don't propose the latter should be done here, but the former is clearly within the area of responsibility of mobile-ip! And the onlyreasonable way to support a multitude of types of the same parameter is some kind of TLV coding. Last point on TLVs: Most mobile compoters today sport 10s of times as much processing power as those for which IP et al. were designed for. 386's, 486's, Power, whatever the thing in Newton is called, all are certainly capable of processing A FEW TLVs every now and then! R, Hakan ---------------------- Replied Message Body ---------------------- Date: 11-22-93 11:43am PST From: {minshall@wc.novell.com}:internet:vtt To: Hakan Mitts:vtt:vtt Subj: (mobile-ip 616) Re: TLV's ---------------------------------------------------------------------- Tony, With my response, this is getting fairly silly, but... >How does the receiver of a FUBAR address know how long it is? Or how >to parse the rest of the packet? Or if it is a FUBAR address and not >an IP addres? The receiver of a packet with a FUBAR address knows how long it is (or, at least, that it isn't an IP address of length 4) by the fact that it is being received over a different protocol, different packet type, etc. >One byte "Type", one byte "Length". Save the high order bit of the >type field to indicate "Required" attributes, which, if set, indicate >that the TLV MUST be understood by all parties for the binding to be >effective. If the bit is clear, the TLV is "optional". Some TLV's >for registration: If a required one is not understood, how to propagate that fact back to the sender. How the two parties arrive at some commonly understood subset of understood tags. Etc. >Type 0: Mobile host home address. Variable length, first octet is an >AFI. Always required. Then, this should be 128? >Type 1: Home agent authentication. Variable length, first octet >indiates authentication mechanism. Normally required if present. May >be omitted. Used by the HA to authenticate the MH. Etc. >Type 127: Reserved for future expansion. And, the rules for use are? >I was unaware that physical size had anything to do with >programmability. ;-) Turing machine completeness, yes. But, power, memory constraints, etc., are real problems, and more severe problems on smaller machines. >[Momentary divergence: I am convinced that routers need not be large. I certainly don't think that routers have to be large. >Good. Since the mobile host protocol is a routing protocol (for >passing around a single host route), I'm glad you're seeing our way. ;-) Sorry. The mobile host protocol is a protocol between two entities, which may involve changes in the underlying routing topology. It is *NOT* the case that either of the entities (in the 3 or 4 pairs of entities) is necessarily a router. And, in my definition, a "routing protocol" is that which is spoken between routers, not any protocol in the world which, when executed, may affect routing. (Thus, SNMP and/or telnet, when used to manage a router, don't qualify as routing protocols.) Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09761; 23 Nov 93 11:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09757; 23 Nov 93 11:51 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa07374; 23 Nov 93 11:51 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id IAA06053 for mobile-ip-dist; Tue, 23 Nov 1993 08:50:38 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id IAA06029 for ; Tue, 23 Nov 1993 08:50:27 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from [130.57.64.147] by wc.novell.com (4.1/smi4.1.1.v91190) id AA05491; Tue, 23 Nov 93 08:46:54 PST Date: Tue, 23 Nov 93 08:46:53 PST Message-Id: <9311231646.AA05491@wc.novell.com> To: Tony Li Subject: (mobile-ip 625) Re: TLV's Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Tony, There is some content here... > The receiver of a packet with a FUBAR address knows how long it is (or, at > least, that it isn't an IP address of length 4) by the fact that it is > being received over a different protocol, different packet type, etc. >Falls apart when you try to do multiprotocol support. Precisely the point. We are not trying to do multiprotocol support. It is more complex. >I vehemently disagree. At the very least, the home agent fits the >definition of a router (at least while it is tunneling): > 12 A router is connected to two or more networks, appearing to > 13 each of these networks as a connected host. Thus, it has (at > 14 least) one physical interface and (at least) one IP address on > 15 each of the connected networks. Forwarding an IP datagram > 16 generally requires the router to choose the address of the > 17 next-hop router or (for the final hop) the destination host. > 18 This choice, called "routing", depends upon a routing database > 19 within the router. This routing database should be maintained > 20 dynamically to reflect the current topology of the Internet > 21 system; a router normally accomplishes this by participating in > 22 distributed routing and reachability algorithms with other > 23 routers. Routers provide datagram transport only, and they > 24 seek to minimize the state information necessary to sustain > 25 this service in the interest of routing flexibility and > 26 robustness. Sorry, but there is nothing about a home agent that requires that it be implemented as a router. It could be a box with an ethernet interface in "promiscuous" mode and which knows how to filter packets for the ethernet addresses of "its" MHs. Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10783; 23 Nov 93 12:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10777; 23 Nov 93 12:25 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa08181; 23 Nov 93 12:24 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA06785 for mobile-ip-dist; Tue, 23 Nov 1993 09:23:34 -0800 Reply-To: mobile-ip@ossi.com Received: from pdxgate.cs.pdx.edu (pdxgate.cs.pdx.edu [131.252.20.103]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id JAA06761 for ; Tue, 23 Nov 1993 09:23:23 -0800 Received: from sirius.cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/pdx-gateway-evision: 1.31 id AA25316; Tue, 23 Nov 93 09:23:16 PST Received: from sirius.cs.pdx.edu by sirius.cs.pdx.edu (4.1/pdx-client-evision: 1.21 id AA28189; Tue, 23 Nov 93 09:23:11 PST Message-Id: <9311231723.AA28189@sirius.cs.pdx.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 626) Re: TLV's <9311231646.AA05491@wc.novell.com> Date: Tue, 23 Nov 93 09:23:10 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jrb@cs.pdx.edu X-Orig-Sender: owner-mobile-ip@ossi.com Greg, how are those packets forwarded by other routers to the HA ever going to get there if they don't think the HA is a router? To me, the meaning of "advertises" is that the HA is running a dynamic routing protocol such as RIP/OSPF or using static routing -- the result being that other routers know to forward packets headed for the mobile subnet to the HA. No amount of promiscuous mode is going to get that accomplished. Tunneling is another aspect of routing. I see tunnels as a virtual "ip_forward". j.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11350; 23 Nov 93 13:05 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11346; 23 Nov 93 13:05 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa09066; 23 Nov 93 13:05 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA08179 for mobile-ip-dist; Tue, 23 Nov 1993 10:04:41 -0800 Reply-To: mobile-ip@ossi.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA08155 for ; Tue, 23 Nov 1993 10:04:32 -0800 Received: by lager.cisco.com id AA03986 (5.67a/IDA-1.5 for mobile-ip@ossi.com); Tue, 23 Nov 1993 10:03:56 -0800 Date: Tue, 23 Nov 1993 10:03:56 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199311231803.AA03986@lager.cisco.com> To: minshall@wc.novell.com Cc: mobile-ip@ossi.com Subject: (mobile-ip 627) TLV's X-Orig-Sender: owner-mobile-ip@ossi.com Precisely the point. We are not trying to do multiprotocol support. It is more complex. I will grant you that it is slightly more complex. But it is trivial to leave the hooks (TLVs) now so that we can add them to the protocol when we figure it out. Sorry, but there is nothing about a home agent that requires that it be implemented as a router. It could be a box with an ethernet interface in "promiscuous" mode and which knows how to filter packets for the ethernet addresses of "its" MHs. Sorry, but a box which picks up packets on the Ethernet interface and shoves them down a tunnel IS a router. I see no two ways about it. Certainly it could be an exceptionally DUMB router, but it is making a routing decision based on the level 3 destination address. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11560; 23 Nov 93 13:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11556; 23 Nov 93 13:17 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa09316; 23 Nov 93 13:17 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA08263 for mobile-ip-dist; Tue, 23 Nov 1993 10:16:55 -0800 Reply-To: mobile-ip@ossi.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA08239 for ; Tue, 23 Nov 1993 10:16:43 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minshall@wc.novell.com Received: from [130.57.64.147] by wc.novell.com (4.1/smi4.1.1.v91190) id AA06738; Tue, 23 Nov 93 10:13:22 PST Date: Tue, 23 Nov 93 10:13:21 PST Message-Id: <9311231813.AA06738@wc.novell.com> To: mobile-ip@ossi.com, mobile-ip@ossi.com Subject: (mobile-ip 628) Re: TLV's <9311231646.AA05491@wc.novell.com> X-Orig-Sender: owner-mobile-ip@ossi.com Jim, >how are those packets forwarded by other routers to the HA >ever going to get there if they don't think the HA is a router? >To me, the meaning of "advertises" is that the HA is running a dynamic >routing protocol such as RIP/OSPF or using static routing -- the result >being that other routers know to forward packets headed for the mobile >subnet to the HA. No amount of promiscuous mode is going to get that >accomplished. Tunneling is another aspect of routing. I see >tunnels as a virtual "ip_forward". If there is a physical network somewhere that is the "home" network for the home address of the mobile host, and if the home agent is physically attached to that network, and if the interface which the home agent uses to attach to that network is running in promiscuous mode, AND if the home agent is willing to do something which sort of is, but sort of isn't, like proxy ARP (i.e., answer on behalf of the mobile host, but answering the ethernet address of the mobile host), which is required to get any packets flowing, then the home agent will see those packets. Is this the best solution? The preferred solution? In some "applications" (environments, stress levels, etc.), maybe. Greg   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13124; 23 Nov 93 14:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13120; 23 Nov 93 14:34 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa11009; 23 Nov 93 14:34 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA09710 for mobile-ip-dist; Tue, 23 Nov 1993 11:33:03 -0800 Reply-To: mobile-ip@ossi.com Received: from pdxgate.cs.pdx.edu (pdxgate.cs.pdx.edu [131.252.20.103]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA09686 for ; Tue, 23 Nov 1993 11:32:40 -0800 Received: from rigel.cs.pdx.edu (cs.pdx.edu) by pdxgate.cs.pdx.edu (4.1/pdx-gateway-evision: 1.31 id AA26168; Tue, 23 Nov 93 11:32:31 PST Received: from rigel.cs.pdx.edu by rigel.cs.pdx.edu (4.1/pdx-client-evision: 1.21 id AA20968; Tue, 23 Nov 93 11:32:30 PST Message-Id: <9311231932.AA20968@rigel.cs.pdx.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 629) Re: TLV's <9311231646.AA05491@wc.novell.com> <9311231813.AA06738@wc.novell.com> Date: Tue, 23 Nov 93 11:32:29 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jrb@cs.pdx.edu X-Orig-Sender: owner-mobile-ip@ossi.com >If there is a physical network somewhere that is the "home" network for the >home address of the mobile host, and if the home agent is physically >attached to that network, and if the interface which the home agent uses to >attach to that network is running in promiscuous mode, AND if the home >agent is willing to do something which sort of is, but sort of isn't, like >proxy ARP (i.e., answer on behalf of the mobile host, but answering the >ethernet address of the mobile host), which is required to get any packets >flowing, then the home agent will see those packets. >Is this the best solution? The preferred solution? In some "applications" >(environments, stress levels, etc.), maybe. So there are two possible models for HAs: 1. HA as router. 2. HA as promiscious snooper. (proxy sink for packets) The assumption here is that packets are being forwarded either to the HA itself (case 1), or to the subnet that the HA resides on. I.e., HA/router | ---------------------------mobile subnet------------------- router (non-HA) | ---------------------mobile subnet ---------- | HA (promiscuous i/f) My reaction to 2 is that I don't believe that the promiscuous HA should be the preferred model. I think 1 is simpler to understand. No reason to rule it out though, is there? anybody? Obvious question is "how does it work again if MH is "home""? :-> j.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13171; 23 Nov 93 14:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13167; 23 Nov 93 14:37 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa11100; 23 Nov 93 14:37 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA10181 for mobile-ip-dist; Tue, 23 Nov 1993 11:37:27 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id LAA10157 for ; Tue, 23 Nov 1993 11:37:19 -0800 Received: from piraya.electrum.kth.se (piraya.electrum.kth.se [130.237.212.130]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id LAA08761 for ; Tue, 23 Nov 1993 11:37:16 -0800 Received: from fullhorn.electrum.kth.se by piraya.electrum.kth.se (5.61-bind 1.4+ida/4.0) id AA05072; Tue, 23 Nov 93 20:36:59 +0100 Date: Tue, 23 Nov 93 20:37:03 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Frank.Reichert" Subject: (mobile-ip 630) Mobile = Wireless ??? To: MOBILE-IP@ossi.com X-Mailer: LeeMail 2.0.1 Message-Id: X-Orig-Sender: owner-mobile-ip@ossi.com Hej! and Gruess Gott! I have a question related to "Routing Support for IP Mobile Hosts" Oct 93 Is it true that a Mobile Host (MH) must use a wireless interface? If YES, -> forget the rest of this message. If NO, the MH may use a cable and plug into the same, e.g., Ethernet as the Home Agent (HA). Routing to/from this network may be provided by conventional routers. On Page 11: >After a mobile host completes the registration process with its Home Agent, >the Home Agent will recognize that the mobile host is at home, and will >provide conventional routing functions on behalf of the mobile host. Q1: why is routing needed if two stations sit on the same network? Q2: wouldn't it be better that the HA disables mobile-ip service for a MH which is at home under certain network configurations? Q3: Does the sentence above not imply certain network topologies?. Q4: Is it not possible that a home agent is a host having only one interface which may be wired or even wireless? Perhaps the paragraph could be rephrased to: >After a mobile host completes the registration process with its Home Agent, >the Home Agent will recognize that the mobile host is at home, and will possibility a: >provide conventional routing functions on behalf of the mobile host, if necessary. possibility b: >provide conventional routing functions on behalf of the mobile host, if required to forward packets to the mobile host. Frank ---------------------------------------------------------------------- Frank Reichert - reichert@it.kth.se - tel. +46 8 751 1434 ----------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15506; 23 Nov 93 16:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15502; 23 Nov 93 16:31 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa13622; 23 Nov 93 16:31 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id NAA12138 for mobile-ip-dist; Tue, 23 Nov 1993 13:30:06 -0800 Reply-To: mobile-ip@ossi.com Received: from loki.ossi.com (loki.ossi.com [192.240.4.1]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id NAA12106 for ; Tue, 23 Nov 1993 13:29:57 -0800 Received: from avalon.mpce.mq.edu.au ([137.111.238.12]) by loki.ossi.com (8.6.4/8.6.4) with SMTP id NAA09167 for ; Tue, 23 Nov 1993 13:29:52 -0800 Message-Id: <199311232129.NAA09167@loki.ossi.com> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA15082; Wed, 24 Nov 93 08:33:02 edt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Myles Subject: (mobile-ip 632) Re: TLV's To: mobile-ip@ossi.com Date: Wed, 24 Nov 93 8:33:01 EDT Mailer: Elm [revision: 64.9] X-Orig-Sender: owner-mobile-ip@ossi.com G'day all, > how are those packets forwarded by other routers to the HA > ever going to get there if they don't think the HA is a router? > To me, the meaning of "advertises" is that the HA is running a dynamic > routing protocol such as RIP/OSPF or using static routing A HA does NOT advertise anything contrary to much that has been written. However, if it is in the same box as a router (only only possible configuration) the router will use RIP/OSPF etc. > -- the result > being that other routers know to forward packets headed for the mobile > subnet to the HA. No amount of promiscuous mode is going to get that > accomplished. Tunneling is another aspect of routing. I see > tunnels as a virtual "ip_forward". I am confused why this promiscuous mode stuff has come up. It is certainly not needed in the latest work. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, MPCE Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8059071 (W), +61 2 8059128 (Fax), +61 2 8786060 (H).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18213; 23 Nov 93 19:55 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18209; 23 Nov 93 19:55 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa17450; 23 Nov 93 19:55 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id QAA21726 for mobile-ip-dist; Tue, 23 Nov 1993 16:54:32 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id QAA21702 for ; Tue, 23 Nov 1993 16:54:24 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.4/8.6.4) with SMTP id QAA24012 for mobile-ip@bette.ossi.com; Tue, 23 Nov 1993 16:54:22 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311240054.QAA24012@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: mobile-ip@ossi.com Subject: (mobile-ip 633) TLV's Date: Tue, 23 Nov 93 16:54:22 PST X-Orig-Sender: owner-mobile-ip@ossi.com Well, I never could resist a good religious war. :) As someone who cares about gigabit+ network speeds I am opposed to TLV's on fields. They slow things down and make them more complex without any clear gain that I can see. With due respect to Tony Li and others, I do hear your arguments but remain unconvinced. Packets do need typing information, however. And a network must support many packet types. To allow for high-speed and small-scale implementations, I believe any typing information should be once per packet. As an example, the IP header version number is such a form of typing. I know everything about the shape of the packet from one field. I can still make an implementation which accepts multiple IP versions just as easily as if each field had TLV's. I can switch off the version number or type or magic cookie or whatever you want to call it. I can write my implementation so it stores TLV's internally. Heck, I can even make an implementation that is extensible if I provide the right hooks. However, I now have *one* place where I check for *one* value. The use of XDR in NFS, for example, shows the folly of TLV's. Oh sure, RPC is wonderfully versatile because of XDR being underneath it. However, every NFS implementation must still use the same underlying types for those expensive TLV encodings. It is pointless bytes and cyles. NFS should have had a packet format. TLV's belong in XDR for RPC because RPC ostensibly creates an API, and you cannot assume the typing of the data. NFS is not such a protocol: it is of necessity a completely static entity: no one really knows what it would mean if an NFS stat gave you back a 60-bit integer for the file mode. Now these packets we are specifying are hoped to be relatively infrequent. And bully for that! However, that doesn't mean that bandwidth is free and that I want to waste bytes on TLV encoding. (Right now I'm typing this message from behind a slow SLIP link...which makes me very touchy about packet sizes. :) So, I claim that the current packet formats in the group draft are adequate: o This protocol is still just an experiment, so changes should be expected o The protocol identifier field can be used to extend the protocol later easily o Leaving packet sizes fixed allows folks inclined to build tiny little IP things in PROMS to have a somewhat easier time making stuff fit o Leaving TLV's out cannot possibly slow the protocol, but adding them might o Multiprotocol support isn't very important right now I would also support putting a statement in the document that suggests that if this protocol is picked up to support mobility for other protocols besides IP that our intent is that they register a new protocol identifier and change the field lengths suitably, retaining the field order and other attributes, completely if possible. Cheers, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02173; 24 Nov 93 8:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02169; 24 Nov 93 8:03 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa04664; 24 Nov 93 8:03 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id FAA00183 for mobile-ip-dist; Wed, 24 Nov 1993 05:02:38 -0800 Reply-To: mobile-ip@ossi.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id FAA00155 for ; Wed, 24 Nov 1993 05:02:30 -0800 Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <14713(2)>; Wed, 24 Nov 1993 05:01:49 PST Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Wed, 24 Nov 1993 05:01:38 -0800 Received: from earth.njit.edu ([128.235.1.200]) by alpha.xerox.com with SMTP id <14707(2)>; Wed, 24 Nov 1993 05:01:14 PST Received: from bart.njit.edu by earth.njit.edu (5.61+++/irss) id AA00284; Wed, 24 Nov 93 07:56:18 -0500 Received: by bart.njit.edu (5.61+++/earth-client) id AA24369; Wed, 24 Nov 93 07:49:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: kant@earth.njit.edu Message-Id: <9311241249.AA24369@bart.njit.edu> Subject: (mobile-ip 638) Removal from Mailing lsit!! To: mobile-ip@parc.xerox.com Date: Wed, 24 Nov 1993 04:49:27 PST X-Mailer: ELM [version 2.3 PL11] X-Orig-Sender: owner-mobile-ip@ossi.com Hi mobile-ip working group!! Thanks for all the useful information I got from your mailing list. Since I'm going back to Germany, please remove me. Keep going, -- Andreas Keppler   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08111; 24 Nov 93 13:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08107; 24 Nov 93 13:06 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa10826; 24 Nov 93 13:06 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id JAA07015 for mobile-ip-dist; Wed, 24 Nov 1993 09:57:39 -0800 Reply-To: mobile-ip@ossi.com Received: from bette.ossi.com (bette.ossi.com [192.240.4.170]) by rara.ossi.com (8.6.4/8.6.4) with ESMTP id JAA06991 for ; Wed, 24 Nov 1993 09:57:32 -0800 Received: from localhost.ossi.com (localhost.ossi.com [127.0.0.1]) by bette.ossi.com (8.6.4/8.6.4) with SMTP id JAA02609 for mobile-ip; Wed, 24 Nov 1993 09:57:31 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Parker Message-Id: <199311241757.JAA02609@bette.ossi.com> X-Authentication-Warning: bette.ossi.com: Host localhost.ossi.com didn't use HELO protocol To: mobile-ip@ossi.com Subject: (mobile-ip 640) Apologies for recent mail loop/bounce messages... Date: Wed, 24 Nov 93 09:57:31 PST X-Orig-Sender: owner-mobile-ip@ossi.com The offending address has been removed and the appropriate postmaster contacted. I would have done so sooner, but I had not noticed they were bound for mobile-ip not owner-mobile-ip. Cheers, ~sparker   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09440; 24 Nov 93 14:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09431; 24 Nov 93 14:02 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12079; 24 Nov 93 14:02 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA11807 for mobile-ip-dist; Wed, 24 Nov 1993 10:59:59 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA11763 for ; Wed, 24 Nov 1993 10:59:48 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA13932; Wed, 24 Nov 93 12:58:49 CST Message-Id: <9311241858.AA13932@sbctri.sbc.com> Date: 19 Nov 1993 08:07:13 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 642) Rejected by Custodian To: minshall@wc.novell.com Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 599) Charlie's t Received: by trigate.sbc.com with SMTP;19 Nov 1993 08:06:27 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id FAA12671 for mobile-ip-dist; Fri, 19 Nov 1993 05:06:53 -0800 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id FAA12647 for ; Fri, 19 Nov 1993 05:06:45 -0800 From: yakov@watson.ibm.com Message-Id: <199311191306.FAA12647@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0235; Fri, 19 Nov 93 08:06:42 EST Date: Fri, 19 Nov 93 08:04:38 EST To: minshall@wc.novell.com cc: mobile-ip@ossi.com Subject: (mobile-ip 599) Charlie's thankless task >I think the sense of the WG was that fields should be aligned. Greg, I tend to disagree with you on this. It is certainly *nice* when fields are aligned, however, I don't think this should be a hard requirement. To give you an example, if it is possible to get an alignment by just rearranging fields within a packet, then I go for it. However, if the alignment is used as an argument against any variable length field, then I would disagree with this argument. I also think that using padding as a way to get the alignment is not a good idea in general. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09470; 24 Nov 93 14:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09463; 24 Nov 93 14:03 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12104; 24 Nov 93 14:03 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11878 for mobile-ip-dist; Wed, 24 Nov 1993 11:01:08 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11849 for ; Wed, 24 Nov 1993 11:01:00 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA14025; Wed, 24 Nov 93 13:00:01 CST Message-Id: <9311241900.AA14025@sbctri.sbc.com> Date: 19 Nov 1993 02:23:10 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 644) Rejected by Custodian To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 597) Comment on Received: by trigate.sbc.com with SMTP;19 Nov 1993 02:22:51 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id XAA04896 for mobile-ip-dist; Thu, 18 Nov 1993 23:34:59 -0800 Received: from vtt.fi (vtt.fi [130.188.1.1]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id XAA04872 for ; Thu, 18 Nov 1993 23:34:52 -0800 From: Hakan.Mitts@vtt.fi Received: by vtt.fi id AA06853 (5.67a8+/IDA-1.5 for mobile-ip@ossi.com); Fri, 19 Nov 1993 09:31:09 +0200 Message-Id: <199311190731.AA06853@vtt.fi> Date: Fri, 19 Nov 93 09:30:05 -0200 To: mobile-ip@ossi.com Subject: (mobile-ip 597) Comment on decoupling COA and FA X-Charset: LATIN1 X-Char-Esc: 29 X-Popmail-Charset: European Hello Greg proposed in a mail: >The suggestion is that the "care of address" (COA) be decoupled from >the address of the "foreign agent" (FA) in all registration, etc., >packets. The home agent, and any "mobile aware" "correspondent hosts" >(CHs) would keep a binding of (home address, care of address), rather >than the current (home address, foreign agent address). >But, a site can also generate a system in which the COA is not tied to >a given FA, but rather addresses (some agent or agents at) the site >itself. In this method, the MH can sequentially register with different >FA's at the site without having to send a registration update back to >the HA. >(To implement this at a site would require using a protocol which we >aren't specifying. One possibility would be to use host routes in the >site. The other is to have a registration protocol between the foreign >agent and the care of address agent so that packets arriving at the >latter would be forwarded to the former.) I heartyly agree with this as this seems to be a way to get around having one FA per subnet as (in addition to the POP-UP/FA thing). But then the protocols between COA-agent/FA :-) and the MH gets more compli- caed I guess? R, Hakan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09472; 24 Nov 93 14:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09464; 24 Nov 93 14:03 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12105; 24 Nov 93 14:03 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11856 for mobile-ip-dist; Wed, 24 Nov 1993 11:01:02 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11828 for ; Wed, 24 Nov 1993 11:00:53 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA14008; Wed, 24 Nov 93 12:59:54 CST Message-Id: <9311241859.AA14008@sbctri.sbc.com> Date: 19 Nov 1993 04:22:20 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 643) Rejected by Custodian To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 598) Keeping the Received: by trigate.sbc.com with SMTP;19 Nov 1993 04:22:10 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id BAA07612 for mobile-ip-dist; Fri, 19 Nov 1993 01:41:05 -0800 Received: from dir.bris.ac.uk (dir.bris.ac.uk [137.222.10.38]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id BAA07588 for ; Fri, 19 Nov 1993 01:40:52 -0800 Via: uk.ac.bristol.comms-research; Fri, 19 Nov 1993 09:40:39 +0000 Received: from boycott.comms-research.bristol.ac.uk by comms-research.bristol.ac.uk; Fri, 19 Nov 93 09:40:34 GMT From: Alistair Munro Message-Id: <5468.9311190940@boycott.comms-research.bristol.ac.uk> Subject: (mobile-ip 598) Keeping the transport layer happy To: mobile-ip@ossi.com Date: Fri, 19 Nov 1993 09:40:30 +0000 (GMT) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3873 Grep, Thanks for your comments on registration and the transport layer. Here's a response on keeping the transport layer happy. > >3. The transport layer should be kept happy up to a point. From Ramon's > > paper it seems that you have an end-to-end problem with TCP that you can > > avoid with, say, X.25 PLP. Changing TCP would seem to be a tricky > > political problem! Are there other solutions? > > I (in my supreme ignorance!) would be interested in hearing how X.25 PLP > would deal with this. > At the risk of causing some astonishment, the X.25 PLP is functionally much the same as TCP in the "established" state. (By which I mean that the differences aren't relevant to the argument). The sliding window is packet-based in X.25 PLP so there is a coarser level of granularity. It's used for the same goals of keeping transmission going efficiently and achieving flow control. Architecturally, the PLP is defined only between the end system (ES) and the first intermediate system (IS): what goes on between the ISs is their own business. In particular, part of their business is congestion management: the ES is only aware that its window hasn't been updated when the IS is battling with the rest of the network. In the absence of any external intervention, the ES may carry on and retransmit to the IS or it may not (this is a user-requested, implementor/operator choice). Duplicate packets received by the IS are not forwarded, just discarded. In the case of a MH link failure, the only relationship that is affected is the ES - IS that used the link. An indication of link failure can be used to freeze the internal timers at the ES or IS until the link comes back (if it does). The indication doesn't need to be propagated through the network - but ISs may choose to between themselves for internal management if it's possible in the infrastructure. There *are* end-to-end aspects of an X.25 PLP connection which would cause problems; however these can be negotiated out when the connection is connection is established. > > Some link layers may do more than others as far as residual BER, PUEM, > > missequencing, etc. is concerned and they *may* do enough to keep TCP happy. > > I wouldn't rely on it! > > I wouldn't rely on those link layers being all that successful for general > purpose mobile computing! > > > Remember also, that while some applications are going to get it in the > > neck, others can cope quite happily with transport problems. Don't try too > > hard. > > Well, yes, this is the other side of the argument. Some link layers may > only support a small percentage of applications running over specialized > transport protocols (things like pagers, etc.). > I don't want to bore you too much again with TETRA but it's partly my baby so I'll take the liberty. The link service provides BREAK (when MAC traffic is no longer possible) and RESUME (when the MAC is available again) indications to its client users at the MH and the base-station. These users can do something with the indications or not: we don't care. It was a battle to get this view put across: there was an opinion that behaviour should be more constrained, that the link layer should flounder around doing retransmissions, etc. Against this was the view that we don't really know what is going to happen, and should do the minimum necessary until we understand the constraints properly. I would be interested to hear suggestions for TCP or IP. A comparison with ISO CLNP + TP class 4 might be useful? I could make several suggestions, but I'd like to hear what people think. Regards, Alistair -- Dr. Alistair Munro, Centre for Communications Research, Bristol University Rm 1.3 Queen's Building, University Walk, BS8 1TR UK E-mail: A.Munro@bristol.ac.uk Tel: +44-272-291403 | +44-272-288620; Fax: +44-272-255265   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09486; 24 Nov 93 14:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09482; 24 Nov 93 14:04 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12129; 24 Nov 93 14:04 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11953 for mobile-ip-dist; Wed, 24 Nov 1993 11:02:00 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11929 for ; Wed, 24 Nov 1993 11:01:53 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA14087; Wed, 24 Nov 93 13:00:53 CST Message-Id: <9311241900.AA14087@sbctri.sbc.com> Date: 18 Nov 1993 20:22:59 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 646) Rejected by Custodian To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 595) Charlie's t Received: by trigate.sbc.com with SMTP;18 Nov 1993 20:22:48 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id RAA27797 for mobile-ip-dist; Thu, 18 Nov 1993 17:47:03 -0800 Received: from eegw.ee.sunysb.edu (sbee3b.eng.sunysb.edu [129.49.27.5]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id RAA27773 for ; Thu, 18 Nov 1993 17:46:54 -0800 Received: from roger.ee.sunysb.edu by eegw.ee.sunysb.edu (4.0/SMI-4.0) id AA03329; Thu, 18 Nov 93 20:46:14 EST Received: from jessica.ee.sunysb.edu by roger.ee.sunysb.edu (4.1/SMI-4.1) id AA02211; Thu, 18 Nov 93 20:45:11 EST Date: Thu, 18 Nov 93 20:45:11 EST From: jhua@sbee.eng.sunysb.edu (Jiang Hua) Message-Id: <9311190145.AA02211@roger.ee.sunysb.edu> To: mobile-ip@ossi.com Subject: (mobile-ip 595) Charlie's thankless task sorry, a test   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09496; 24 Nov 93 14:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09492; 24 Nov 93 14:04 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12133; 24 Nov 93 14:04 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id LAA11917 for mobile-ip-dist; Wed, 24 Nov 1993 11:01:45 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id LAA11880 for ; Wed, 24 Nov 1993 11:01:37 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA14075; Wed, 24 Nov 93 13:00:37 CST Message-Id: <9311241900.AA14075@sbctri.sbc.com> Date: 18 Nov 1993 21:16:49 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 645) Rejected by Custodian To: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 596) Minutes Received: by trigate.sbc.com with SMTP;18 Nov 1993 21:16:37 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id SAA29030 for mobile-ip-dist; Thu, 18 Nov 1993 18:37:44 -0800 Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id SAA29006 for ; Thu, 18 Nov 1993 18:37:36 -0800 From: minshall@wc.novell.com Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB25442; Thu, 18 Nov 93 18:34:25 PST Date: Thu, 18 Nov 93 18:34:25 PST Message-Id: <9311190234.AB25442@wc.novell.com> To: mobile-ip@ossi.com Subject: (mobile-ip 596) Minutes All, With respect to the following note i sent regarding the minutes: >Unfortunately, i think *THIS* set of notes is going to go in in the current >format (just due to my own time constraints between now and tomorrow am). After sending the above, i am worried that i may have conveyed the wrong impression. Pierre Dupont, the taker of the minutes, was *very* punctual in getting the draft minutes to me. I, because of being out of town, etc., was very remiss in going over them, making minor corrections, and getting them out in a timely manner to the list for everyone's review. Thus, that the minutes are late, and can't be re-done, is solely my fault. Greg Minshall, co-chair for administrivia   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09439; 24 Nov 93 14:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09432; 24 Nov 93 14:02 EST Received: from rara.ossi.com by CNRI.Reston.VA.US id aa12080; 24 Nov 93 14:02 EST Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id KAA11803 for mobile-ip-dist; Wed, 24 Nov 1993 10:59:58 -0800 Reply-To: mobile-ip@ossi.com Received: from sbctri.sbc.com (sbctri.tri.sbc.com [144.60.1.10]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id KAA11757 for ; Wed, 24 Nov 1993 10:59:45 -0800 Received: from trigate.sbc.com (trigate.tri.sbc.com) by sbctri.sbc.com (4.1/SMI-4.1) id AA13926; Wed, 24 Nov 93 12:58:46 CST Message-Id: <9311241858.AA13926@sbctri.sbc.com> Date: 19 Nov 1993 08:52:49 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: TRIGATE Subject: (mobile-ip 641) Rejected by Custodian To: minshall@wc.novell.com Cc: mobile-ip@ossi.com X-Orig-Sender: owner-mobile-ip@ossi.com Mail*Link(r) SMTP (mobile-ip 600) TLV's Received: by trigate.sbc.com with SMTP;19 Nov 1993 08:51:12 -0600 Received: from localhost (daemon@localhost) by rara.ossi.com (8.6.4/8.6.4) id GAA13835 for mobile-ip-dist; Fri, 19 Nov 1993 06:05:26 -0800 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by rara.ossi.com (8.6.4/8.6.4) with SMTP id GAA13811 for ; Fri, 19 Nov 1993 06:05:18 -0800 From: yakov@watson.ibm.com Message-Id: <199311191405.GAA13811@rara.ossi.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0645; Fri, 19 Nov 93 09:05:11 EST Date: Fri, 19 Nov 93 09:03:58 EST To: minshall@wc.novell.com cc: mobile-ip@ossi.com Subject: (mobile-ip 600) TLV's >And, then I'll use Yakov's comments to suggest that we ditch >using TLV's to represent network addresses in packets. TLV's >are more complicated. We should be striving for simple. What >if the receiver doesn't grok the TLV format ? So, you need >new error replies. Etc. Greg, You may be correct that TLV's are more complicated. However, their complexity should be analysed within the specific context they are used. So, let's first talk about using TLV's to carry network addresses. This would allow the same routing protocol (like the registration protocol within mobile-ip) to be used in conjunction with different network layer protocols. So, here we have a trade-off between re-using the same protocol, but paying extra complexity for TLV's or using multiple protocols and have network addresses encoded as fixed length fields. With respect to the example you gave when "the receiver doesn't grok the TLV", I'd like to understand how is that different from the receiver that "doesn't grok" a particular fixed length field (e.g. due to bad/invalid semantics of the field). The second point I'd like to make is that TLV's allow a rather straightforward mechanism for protocol extensibility. That is, extensibility is achieved by allowing optional parameters, where each parameter is encoded as a TLV entity. Any proponents of outlawing TLV's all together, should indicate alternative mechanisms for extensibility (or make an explicit disclaimer that the extensibility is viewed as a non-goal). Finally, going back to your original argument that processing of TLV's are more complicated, as compared to fixed format packets. While this assertion may be correct, the assertion should not be taken in a vacuum. The actual impact of this extra complexity depends *very much* on the environment. For example, the impact on processing overhead of using TLV's for encoding routing information carried by a routing protocol is *significantly less* than the impact of using TLV's carried by data packets (this is because the volume of routing information is significantly lower than the volume of data traffic). So, one may wonder whether the impact of processing TLV's for encoding routing information in mobile-ip should be taken into the consideration or not. I am aware of at least one routing protocol (which is widely deployed in the Internet for quite a while) that *extensively* uses TLV's for encoding routing information. So far we didn't hear any complains about TLV's causing problems in this protocol. Since the IETF believes in the *operational* experience, I would suggest that the experience with this protocol should be used to ditch the discussion about the additional overhead associated with using TLV's for encoding routing information. Yakov.