home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-93jul.txt < prev    next >
Encoding:
Text File  |  1993-09-16  |  15.2 KB  |  394 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by John Johnston/National Semiconductor
  5.  
  6. Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
  7. (MOBILEIP)
  8.  
  9.  
  10. Agenda
  11.  
  12.    o Review of mobility model
  13.    o Liaison reports
  14.    o Document status
  15.    o Subcommittee reports
  16.    o Short presentations
  17.    o Interim Meeting
  18.  
  19.  
  20. Mobility Model
  21.  
  22. Greg Minshall reviewed the mobility model for the first time attendees
  23. in the session.  Basically, the problem was stated as finding a
  24. methodology (architecture, protocol, etc.)  to support the routing of
  25. mobile hosts (MH). In most of the models presented to date, each MH has
  26. both a home address and a forwarding or care of address.  Packets are
  27. sent to a MH via its home address.  These packets are directed via
  28. normal routing to a base station which serves as the home base of the
  29. MH. This base station must know where the MH is at all times by
  30. maintaining the IP address of the base station currently serving the MH.
  31. Assuming the MH is ``not at home'' the base station then forwards the
  32. packet to its peer currently serving the MH, who in turn delivers the
  33. packet directly to the MH.
  34.  
  35. The base station to base station delivery mechanism is called tunneling
  36. which can result in inefficient (dogleg) routing.  An extreme example is
  37. a US-based Amsterdam IETF attendee trying to connect to a local
  38. Amsterdam host.  Packets would be first routed over the Atlantic to the
  39. home base station in the US, then routed back over the Atlantic to the
  40. MH's current base station in Amsterdam, and finally delivered to the
  41. local Amsterdam host.  This problem will be handled through the use of
  42. address caching.
  43.  
  44. Finally, Greg clarified the scope of the working group as supporting
  45. media independent mobility.  One solution must handle wireless IR,
  46. wireless RF, ethernet, etc.
  47.  
  48.  
  49. Liaison Reports
  50.  
  51. Charlie Perkins reported that 802.11 is standardizing IEEE MAC protocols
  52. for wireless media.  This body is meeting during the same week as the
  53. IETF. At their last session, Charlie proposed that the IETF working
  54. group inform 802.11 about all of the network layer events and
  55. indications that will be necessary to support mobile IP. Charlie
  56. indicated that 802.11 still has many open issues including MAC address
  57. selection (48-bit?).
  58.  
  59. Steve Alexander did not report on the Dynamic Host Configuration Working
  60. Group (DHC) because the group has not met since the last IETF.
  61.  
  62. Scott Kaplan, the liaison for the Domain Name System Working Group
  63. (DNS), did not report, because he was unable to attend the last DNS
  64. session.
  65.  
  66. There was no report given for the Internet Protocol Security Protocol
  67. Working Group (IPSEC) because John Ioannidis was unable to attend this
  68. MOBILEIP session.
  69.  
  70.  
  71.  
  72. Document Status
  73.  
  74.    o Fumio Teraoka from Sony will distribute a new version of his
  75.      document when he returns from the IETF.
  76.  
  77.    o Dave Johnson has an updated version of his document available.
  78.  
  79.    o The working group has not heard from Columbia University.
  80.  
  81.    o Charlie Perkins will complete a new version of his document in
  82.      several months.
  83.  
  84.    o Matsushita's draft work is continuing.  A version will be released
  85.      in several weeks.
  86.  
  87.  
  88.  
  89. Subcommittee Reports
  90.  
  91.    o Terminology (Perkins)
  92.  
  93.         Charlie conveyed the confusion over inconsistent terminology by
  94.         offering the following list:
  95.  
  96.             Host
  97.             Mobile Host
  98.             Correspondent Host - used to describe a destination host
  99.                                  which may or may not be mobile
  100.             Home Address Agent/Home Redirector (Location Server)
  101.             Location Directory
  102.             Base Station (Cell Manager)
  103.             Visited Redirector/Remote Redirector
  104.             Visitor's Redirector/Vistor's Redirector
  105.             Cell Cluster
  106.  
  107.         Consistent terminology has not yet been selected.  Consensus was
  108.         that this must happen as soon as possible, but it was recognized
  109.         that we must agree on the functionality of the things we are
  110.         naming before we can agree on their names.  Acronyms should be
  111.         avoided at least until consistent terminology is adopted.
  112.  
  113.    o Beaconing (Perkins)
  114.  
  115.         Charlie described beaconing as the method by which a Mobile Host
  116.         advertises itself to a base station.  Some link layers have
  117.         beaconing built-in and will not require layer 3 support.
  118.         Mechanisms must be identified to support advertisement requests
  119.         (solicitation), acceptance, and responses.  Broadcast and
  120.         multicast mechanisms are both under consideration.  Open
  121.         question - Can we use existing router discovery methods?
  122.  
  123.    o User Requirements (Rehkter)
  124.  
  125.         Yakov presented an overview of his latest document which will be
  126.         available in several weeks.  This document addresses the
  127.         Internet model, mobile computing models, mobility dynamics,
  128.         overhead considerations, scalability, performance transparency,
  129.         manageability, security, and a comprehensive solution.
  130.  
  131.    o Database Service Interface (Rehkter) - no report
  132.  
  133.    o Tunneling/Redirecting (Dave Johnson)
  134.  
  135.         Tunneling is initiated by a Location Cache or a Location Server
  136.         (Dave's terms).  Dave is no longer supporting loose source
  137.         routing because it is slow, buggy, and politically incorrect.
  138.         Instead, the approach is to use encapsulation as described by
  139.         Dave's latest document.  This approach supports all existing IP
  140.         options, cache coherency through the dynamic maintenance of an
  141.         address forwarding list in each tunneled packet, loop discovery
  142.         through the same address list, and base station state recovery.
  143.         Cache coherency is also supported through a new mobile ICMP
  144.         redirect message.  Open questions are:
  145.             1. Does this break trace route?
  146.             2. Does this break MTU discovery?
  147.  
  148.    o Security (Ioannidis) - John Ioannidis was unable to attend
  149.  
  150.    o MIB - not discussed
  151.  
  152.  
  153.  
  154. Short Presentations
  155.  
  156.    o Dave's Latest Document (Dave Johnson)
  157.  
  158.         Dave presented the essence of his latest proposal when he
  159.         discussed tunneling/redirecting.  It was decided to table
  160.         further discussions until the WG had a chance to read the new
  161.         version.
  162.  
  163.    o Review of Existing Mobile Services and Techniques (John Penners)
  164.  
  165.         John listed existing technologies and services.  He briefly
  166.         described RAM Mobile Data, ARDIS, PRMA (Packet Reservation
  167.         Multiple Access), CDPD (Cellular Digital Packet Data), AMPS
  168.         (Advanced Mobile Phone System), GSM (Groupe Special Mobile), and
  169.         DECT (Digital European Cordless Telecom).  See his document for
  170.         for more details.
  171.  
  172.    o Experience with CU Mobile Implementation (Jim Binkley)
  173.  
  174.         Jim described problems encountered while porting the CU code.
  175.         The 20 MHs were DOS based, while the 7 MSRs were ported to UNIX
  176.         and supported mobility on each port.  His results are based on 1
  177.         month of testing.
  178.             - DOS MH implementation difficulties outline the need for
  179.               and MH architecture ASAP.
  180.             - CU requirements = ARP, route, and raw sockets.  Needed
  181.               help from FTP software.
  182.             - A multi-home bug was discovered.  Because forwarding
  183.               address != IP source address, MSRs got into trouble
  184.               looking at addressing in previous layers.
  185.             - intra segment routing needs to be addressed (ARP)
  186.             - problems with traceroute, IP options, and 8k fragmentation
  187.               when using IPIP encapsulation
  188.             - implementation bug in MSR led to infinite ack loops
  189.             - Installation of JI's embedded subnet demonstrated
  190.               importance that home subnet not be in too many (> 4)
  191.               partitions.
  192.             - JI's embedded subnet causes MSRs to burn packets with
  193.               proxy ARP turned on.
  194.             - directed broadcast caused broadcast storms - routers don't
  195.               realize its a broadcast, so it is forwarded.
  196.             - when Jim "unplugged it and watch"ed, PC based NFS crashed
  197.               and BSD NFS/UDP exhibited slow start
  198.  
  199.    o Beaconing Procedure (Charlie Perkins)
  200.  
  201.             Charlie outlined a beaconing procedure:
  202.  
  203.                 1. MH solicits to either a known MAC (unicast) or an
  204.                    unknown MAC (broadcast/multicast)
  205.                 2. IAP (Internet Access Point) advertises (unicast or
  206.                    broadcast/multicast)
  207.                 3. MH sends acceptance (unicast, with encrypted value?)
  208.                 4. IAP sends ack or reject
  209.                 5. MH updates old IAP
  210.                 6. MH updates home redirector
  211.  
  212.             and proposed a beacon packet format:
  213.  
  214.                 type, code, checksum
  215.                 IAP address
  216.                 timestamp/serial #
  217.                 beacon interval/lifetime
  218.                 random value to by encrypted
  219.                 MAC address
  220.                 type of authentication (including none)
  221.  
  222.             The status of Charlie's work:
  223.                 - intend to try icmp "host moved" function in IAPs
  224.                 - intend to release code fragments
  225.                 - will switch from simple beacon
  226.                 - need to select encapsulation/get protocol #/modify
  227.                   IPIP
  228.                 - intend to support public domain Mach implementation
  229.                 - desires routing to "shared media"
  230.                 - port to OS/2
  231.  
  232.  
  233. Interim Meeting
  234.  
  235.  
  236. There was consensus to meet somewhere on the east coast sometime before
  237. the November IETF. Possible dates and locations will be discussed via
  238. the mailing list.
  239.  
  240.  
  241.  
  242. Further Discussion
  243.  
  244.  
  245. Yakov Rehkter's subcommittee report on user requirements created a
  246. discussion regarding CDPD. This technology was described by Mark
  247. Knopper:
  248.  
  249.  
  250.    o Consortium of 9 large US and 1 Canadian voice carriers.
  251.    o Data services over cellular infrastructure.
  252.    o Mobile End System makes itself known to a Mobile Intermediary
  253.      System.
  254.    o Packets routed first to Intermediary System which forwards them to
  255.      End System.
  256.    o Billing through X.400.
  257.  
  258.  
  259. Suzy Brown expressed the desire for the IETF to press ahead quickly to
  260. avoid the potential for deployment of technology-specific solutions that
  261. will not interoperate with the Internet.  Other infrastructure-based
  262. solutions are being developed (Ram Mobile Data, Mobitex, GSM, etc.).
  263.  
  264. Along the same lines, John Penners' review of mobile services spawned
  265. discussions centering on the relationship between mobile IP and the many
  266. specialized services and providers.  Steve Deering presented a model
  267. that emphasized the logical separation from wireless service providers
  268. and the Internet.  This led to several observations:
  269.  
  270.  
  271.    o We should view the technologies as physical medium below IP
  272.      (service provider is at lower level).
  273.  
  274.    o Successful mobile IP deployment could leverage incorporation into
  275.      technology-specific switches.
  276.  
  277.    o A goal is to avoid ``doglegs.''
  278.  
  279.    o Single hop at IP level (not single physical hop) in service
  280.      provider.
  281.  
  282.    o Understanding providers' rules might help the dogleg problem.
  283.  
  284.    o Service providers need mobile IP to connect their clouds.
  285.  
  286.  
  287. Greg Minshall presented a similar model emphasizing how CDPD could
  288. create a coast-to-coast dogleg because it is not care of address-aware.
  289. This led to a discussion over whether it would be beneficial to take
  290. proactive measures to influence CDPD.
  291.  
  292. During Charlie Perkins' presentation on beaconing procedures, Steve
  293. Deering emphasized the desirability that mobile hosts transmit new base
  294. station updates (as opposed to IAPs).  Also, Steve stated that he would
  295. like to use multicast addressing over broadcast whenever possible
  296. (addressing must be consistent within a cell), and Greg indicated that
  297. we should request a ``well known'' address for this purpose.
  298.  
  299.  
  300. Open Issues
  301.  
  302.    o Can we use existing router discovery methods to support beaconing?
  303.    o Does Dave Johnson's encapsulation technique break traceroute?
  304.    o Does Dave Johnson's encapsulation technique break MTU discovery?
  305.  
  306.  
  307. Action Items
  308.  
  309.    o Steve Deering will contact Columbia University for an update on
  310.      their work.
  311.  
  312.    o Determine if a working group should be formed within the IETF to
  313.      deal with the issues of encapsulation.
  314.  
  315.    o Obtain a well known multicast address.
  316.  
  317.    o Obtain new ICMP number.
  318.  
  319.  
  320. Attendees
  321.  
  322. Kannan Alagappan         kannan@DSMAIL.ENET.DEC.COM
  323. Steve Alexander          stevea@lachman.com
  324. Nick Alfano              alfano@mpr.ca
  325. James Allard             jallard@microsoft.com
  326. Bernt Allonen            bal@tip.net
  327. Michael Anello           mike@xlnt.com
  328. Anders Baardsgaad        anders@cc.uit.no
  329. Cynthia Bagwell          cbagwell@gateway.mitre.org
  330. Dennis Baker             dbaker@wellfleet.com
  331. John Ballard             jballard@microsoft.com
  332. Nutan Behki              Nutan_Behki@qmail.newbridge.com
  333. Per Bilse                bilse@ic.dk
  334. Jim Binkley              jrb@ibeam.intel.com
  335. Carsten Bormann          cabo@cs.tu-berlin.de
  336. Michael Brescia
  337. Ronald Broersma          ron@nosc.mil
  338. Ramon Caceres            ramon@mitl.research.panasonic.com
  339. Thomas Cordetti          tomc@digibd.com
  340. Geert Jan de Groot       geertj@ica.philips.nl
  341. Stephen Deering          deering@parc.xerox.com
  342. Pierre Dupont            dupont@mdd.comm.mot.com
  343. Kjeld Borch Egevang      kbe@craycom.dk
  344. Julio Escobar            jescobar@bbn.com
  345. Dan Frommer              dan@jeremy.enet.dec.com
  346. Shoji Fukutomi           fuku@furukawa.co.jp
  347. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  348. Jari Hamalainen          jah@rctre.nokia.com
  349. Mark Handley             mhandley@cs.ucl.ac.uk
  350. Gerd Holzhauer           Holzhauer1@applelink.apple.com
  351. John Hopkins             J_Hopkins@icrf.icnet.uk
  352. Steven Horowitz          witz@chipcom.com
  353. Chris Howard             chris_howard@inmarsat.org
  354. Geoff Huston             g.huston@aarnet.edu.au
  355. David Johnson            dbj@cs.cmu.edu
  356. John Johnston            john@berlioz.nsc.com
  357. Philip Jones             p.jones@jnt.ac.uk
  358. Marijke Kaat             marijke@sara.nl
  359. Scott Kaplan             scott@wco.ftp.com
  360. Ton Koelman              koelman@stc.nato.int
  361. Mark Kosters             markk@internic.net
  362. Mark Laubach             laubach@hpl.hp.com
  363. Tony Li                  tli@cisco.com
  364. Susan Lin                suelin@vnet.ibm.com
  365. Cynthia Martin           martin@spica.disa.mil
  366. Donald Merritt           don@arl.army.mil
  367. Paul Milazzo             milazzo@bbn.com
  368. Greg Minshall            minshall@wc.novell.com
  369. William Miskovetz        misko@cisco.com
  370. Keith Mitchell           keith@pipex.net
  371. Henri Moelard            henri.moelard@utrecht.ncr.com
  372. Jun Murai                jun@wide.ad.jp
  373. Ronny Nilsen             Ronny.Nilsen@usit.uio.no
  374. Petri Ojala              ojala@eunet.fi
  375. Zbigniew Opalka          zopalka@agile.com
  376. John Penners             jpenners@advtech.uswest.com
  377. Charles Perkins          perk@watson.ibm.com
  378. Jim Rees                 Jim.Rees@umich.edu
  379. Yakov Rekhter            yakov@watson.ibm.com
  380. Henry Sanders            henrysa@microsoft.com
  381. Hal Sandick              sandick@vnet.ibm.com
  382. William Simpson          Bill.Simpson@um.cc.umich.edu
  383. Fumio Teraoka            tera@csl.sony.co.jp
  384. Antoine Trannoy          trannoy@crs4.it
  385. Thierry Turletti         turletti@sophia.inria.fr
  386. Werner Vogels            werner@inesc.pt
  387. Jost Weinmiller          jost@prz.tu-berlin.d400.de
  388. Kirk Williams            kirk@sbctri.sbc.com
  389. Rachel Willmer           rachelw@spider.co.uk
  390. Sam Wilson               sam.wilson@ed.ac.uk
  391. Wilfried Woeber          Wilfried.Woeber@CC.UniVie.ac.at
  392. Jessica Yu               jyy@merit.edu
  393. Romeo Zwart              romeo@sara.nl
  394.