home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
- Reported by John Johnston/National Semiconductor
-
- Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
- (MOBILEIP)
-
-
- Agenda
-
- o Review of mobility model
- o Liaison reports
- o Document status
- o Subcommittee reports
- o Short presentations
- o Interim Meeting
-
-
- Mobility Model
-
- Greg Minshall reviewed the mobility model for the first time attendees
- in the session. Basically, the problem was stated as finding a
- methodology (architecture, protocol, etc.) to support the routing of
- mobile hosts (MH). In most of the models presented to date, each MH has
- both a home address and a forwarding or care of address. Packets are
- sent to a MH via its home address. These packets are directed via
- normal routing to a base station which serves as the home base of the
- MH. This base station must know where the MH is at all times by
- maintaining the IP address of the base station currently serving the MH.
- Assuming the MH is ``not at home'' the base station then forwards the
- packet to its peer currently serving the MH, who in turn delivers the
- packet directly to the MH.
-
- The base station to base station delivery mechanism is called tunneling
- which can result in inefficient (dogleg) routing. An extreme example is
- a US-based Amsterdam IETF attendee trying to connect to a local
- Amsterdam host. Packets would be first routed over the Atlantic to the
- home base station in the US, then routed back over the Atlantic to the
- MH's current base station in Amsterdam, and finally delivered to the
- local Amsterdam host. This problem will be handled through the use of
- address caching.
-
- Finally, Greg clarified the scope of the working group as supporting
- media independent mobility. One solution must handle wireless IR,
- wireless RF, ethernet, etc.
-
-
- Liaison Reports
-
- Charlie Perkins reported that 802.11 is standardizing IEEE MAC protocols
- for wireless media. This body is meeting during the same week as the
- IETF. At their last session, Charlie proposed that the IETF working
- group inform 802.11 about all of the network layer events and
- indications that will be necessary to support mobile IP. Charlie
- indicated that 802.11 still has many open issues including MAC address
- selection (48-bit?).
-
- Steve Alexander did not report on the Dynamic Host Configuration Working
- Group (DHC) because the group has not met since the last IETF.
-
- Scott Kaplan, the liaison for the Domain Name System Working Group
- (DNS), did not report, because he was unable to attend the last DNS
- session.
-
- There was no report given for the Internet Protocol Security Protocol
- Working Group (IPSEC) because John Ioannidis was unable to attend this
- MOBILEIP session.
-
-
-
- Document Status
-
- o Fumio Teraoka from Sony will distribute a new version of his
- document when he returns from the IETF.
-
- o Dave Johnson has an updated version of his document available.
-
- o The working group has not heard from Columbia University.
-
- o Charlie Perkins will complete a new version of his document in
- several months.
-
- o Matsushita's draft work is continuing. A version will be released
- in several weeks.
-
-
-
- Subcommittee Reports
-
- o Terminology (Perkins)
-
- Charlie conveyed the confusion over inconsistent terminology by
- offering the following list:
-
- Host
- Mobile Host
- Correspondent Host - used to describe a destination host
- which may or may not be mobile
- Home Address Agent/Home Redirector (Location Server)
- Location Directory
- Base Station (Cell Manager)
- Visited Redirector/Remote Redirector
- Visitor's Redirector/Vistor's Redirector
- Cell Cluster
-
- Consistent terminology has not yet been selected. Consensus was
- that this must happen as soon as possible, but it was recognized
- that we must agree on the functionality of the things we are
- naming before we can agree on their names. Acronyms should be
- avoided at least until consistent terminology is adopted.
-
- o Beaconing (Perkins)
-
- Charlie described beaconing as the method by which a Mobile Host
- advertises itself to a base station. Some link layers have
- beaconing built-in and will not require layer 3 support.
- Mechanisms must be identified to support advertisement requests
- (solicitation), acceptance, and responses. Broadcast and
- multicast mechanisms are both under consideration. Open
- question - Can we use existing router discovery methods?
-
- o User Requirements (Rehkter)
-
- Yakov presented an overview of his latest document which will be
- available in several weeks. This document addresses the
- Internet model, mobile computing models, mobility dynamics,
- overhead considerations, scalability, performance transparency,
- manageability, security, and a comprehensive solution.
-
- o Database Service Interface (Rehkter) - no report
-
- o Tunneling/Redirecting (Dave Johnson)
-
- Tunneling is initiated by a Location Cache or a Location Server
- (Dave's terms). Dave is no longer supporting loose source
- routing because it is slow, buggy, and politically incorrect.
- Instead, the approach is to use encapsulation as described by
- Dave's latest document. This approach supports all existing IP
- options, cache coherency through the dynamic maintenance of an
- address forwarding list in each tunneled packet, loop discovery
- through the same address list, and base station state recovery.
- Cache coherency is also supported through a new mobile ICMP
- redirect message. Open questions are:
- 1. Does this break trace route?
- 2. Does this break MTU discovery?
-
- o Security (Ioannidis) - John Ioannidis was unable to attend
-
- o MIB - not discussed
-
-
-
- Short Presentations
-
- o Dave's Latest Document (Dave Johnson)
-
- Dave presented the essence of his latest proposal when he
- discussed tunneling/redirecting. It was decided to table
- further discussions until the WG had a chance to read the new
- version.
-
- o Review of Existing Mobile Services and Techniques (John Penners)
-
- John listed existing technologies and services. He briefly
- described RAM Mobile Data, ARDIS, PRMA (Packet Reservation
- Multiple Access), CDPD (Cellular Digital Packet Data), AMPS
- (Advanced Mobile Phone System), GSM (Groupe Special Mobile), and
- DECT (Digital European Cordless Telecom). See his document for
- for more details.
-
- o Experience with CU Mobile Implementation (Jim Binkley)
-
- Jim described problems encountered while porting the CU code.
- The 20 MHs were DOS based, while the 7 MSRs were ported to UNIX
- and supported mobility on each port. His results are based on 1
- month of testing.
- - DOS MH implementation difficulties outline the need for
- and MH architecture ASAP.
- - CU requirements = ARP, route, and raw sockets. Needed
- help from FTP software.
- - A multi-home bug was discovered. Because forwarding
- address != IP source address, MSRs got into trouble
- looking at addressing in previous layers.
- - intra segment routing needs to be addressed (ARP)
- - problems with traceroute, IP options, and 8k fragmentation
- when using IPIP encapsulation
- - implementation bug in MSR led to infinite ack loops
- - Installation of JI's embedded subnet demonstrated
- importance that home subnet not be in too many (> 4)
- partitions.
- - JI's embedded subnet causes MSRs to burn packets with
- proxy ARP turned on.
- - directed broadcast caused broadcast storms - routers don't
- realize its a broadcast, so it is forwarded.
- - when Jim "unplugged it and watch"ed, PC based NFS crashed
- and BSD NFS/UDP exhibited slow start
-
- o Beaconing Procedure (Charlie Perkins)
-
- Charlie outlined a beaconing procedure:
-
- 1. MH solicits to either a known MAC (unicast) or an
- unknown MAC (broadcast/multicast)
- 2. IAP (Internet Access Point) advertises (unicast or
- broadcast/multicast)
- 3. MH sends acceptance (unicast, with encrypted value?)
- 4. IAP sends ack or reject
- 5. MH updates old IAP
- 6. MH updates home redirector
-
- and proposed a beacon packet format:
-
- type, code, checksum
- IAP address
- timestamp/serial #
- beacon interval/lifetime
- random value to by encrypted
- MAC address
- type of authentication (including none)
-
- The status of Charlie's work:
- - intend to try icmp "host moved" function in IAPs
- - intend to release code fragments
- - will switch from simple beacon
- - need to select encapsulation/get protocol #/modify
- IPIP
- - intend to support public domain Mach implementation
- - desires routing to "shared media"
- - port to OS/2
-
-
- Interim Meeting
-
-
- There was consensus to meet somewhere on the east coast sometime before
- the November IETF. Possible dates and locations will be discussed via
- the mailing list.
-
-
-
- Further Discussion
-
-
- Yakov Rehkter's subcommittee report on user requirements created a
- discussion regarding CDPD. This technology was described by Mark
- Knopper:
-
-
- o Consortium of 9 large US and 1 Canadian voice carriers.
- o Data services over cellular infrastructure.
- o Mobile End System makes itself known to a Mobile Intermediary
- System.
- o Packets routed first to Intermediary System which forwards them to
- End System.
- o Billing through X.400.
-
-
- Suzy Brown expressed the desire for the IETF to press ahead quickly to
- avoid the potential for deployment of technology-specific solutions that
- will not interoperate with the Internet. Other infrastructure-based
- solutions are being developed (Ram Mobile Data, Mobitex, GSM, etc.).
-
- Along the same lines, John Penners' review of mobile services spawned
- discussions centering on the relationship between mobile IP and the many
- specialized services and providers. Steve Deering presented a model
- that emphasized the logical separation from wireless service providers
- and the Internet. This led to several observations:
-
-
- o We should view the technologies as physical medium below IP
- (service provider is at lower level).
-
- o Successful mobile IP deployment could leverage incorporation into
- technology-specific switches.
-
- o A goal is to avoid ``doglegs.''
-
- o Single hop at IP level (not single physical hop) in service
- provider.
-
- o Understanding providers' rules might help the dogleg problem.
-
- o Service providers need mobile IP to connect their clouds.
-
-
- Greg Minshall presented a similar model emphasizing how CDPD could
- create a coast-to-coast dogleg because it is not care of address-aware.
- This led to a discussion over whether it would be beneficial to take
- proactive measures to influence CDPD.
-
- During Charlie Perkins' presentation on beaconing procedures, Steve
- Deering emphasized the desirability that mobile hosts transmit new base
- station updates (as opposed to IAPs). Also, Steve stated that he would
- like to use multicast addressing over broadcast whenever possible
- (addressing must be consistent within a cell), and Greg indicated that
- we should request a ``well known'' address for this purpose.
-
-
- Open Issues
-
- o Can we use existing router discovery methods to support beaconing?
- o Does Dave Johnson's encapsulation technique break traceroute?
- o Does Dave Johnson's encapsulation technique break MTU discovery?
-
-
- Action Items
-
- o Steve Deering will contact Columbia University for an update on
- their work.
-
- o Determine if a working group should be formed within the IETF to
- deal with the issues of encapsulation.
-
- o Obtain a well known multicast address.
-
- o Obtain new ICMP number.
-
-
- Attendees
-
- Kannan Alagappan kannan@DSMAIL.ENET.DEC.COM
- Steve Alexander stevea@lachman.com
- Nick Alfano alfano@mpr.ca
- James Allard jallard@microsoft.com
- Bernt Allonen bal@tip.net
- Michael Anello mike@xlnt.com
- Anders Baardsgaad anders@cc.uit.no
- Cynthia Bagwell cbagwell@gateway.mitre.org
- Dennis Baker dbaker@wellfleet.com
- John Ballard jballard@microsoft.com
- Nutan Behki Nutan_Behki@qmail.newbridge.com
- Per Bilse bilse@ic.dk
- Jim Binkley jrb@ibeam.intel.com
- Carsten Bormann cabo@cs.tu-berlin.de
- Michael Brescia
- Ronald Broersma ron@nosc.mil
- Ramon Caceres ramon@mitl.research.panasonic.com
- Thomas Cordetti tomc@digibd.com
- Geert Jan de Groot geertj@ica.philips.nl
- Stephen Deering deering@parc.xerox.com
- Pierre Dupont dupont@mdd.comm.mot.com
- Kjeld Borch Egevang kbe@craycom.dk
- Julio Escobar jescobar@bbn.com
- Dan Frommer dan@jeremy.enet.dec.com
- Shoji Fukutomi fuku@furukawa.co.jp
- Robert Gilligan Bob.Gilligan@Eng.Sun.Com
- Jari Hamalainen jah@rctre.nokia.com
- Mark Handley mhandley@cs.ucl.ac.uk
- Gerd Holzhauer Holzhauer1@applelink.apple.com
- John Hopkins J_Hopkins@icrf.icnet.uk
- Steven Horowitz witz@chipcom.com
- Chris Howard chris_howard@inmarsat.org
- Geoff Huston g.huston@aarnet.edu.au
- David Johnson dbj@cs.cmu.edu
- John Johnston john@berlioz.nsc.com
- Philip Jones p.jones@jnt.ac.uk
- Marijke Kaat marijke@sara.nl
- Scott Kaplan scott@wco.ftp.com
- Ton Koelman koelman@stc.nato.int
- Mark Kosters markk@internic.net
- Mark Laubach laubach@hpl.hp.com
- Tony Li tli@cisco.com
- Susan Lin suelin@vnet.ibm.com
- Cynthia Martin martin@spica.disa.mil
- Donald Merritt don@arl.army.mil
- Paul Milazzo milazzo@bbn.com
- Greg Minshall minshall@wc.novell.com
- William Miskovetz misko@cisco.com
- Keith Mitchell keith@pipex.net
- Henri Moelard henri.moelard@utrecht.ncr.com
- Jun Murai jun@wide.ad.jp
- Ronny Nilsen Ronny.Nilsen@usit.uio.no
- Petri Ojala ojala@eunet.fi
- Zbigniew Opalka zopalka@agile.com
- John Penners jpenners@advtech.uswest.com
- Charles Perkins perk@watson.ibm.com
- Jim Rees Jim.Rees@umich.edu
- Yakov Rekhter yakov@watson.ibm.com
- Henry Sanders henrysa@microsoft.com
- Hal Sandick sandick@vnet.ibm.com
- William Simpson Bill.Simpson@um.cc.umich.edu
- Fumio Teraoka tera@csl.sony.co.jp
- Antoine Trannoy trannoy@crs4.it
- Thierry Turletti turletti@sophia.inria.fr
- Werner Vogels werner@inesc.pt
- Jost Weinmiller jost@prz.tu-berlin.d400.de
- Kirk Williams kirk@sbctri.sbc.com
- Rachel Willmer rachelw@spider.co.uk
- Sam Wilson sam.wilson@ed.ac.uk
- Wilfried Woeber Wilfried.Woeber@CC.UniVie.ac.at
- Jessica Yu jyy@merit.edu
- Romeo Zwart romeo@sara.nl
-