Subject: [MOBILE-IP] Draft Version: Minutes of Mobile IP meetings at IETF46

From: Basavaraj Patil <[email-masked]>
Date: Fri, 19 Nov 1999 16:41:24 -0600

If anybody has additional comments or views that they captured at the
meetings, please do send them to me by Nov 23rd.

========================================================

Logistics:
----------
The Mobile IP WG met in Washington D.C for two sessions on Thursday,
November 11th '99 from 9 - 11.30 AM and 3:30 - 5:30 PM.

Attendance at the sessions was approximately 226.

The meeting minutes for both sessions have been provided by Pete McCann.

|-----------------------------------------------------------|
| Morning Meeting (9:00 AM - 11:30 AM)  |
|-----------------------------------------------------------|

WG Status
----------------
Status of MN-NAI draft - The IESG has assigned an Experimental status
to this document.
Charles says it should be proposed standard - why don't we ask
for this change now?
Pat: "It's not clear how Mobile IP will make use of NAI" said the IESG.
But we need to make it work with other ROAMOPS stuff.
Raj says we will make another request to the IESG to change the status
to PS.

WG documents that will go to last call:
-3Gwireless micro-mobility
-Vendor/Org extensions
-Mobile IP for IPv6

Dave Johnson
Got a lot of comments at the last minute on Mobile IPv6
Mostly regarding IPSec interactions. We will go to working group last
call shortly, then to IETF last call.

Mobile IP Requirements for AAA
Raj says that this document is owned by the Mobile IP WG and the WG
needs to arrive at a consensus on the requirements. The intent is to
feed the requirements as input to the AAA WG.
The WG has been requested to provide more input into AAA
Pat: AAA WG has a very aggressive timeline.  People should read this draft
and provide comments. Maybe the only way to do that is to take it to
last call.

Draft Presentations :
------------------------------

1. Mobile IP Based Micro Mobility Management Protocol for 3Gwireless
Network Systems - draft-ietf-mobileip-3Gwireless-ext-01.txt
(Rajesh Bhalla)

It's a WG document because it will aid deployment of Mobile IP.
The document is a work of TIA TR45.4 and 3GPP2 TSG-A
Lots of contributing companies
Overview of 3G wireless network service domain - RNN, PDSN, R-P network
PDSN terminates link-layer and hosts a foreign agent
Draft focuses on R-P connection - minimizes latency of handoff

R-P Mobillity protocol objectives
  minimize RNN handoff latency and round-trip signaling through the
  packet network
  Extend link layer connectivity beyond a physical layer termination
  RNN and link-layer termination PDSN
  Provide mobility from RNN to RNN
  Provide a secure signaling mechanism for data transport

R-P Mobility protocol overview
  RP connection established by RNN when it becomes aware of the MN
  and has link-layer identity
  Mobile IP based registration and reply procedures to establish the
connection
  Then use GRE encapsulation to send link-layer fragments or frames
  The RP connection appears as a link-layer termination point from
  which packets can be sent/received

Message flows for connection setup

Session specific extension
  Carries link-layer identifier (IMSI)
  Carries session ID for those link-layers that support simultaneous
connection

Message flows for handoff
  Registration update message to tear-down connection

Q: Raj & Charles: could we use Binding Update for this?
A: yes, but standardization status of Route Optimization is unclear

Q: Dave Johnson: why is your schedule so tight?
A: (rajesh and lipford) yes, our schedule is tight - TSG is already in
   last call

Q: Ramjee: is RP an IP network?
A: yes
Q: Why not send binding update if the FA is at the RNN?
Pete: We have a requirement to give good service to nodes without MIP
      clients.  This is why RP must tunnel PPP data.

Last slide: handoff to a new PDSN, we must to end-to-end Mobile IP
registration

Q: Nordmark: how does old PDSN know the MN has gone?
A: timeouts

Q: when do you do a PDSN change?
A: outside the scope

////////////////////////////////////////////////////////

2. Update to RFC2002 - MobileIPv4 revised (Charles Perkins)
(draft-ietf-mobileip-rfc2002-bis-00.txt)

Really, really nit-picky details
Some places in original draft said be careful about using
now it said just don't

MN must ignore reserved bits in advertisement instead of drop the
advertisement
Calculation of authentication extension must include SPI
FA can now configure a max number of pending registrations, and may
delete them if > 7 seconds old
FA must check for the case of MN registration even when on home network
Unrecognized set bits or unrecognized care-of address cause FA to drop
registration request

Max number of outstanding requests not standardize, but 7 seconds is
hardcoded.
Dave J. & Nordmark: why is this hard coded?
A: ok, we'll talk about it

Other changes: recursive -> nested

What to do with this draft?  Mandatory support for reverse tunneling?
Do we take it to draft standard or to an intermediate proposed
standard?  Does it become an RFC?

Some features have not been tested for interoperability - this would
hinder draft standard status

Pat: if there is a protocol change, it must go back to the beginning?
A: yes, if they are big
Dave: if changes reduce the maturity level, then yes, we have to go back
      to proposed
Pat: all interoperability already uses the new SPI calculation

Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get
   traffic forwarded directly rather than via HA.  Also MNs can introduce
   denial of service if they make a mistake in their registration
   messages - sometimes re-registrations can be redirected at a MN!
A: Reverse tunneling might be important enough to go in.

Q (Charles): Is this a revised draft or a new draft?
A: Raj : maybe it's just a revision and we should go to draft standard
A: Dave: a new proposed standard would be a new 6 month clock
Q: Nordmark: what about the untested features?
A: Charles: yes, that's a concern
Q: what about private addresses?
A: Charles: let's not tackle that yet
A: Raj: we had some discussion and came to consensus, but it doesn't
   need to go in this draft

Montenegro: We could support private addresses with RFC2344
Survey of the room on proposed vs draft for this revision:
about 25 for porposed, low single digits for draft,
a few abstainers.  Because of the low number of votes we will take the
question to the list.

///////////////////////////////////////////////////////

3. AAA Requirements for Mobile IP (Charles Perkins)
(draft-ietf-mobileip-aaa-reqs-00.txt)

This has been presented to AAA WG
Tom Hiller has a similar presentation
This is now a MIP WG item - please read it and comment

Interactions between Mobile IP and AAA
MN presents credentials to the FA
Credentials are sent to FAAA, HAAA where they are verified, sent to HA
AAA protocol should work without specific details of Mobile IP
Mobile IP should work without specific details of AAA
FA - FAAA association, HA-HAAA association

Trust relationships - generic model
Trust should really be security associations
MN - HAAA
FA - FAAA
HA - HAAA
FAAA - HAAA

Q: Johnson & Dommety: Can we really do away with security association
between MN and HA?  It's coded in the standards
A: Yes, this is a change, but people in industry like it
Q: Johson & Raj: this is a change.  Doesn't it break implementations?
A: Maybe, but this is a good way to model interaction between MIP and AAA
Q: Gopal: we need to keep RFC2002 as is
A: Charles: we are not breaking RFC2002, but we do need to change the
   requirement MN-HA extension
Q: Vipul: can't we just use MN-HA extension as is?
Q: Pat: AAAH will be generating session keys.  We need to know when to go
   to AAA vs. doing MIP
Q: Gopal: we could view HAAA & HA as one network.  We are asking AAAH to
   do Mobile IP
A: Pat: AAAH has no idea what a MIP RRQ looks like

AAA Model with local HA
Could dynamically allocate HA in the visited network

AAA Model with local everything
Maybe we use a credit card to get service

Q: what about co-located care-of address or IPv6?
A: IPv6 is another matter.  We need a v4 solution
DHCP server could run this protocol
Mark Munson: we need these features for commercial deployment; there is a
limited window
Nordmark: short term deployment of v4 is not going to work
Bernard: it is important that AAA gets features
Pat: a lot of cool things that we could do, but what do we really need?
There is a deployment people want to do.

Raj: we are out of time, let's take it to the mailing list
Charles: let's get comments soon.  We want MIP running on a lot of
         platforms very soon

///////////////////////////////////////////////////////

4. AAA Requirements for cdma2000 (Tom Hiller)
(draft-hiller-cdma2000-AAA-00.txt)

TR45.6 wireless data group
Carriers & vendors

Intro: packet data service for cdma2000; PPP service with limited mobillity
+
       Mobile IP
Public & Private network access
Avoid IPsec tunneling over air interface
HA in public or private network
Overlay, dual-authentication architecture

General Architecture
PDSN, AAA, VLR, HLR, HA

Radio network architecture via VLR/HLR
Then Mobile IP authentication - if not MIP, then use CHAP with PPP
Use Foreign Agent Challenge
Same AAA infrastructure must work for both mechanisms

NAI is used to route the AAA requests to the home AAA server

Serving network and foreign networks do not have a direct association
   May be via brokers
   May be direct in some cases

AAA Transport Requirements
  User profiles (different services authorized)
  Key distribution
    Pre-shared keys for IKE
    MN-FA and HA-FA and MN-HA keys
  Keys should be encrypted end-to-end but maybe not required initially

Key distribution should support
  HA to FA authentication extensions
  intradomain fast FA handoffs
  dynamic HA assignment
  pre-shared key for IKE between HA and FA

AAA Reliability
  Carrier grade reliability
  Reliable proxy chaining
  Configurable retransmission and fail-over
  Ability to detect silent failures of path to next AAA server

Minimize latency
  Single round-trip for AAA and MIP
  Encode a MIP RRQ in same message to avoid multiple round trips
  Fast FA to FA handoff

Message Integrity and non-repudiation
  Replay protection & non-repudiation for all authentication and
  accounting messages
  Match accounting to authorization

cdma2000 MIP deployment status
  We need FAC with RADIUS-like extension
  Deployment depends on NAI and FAC drafts
  We need a robust AAA infrastructure

Q: NAI privacy is not a first requirement?
A: We're studying it, we don't know if it's a long term requirement or not

/////////////////////////////////////////////////////

5. Mobile IP Vendor/Organization Specific Extensions (Gopal Dommety)
(draft-ietf-mobileip-vendor-ext-00.txt)

Facilitate extensions for research and experimentation
Deployment in specific environments
Will help standards organizations (TR45.6) to standardize usage in
specific environments

Two extensions are proposed:
  Normal Vend/Org specific extension (NVSE)
  Type should be in range 128 to 255
  Vendor ID - higher order=0, low 3 bytes are SMI number for org/vendor
  Opaque data

  Critical Vend/Org specific (CVSE)
  Type in range 0-127
  Length is two bytes long

Q: Pat: we all know there will be an identifier in the opaque data.
   In RADIUS, we ended up with a lot of different encodings for the types.
   Maybe we should add a "type" in the opaque data field.
A: Ok, maybe we will add a two-byte type for the data.

Three new error codes
Reg denied by FA  - TBD code 1 unsupported vendor specific
Reg denied by HA

Q: Vipul: since type is critical, should we revise RFC2002 to add error
   message if critical type is not recognized?
A: good idea, but we should defer to Charles
A: Charles: he's happy to put it in if the group agrees

Raj: next step is to make the changes and go to last call
Please send comments.  Any major concerns?

//////////////////////////////////////////////////////

6. KENA (Raja Narayanan)
(draft-mkhalil-mobileip-kena-00.txt)

KENA concepts/highlights
  Centralized key distribution framework
  protects user privacy and enables authentication
  is real time sensitive
  can be easily implemented using extensions to existing protocols

Requirements over Mobile IP
  MN & FA MUST be authenticated before start of any data session
  User privacy MUST be protected until FA is authenticated
  Keys are distributed for a particular MN registration session
  Layer 3 encruption MUST be facillitated
  Central authority controls keys

KENA vs Mobile IP AAA requirements
  Identify or create SA between MN-HA
  Identify or create SA between MN-FA
  Identify or create SA between FA-HA
  Participate in distribution of SA/SPI to MIP
  AAA server must validate certs   (NOT APPLICABLE TO KENA)

Assumptions:
  Shared secret or asymmetric keys between MN and Home
  Secure path between the FA and Home
  Home IP address is protected
  NAI extension is encrupted
  Public HA address
  IP extensions encrypted using shared secret
  Layer 2 is sent in the clear

Lots of questions about need for NAI privacy and traceability
If NAI is encrypted, it is still the same every time and would be traceable
Same for link-layer identifier

We might need an NAI for routing through AAA infrastructure.  HA
address might be missing if it is allocated dynamically.

Once Registration with HA is done, NAI is sent back to the FA in the
clear Session keys are also sent back, encrypted by the pre-existing
security associations
Then all three links are encrypted

////////////////////////////////////////////////////////

7. AAA Session Keys (Pat Calhoun)
(draft-calhoun-mobileip-aaa-keys-00.txt)

It's now an individual contribution. The WG was asked if this needs to
be a WG document. General agreement reached. The document will be
resubmitted as a WG document.

MIP AAA requirements state that KDC is required
Creates 3 keys MN-HA, MN-FA, FA-HA

Problem: session keys destined for FA and HA will be delivered in some
         AAA protocol
         MN must get the keys in some other way

Proposal: Session keys destined for the MN are sent to the HA in the
          AAA message
          HA adds these session keys to the Registration Reply
          Mobile node gets the keys when the reply arrives

Session keys are distributed in two extensions with given format
  (look at draft)
  Security Algorithm, AAA SPI, FA/HA SPI, FA/HA security information

Without this draft, KDC would be useless for the mobile node
If KDC is a Mobile IP WG requirement, this document must become a WG work
item

Q: Gopal: couldn't this be encrypted with the MN-HA key/SPI, not the
   MN-AAA key/SPI
Q: Nordmark: shouldn't we hide the SPIs?
A: Yes, maybe we will make these changes

/////////////////////////////////////////////////////

|-----------------------------------------------------------|
| Afternoon Meeting (3:30 PM - 5:30 PM) |
|-----------------------------------------------------------|
1. Mobile IP Extension Rationalization (Mohamed Khalil)
(draft-mkhalil-mobileip-mier-00.txt)

Add a "content type" and "E" field.  SPI present if "E" is present.
Then some session data.
Use "type" field like "NAI" or "Authentication Extension" then use
Content-Type to be "MN-HA" or "MN-FA", or "MN" "HA" "FA".  Add an "ET" bit

New buffer management extension
0 Buffer size extension
1 Buffer lease time extension
2 IP filter extension

If someday we run out of types, we need to allocate 2 new types,
one from 0-127, another from 128-256

Q: Pat: why can't we start using the new extended types right away?
A: the long-term solution is harder to manage
Q: Pat: what about the space after the E bit?
A: Different extensions can have different flags
Q: Pat: why cant we encode encryption in the content-type?
A: User could do that if he wants

Q: Charlie: In auth extension, why not have a longer length and not
keep the reserved bits?  They could be taken care of with the SPI.

Q: Dave Johnson: why are we re-doing encryption?  Why not use ESP?
A: this is just like what Pat presented this morning

Q: Why do we need the E bit?
A: Sometimes SPI doesn't need to be present
Q: Pat: there are many types that don't need SPI?

Q:  Raj: what if we just had a reserved section, not an E bit?
A: yes, E bit not needed for many types

Q: Security association may be used for protecting the extension only?
   Then maybe any attribute would need an SPI?
A: Maybe... we'll take further questions on the list.

Q: Is there interest in making this draft a WG item?
(Raj asks) is there a real concern we are running out of Type space?
Q: Pat: how many type numbers are assigned today?
A: Charles: about 20 or so.  We should have a bit more discussion on the
mailing list about whether this is needed.
Raj: ok, more discussion on the list, then we will decide.

//////////////////////////////////////////////////////////

2. Mobile IPv6 Connectathon Report (Francis Dupont)

Organized by the G6 group

Implementations by :
    BULL (AIX)
    ERICSSON - TELEBIT (FreeBSD)
    NEC (FreeBSD)
    INRIA (FreeBSD)

Tests were done between MN & fixed correspondent, and MN &MN.
Some tests were done through the 6bone but most tests run on a local
WaveLAN.

Graph of network connectivity

Suggestions for improvement in IPv6 draft
   Retransmissions of Binding Updates should increment the sequence number
   Renumbering, HA should DAD before binding ACK
   Draft has to do further into details of HA discovery

Q: Dave Johnson: I have seen only the second one mentioned on the mailing
list

Conclusions
   Test event was very successful
   Some IPv6 stacks exist and can communicate
  Movement detection needs clarification
  No tests but discussion about IPSEC, IKE, and MIPv6 - SA with mobile
SHOULD use a wildcard source

Q: Dave Johnson: not enough details. where can I get more?
(clarification in French)
A: last slide: http://www.loria.fr/~ichris/mobipv6/connectathon99/index.html

///////////////////////////////////////////////////////////

3. Cellular IP Update (Andrew Campbell)
(draft-valko-cellularip-01.txt)

Woody Allen story.... (Bulldozer noise in the background)

Crossroads in the development of wireless and mobile IP
If wireless ISPs emerge as wired ISPs have, they can introduce a lot of new
interesting technology
This group is poised to make substantial improvements to Mobile IP to make
it work in this environment

Cellular IP project
Started at Columbia with Ericsson
Simple Vision: combining the strengths of Cellular + IP without
inheriting their weaknesses, leverage MIP work

Design Goals
Fast and seamless handoff
   Per-mobile routing soft-state
   Loss and delay sensitive applications
Scalable and real-time location management
   Support for active and idle mobile hosts
   Routing cache, paging cache/implicit paging
Simple access network design
  Off-shelf IP based boxes  (don't need expensive MSC/BSC)
  Plug and play configuration
  Support L2 or L3 networks

Design Goals (cont)
 Single scalable protocol
   Piconet, LAN, MAN
Simplicity
  No new packet formats, encaps, or address space
  Distribute Mobile aware information (MIP)
Promote wireless QoS

A lot of proposals in the past
   HAWAII, Cellular IP, THEMA, hierarchical MIP

Diagram: mobile devices, base stations, gateways, home agent

Cellular IP access network
  Main algorithms:
     routing, handoff, paging
  MNs interact with base stations simply by sending IP packets
  Routing cache on a per-mobile basis (at gateway)
  Paging cache used to find idle mobiles

Major changes to the Internet Draft
  Security support added
     Mobile and network have shared secret
     Control messages are authenticated
     Mobile goes through authorization phase, creates a PID, used by MN as
     it goes through the access network
  Paging areas added
     reduces messaging of idle hosts
  Semi-soft handoff with/without "delay devices"
     support for delay and loss sensitive apps (TCP and RTP/UDP) with fast
     handoff
     Sends a route-update packet to the new base station, then can receive
     packets from both old and new base station
     Delay devices introduced to do "coarse synchronization"

Minor changes to the I-D
  Cache mappings cannot be created or modified by data packets, but can
      be refreshed
  Optional paging tear-down
      Use soft-state whenever possible
  Control packets are ICMP
  Control packets must contain timestamp and auth information

Web page for Cellular IP
  Test bed has been running about a year
  Downloadable code
  Programming manual

comet.columbia.edu/cellularip/

Joint work with many people

/////////////////////////////////////////////////////////////

4. Cellular IP Performance (Javier Gomez)
(draft-gomez-cellularip-perf-00.txt)

Implementation, Topology, evaluation
  handoff
  Active/idle

Cellular IP nodes/mobile hosts: Pentium 300 MHz
Wired links: ethernet 10/100
wireless linnks: 802.11 with new device drivers

Software
Runs in user space, based on PCAP
easy to upgrade to newer freeBSD releases
easy to port to other UNIX OSes

Implementation Model
Dowlink interface, uplink interface, PCAP in kernel space
Routing cache, paging cache, in user space

Topology I: Point to Point wired links
handoffs can be based on SNR, or automatically
Cellular IP gateway connected to the Internet

Topology II: Ethernet
shared medium
Must now keep track of mac addresses

Handoff performance/UDP
Wavelan 2Mbps
CH transmits constant bitrate traffic
Hard handoff - disconnect from one BS and connect to another
blind time is proportional to prop delay to crossover switch

Performance graph
Packet loss per handoff vs. mobile-gateway round-trip time
Linear

Repeat experiment with TCP (TTCP)
performance graph of downlink TCP throughput vs. number of handoffs per
minute
Semisoft handoff improves throughput - using a buffer improves throughput
even more

Q: Charlie: what is semi-soft handoff?
A: immediately upon handoff, we can send control messages to the old BS to
forward packets

Active/idle timeout performance
MNs declare themselves active when they have traffic to send
It would be nice if MN could be kept active for a long time so that we
    avoid paging overhead
Graph of rate of paging traffic vs. applications given 100ms or 1sec active
    hold time after transmission
Local applications can deal with short active times, but inter-continental
    delays are high and require higher active hold times (during which the
    MN actively updates its location, so paging is avoided)

Scalability issues
Cellular IP uses per-host routes
Achieves scalability by a separation of active/idle mobile hosts
Most hosts are idle at any given time

Other scalability issues: increase the size of the database in which we
      search for a mobile
Graph: nodes throughput in Mbps vs. number of MNs in the database
Is not too bad for IP forwarding to a single user when we do binary search
Linear search performance gets very poor as number of MNs increases

Q: do you really mean 10^6 MNs?
A: yes
Q: how many routers need to be updated?
A: depends on the scenario

source code is at comet.columbia.edu/cellularip

Q: you are not including changes in the over-the-air data rate as the MN
   changes speed? As the active nodes move at different velocities, they
   change their data rate.
A: yes, we need more signaling

Q: performance are for TCP streams.  What about latency?
A: no.  Compared throughput with IP forwarding
Q: look at CDPD - its latency is too high.
A: Achieving 90% of what IP forwarding can do, so latency should not
   be an issue

/////////////////////////////////////////////////

5. Minimal latency secure handoff (Pat Calhoun)
(draft-calhoun-mobileip-min-lat-handoff-00.txt)

What can we do to minimize latencey when MN-FA share a key?

Mobile IP WG has a AAA KDC requirement
Home AAA server acts as a key distribution center and creates session keys

Foreign agent receives the session keys via the AAA protocol
When MN moves to a new FA, the new FA must retrieve the MN-FA and FA-HA
session keys

An assumption has been made that the FA could get the keys from the AAAF.
If the AAAF does not have the session keys locally, the request must be sent
to the AAAH to retrieve new session keys
This adds considerable delay in the hand-off process

Proposal
When new session keys are distributed by the AAAH, the FA encrypts the
MN-FA and FA-HA session keys, and adds them to the RRP
MN includes them in the RRQ at the new FA

The new FA decrypts the session keys and no contact with AAA
infrastructure is necessary

Two new extensions to send the session keys
MN-FA, FA-HA session keys

previous FA NAI sent in an extension, could be used with the SPI
to decrypt the key

Proposal currently assumes that the FAs in an admin domain share a group key
Encrypt/decrypt will be done using hte group key
Since all FAs are trusted, maybe this is ok.  However, management and
key update is an issue

Message size
Increased but only when new keys get generated

Q: (Raj): if all FAs are in the same domain?
A: we could query the previous FA, but it's simpler to use a blob that
   is passed to the new FA
Q: Charles: state of route optimization draft is not clear, but it may come
   back to life.  Wouldn't it be better to retrieve the key from the old FA
   over the wired network using the same SA?
A: do we have a chicken and egg problem?  Before we send the binding update,
   we need to authenticate?
Charlie: no, the binding update includes the authentication
Pat: ok, maybe this isn't necessary

Q: To clarify: when the MN moves to a new FA, instead of sending previous
   FA NAI, just use previous FA notification message from binding update
draft
A: Charlie: correct, but we don't need the NAI.  You could use it if you
   wanted to.

Q: (Milo): Two kinds of models, terminal centric, network-centric model.
   Maybe as we roam, I identify myself to the new FA, on behalf of MN I
   establish connectivity to a new HA
A: Charlie: no need to go to the extreme of eliminating all information
   from MIP RRQ
Milo: we still have registration between FA and HA, but not necessarily
      triggered by MN, just the announcement of the MNs identity.  All
      information is retrieved from previous FA.
A: Charlie: not related to current presentation.  This is purely a device
   for passing around keys.

Q: Pat: can we process RRQ and Binding Update simultaneously?
A: Charlie: they happen in parallel
Q: what would happen if MN-FA was invalid, but MN-HA is valid?

Next version of draft will be issued that provides similar functionality
when PKI is used instead of a KDC

////////////////////////////////////////////////////////

6. Buffer Management for MIP (Haseeb Akhtar)
(draft-mkhalil-mobileip-buffer-00.txt)

In addition to the layer-2 mechanism, we are trying to propose something
on layer 3
Problem: packet loss during handoff
MN moves to a new FA, HA creates a new tunnel between HA-NFA, packets in
transit to the previous FA are lost

Q: Dave Johnson: what about packets that were already sprayed into the air
A: old FA is constantly buffering, even packets that were sent on the air

Solution: buffer and forward data
Minimize the window of data loss: previous FA buffers packets and forwards
to the MN
Results in fewer retransmissions for upper layer protocols

3 scenarios are in the draft, we will cover 2.

1. Mobile Assisted handoff
      MN realizes it is about to make a change
      Sends Buffer Control Request to previous FA
      Then sends RRQ to new FA
      RRP is received, then another Buffer Control Request is sent to the
        previous FA.  This tells it to start forwarding packets

2.  PFANEH handoff
    MN does not know when its doing a handoff
    During the first RRQ, it tells the PFA to allocate a buffer and start
      buffering packets
    When we move to a new FA, we register there and then send the Binding
      Update to the PFA
    We start getting forwarded traffic, possible before the RRP from the
      new FA comes back
    The binding update contains ID numbers that tell which packets need to
      be forwarded

New Messages
Buffer Control Request - Mandatory for MN and FA
Can be sent as an independent message or as an extension to Registration
  Request and Binding Update messages
Buffer Control Response
  Optional for MN and FA

Q: Dave Johnson: I don't think you can convince everyone to allocate large
   buffers in FAs
A: Maybe, but its a tradeoff
A: we need a buffer of 2 or 3 packets
Dave: we need one window size for each TCP connection.  That's more than 2
or 3

/////////////////////////////////////////////////////

7. Dynamic IP Address Allocation in Mobile IP (Tomas Bostrom)

Current assumptions
Mobile IP: transparent availability based on permanent IP address
Permanent home address allocation

Network Access Identifier
Identifies users
assists routing authentication requests
users can roam between admin domains

Why do we need dynamic address allocation?
Address = location
Name = identity
Hosts should be identified based on names, not IP addresses
Modern technology promotes nomadic computing (home network wherever you go)
=> concepts of home and foreign have become obsolete
     no need for a permanently allocated address

Dynamic Address Allocation Scope
  Home address acquired dynamically on a temporary basis
  Local connectivity
  Roaming between different domains shall be possible
  Both in public and corporate networks
  Support cross-domain allocation
  "Home" and care-of address could be allocated from different admin domains

Solution
  DHCP-like mechanism should manage temporary IP address allocation
  Dynamic address associated with NAI using DNS-like mechanism
  Temp  home address should be kept by the MN as long as it is connected
  to the same admin domain

Evaluation results
  Temp home address allocation roday is possible within one admin domain
    using available DHCP options
  Address retrieval is approx 100ms in WLAN environment
  DHCP limitations:
    No security provided
    Puts a limitation on usefulness with AAA infrastructure
    No support for cross-domain allocation

Q: 100 ms is too slow
A: within a domain only

What should we do?
  Recent IETF drafts
     AAA Requrements
     DRCP (dynamic registration and configuration protocol)
     NAI draft

There is a need for dynamic address assignment, we should incorporate
in design of MIP

Q: Gopal: NAI draft + RFC 2002 can do this
A: Would like to extend this idea

Q: Mobile IPv6 solves this problem
A: this is IPv4 base

Q: Milo: you have solved just half a problem, MN is just a client.
   If I want to refer to the MN, I need dynamic DNS.  It is simpler to just
   go to a static HA than try to solve these problems.
A: MN should keep its temp IP address as long as it is connected to the
   same admin domain.
Q: Dave: do you lose that address when you move outside the domain?
A: yes
Q: this breaks TCP connections and the charter of this WG
Q: Gopal: what is the problem you are trying to solve?   If you want to do
   only IP allocation we already do it

Raj: we need to move on

/////////////////////////////////////////////////

8. Modifications to "Mobile IP Regional Tunnel Management" from a cellular
perspective (John Wang)
(draft-ietf-mobileip-reg-tunnel-01.txt)

Purpose:
    Propose modifications that could be combined with MIP RT Management
    draft for issues in next generation cellular telephony networks

Special concerns:
   limitations on OTA capacity, computing power, power supply
   Real-time applications, high mobility
   mass market, global coverage with global roaming  (different from
   just local coverage)

Issues
   Tromboning in data routing
       Triangle routing through HA
       Should have distributed FA database
   Peer-to-peer rather than master-slave
       over-the-air capacity, computing power, power supply demanding
       (should put more demanding aspects into the network)
       should be able to fool-proof MIP

Q: (Dave Johnson) is tromboning same as triangle routing?
A: yes.

Why is tromboning a great concern?
Cost & quality of service

Proposed solution
  Layered HA+FA structure
  Regional routing and updating
Improvements
  No trombining
  Homogeneous system architecture
  Minimum MN involvement
Environment
  RAN independent  (TDMA, CDMA, bluetooth)
  Multi-mode MN handset
  Multi-layer overlapped coverage
  Some areas of heterogeneous RAN systems
Advantages
  Global coverage
  Integrated service
  Efficient solution

Route optim based on HA-FA technology
Sometimes we don't need to go back to HA

Don't distinguish between home domain and foreign domain
Take optimal path for both signaling and data

Q: Dave Johnson: who provides services of higher layers of the hierarchy?
A: cellular service providers could have total or shared ownership
Q: Are you proposing a global infrastructure separate from the Internet?
A: no limitations.  Could be part of intranet, depending on business model

Well Recognized Technology
  UMTS applications
     performance evaluation and architecture optimization
     DDB architecture
  Lucent ATM distributed load-balancing technology very similar

Open issues
  Call routing regional tunnel management, route optimization
  Addressing & routes

Q: Are you proposing new inter- or intra-system network?
A: there is no requirement.  Could be either.  For performance it should
   be intra-system
Q: So this is baseline for UMTS or cdma2000 architecture?
A: Cellular carriers in 3GPP and UMTS require this
Q: 3GPP already has some internal protocol

/////////////////////////////////////////////////////

Pat gets up one more time to announce the Connectathon for
Mobile IP v4, v6, and DIAMETER
March 6-9 San Jose, CA
7 or 8 implementations should show up
Dave Johnson should be there to deal with spec issues if any

Dave mentioned Mobicom 2000 one more time

Raj: Thanks.  Moving forward:
Mobile IPv6 needs submission
AAA Requirements : discuss & arrive at consensus
Mobile IP Extensions Rationalization: discuss on mailing list
Key exchange solutions: review and go to WG last call
Route Optimization: how do we proceed?

---

From: Charles Perkins <[email-masked]>
Date: Tue, 23 Nov 1999 10:34:43 -0800

Hello Raj,

Here are a few corrections for the minutes.  BTW -- great job, Pete!

> Some places in original draft said be careful about using

This refers to discussion about how to handle ARP for the mobile
node and the foreign agent.  From a note I posted after the meeting
to the mailing list:

> - Specification that, while they are away from the home network,
>   mobile nodes MUST NOT broadcast ARP packets to find
>   the MAC address of another Internet node.  Thus, the
>   (possibly empty) list of Router Addresses from the ICMP Router
>   Advertisement portion of the message is not useful for selecting
>   a default router, unless the mobile node has some means not involving
>   broadcast ARP and not specified within this document for obtaining
>   the MAC address of one of the routers in the list.  Similarly,
>   in the absence of unspecified mechanisms for obtaining
>   MAC addresses on foreign networks, the mobile node MUST ignore
>   redirects to other routers on foreign networks.
>
> - Specification that a foreign agent MUST NOT use broadcast ARP for
>   a mobile node's MAC address on a foreign network.  It may obtain
>   the MAC address by copying the information from an Agent Solicitation
>   or a Registration Request transmitted from a mobile node.
>
> - Specification that a foreign agent's ARP cache for the mobile node's
>   IP address MUST NOT be allowed to expire before the mobile node's
>   visitor list entry expires, unless the foreign agent has some way
>   other than broadcast ARP to refresh its MAC address associated to
>   the mobile node's IP address.

Probably the minutes do not have to reflect this whole discussion,
which could be summarized by saying that RFC2002bis places significant
new restrictions on the use of ARP.

The discussion about the 7-second timeout for pending registrations
seems
to have been very unclear.  What I meant to say is that RFC2002 offers
7 seconds as a typical value for this timeout.  Particular
implementations
can still pick whatever value they like.  Other discussion at the
meeting
suggested the specification of a minimum value, and changing the
suggested
maximum from 7 seconds to something more.

Regards,
Charlie P.

PS. I'm open to suggestion.  7 was just a nice-looking odd number that
    seemed to fit the needs at the time -- I don't even think it was me
that
    originally suggested it.  Replacement text will be appreciated.