Subject: Re: [MOBILE-IP] More comments on draft-ietf-mobileip-3gwireless -ext-02.txt

From: Yingchun Xu <[email-masked]>
Date: Wed, 16 Feb 2000 04:51:44 -0600

Pat,
I agree with you that we need to make it clear that both PCF IP address and
session key field are necessary to mux/demux a GRE tunneled data. But we did
have sentences stating that each RP tunnel session is uniquely identified by PCF
IP address and session key combination.

By the way, why do you think that using source IP address will impose large
overhead since the source IP address is already there in outer IP packet header.
Do you have anyway to eliminate the source IP address?

--Yingchun.

"pcalhoun/@eng.sun.com" <pcalhoun on 02/14/2000 04:18:47 PM

Please respond to "[email-masked]" <[email-masked]>

Sent by:  "[email-masked]" <pcalhoun

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  [MOBILE-IP] More comments on
      draft-ietf-mobileip-3gwireless-ext-02.txt

All,

As I near implementation of this draft, I still have many concerns that I need
to bring up:

1. GRE Key (or session id) generation. The spec requires that the PCF/RAN (or
initiator of the reg request) creates the pseudo unique GRE id. Since a PDSN
(or termination point of the reg request) will be communicating with many
PCFs, the GRE identifier is hardly unique. Since the GRE id is not unique, the
PDSN cannot use this value alone to identify a data stream from the PCF. So,
we have a couple of options:

        a) Document that tunnel identification is done by using the GRE id AND
           the source IP address of the reg request. Of course, this imposes a
           rather large per packet overhead.
        b) Change the specification to mimick the VTP approach where the tunnel
           initiator sets the most significant 16 bits, and the PDSN sets the
           least significant 16 bits. The 16 bits set MUST be locally unique.
           This scheme works as long as no more than 65535 sessions are needed
           per pair (for lookups, the full 32bits are used).

2. The somewhat complicated requirement that both the FA and rpd (that handles
the protocol defined in this draft) listen on port 434. Some suggestions have
been make that processes only need to listen on certain interfaces, etc. I have
thought more about this, and I REALLY don't like this approach. Since the ONLY
thing that both Mobile-IP and R-P share in common is the packet format (and
the extensions used are different), they are different protocols. Why can we
not simply require that R-P be used over a different port? This is a VERY
simply problem to the solution, and no longer assumes ANY architectural
requirements.

Comments?

PatC

---

From: Sandy Thuel <[email-masked]>
Date: Tue, 22 Feb 2000 10:39:26 -0500

Hi,

Does anyone have measurements on the latency
for completing a Mobile IP registration on
a Home Agent implemented on a Cisco router?

Thanks,
Sandy