Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-04.txt

From: [email-masked]
Date: Fri, 18 Aug 2000 17:28:42 -0500

Charles,
I wish we could have received your comments ealier. The proposed Mobile IP
extension has been implemented in cdma2000 standard and it is very hard to
change. I agreed with Pete that we should stick to the current format.

The points you have made in your email are mostly not hold because of your
misunderstanding of the draft (see Pete's response below). The method proposed
in the draft is mainly used for the mobility management between RNN and PDSN and
it is transparent to the upper layer Mobile IP.

As the matter of fact, the proposed method was approved by 3GPP2 and it
represents 3GPP2.

---Yingchun.

Pete McCann <[email-masked]> on 08/18/2000 04:28:51 PM

Sent by:  Pete McCann <[email-masked]>

To:   "Charles E. Perkins" <[email-masked]>
cc:   See Below
Subject:  draft-ietf-mobileip-3gwireless-ext-04.txt

Charles,

I was quite disheartened to see your message below.  While the
comments come rather late in the process, they also reflect a pretty
serious misunderstanding of both the intent and some of the technical
details of the draft.  While you raise some points that are valid, I
think you have missed the role this draft is intending to play in the
network and its potential interactions with other emerging Mobile IP
standards.  Let me try to address your concerns one at a time.

"Charles E. Perkins" <[email-masked]> (CEP) writes:

CEP> Hello draft co-authors,

CEP> From the discussion below, and after a careful re-reading of the draft,
CEP> I hope to show that this protocol specification does not at all fit
CEP> well within the mainstream of work within the mobile-ip working group.
CEP> I believe that it is actively harmful, because any core network
CEP> implementing their protocol would find it correspondingly much more
CEP> difficult to implement "actual" Mobile IP specifications.  I say
CEP> "actual" in quotes because the specifications in question are not
CEP> yet Proposed Standard, and also because I do not think that the
CEP> 3gwireless specification fits well in its current formulation nor
CEP> has it received sufficient working-group review.

Implementations of 3gwireless should have no trouble co-existing with
any current or proposed Mobile IP extensions.  I hope the further
discussion below will clarify this.

CEP> The first basic problem with the 3G wireless draft is the specification
CEP> of the Registration Update and the Registration Acknowledgement
CEP> message types.  Neither of them is clearly specified, and to the
CEP> extent that I understand their purpose, neither one is necessary.
CEP> The intended results of those messages are done better by use of
CEP> the Binding Update and Binding Acknowledgement messages which are
CEP> already specified in the Route Optimization draft.

Whether to use the Binding Update messages was discussed several
times, and a number of us went back and forth on this issue.  If this
were your only problem with the draft, I'm sure it could be changed to
use Binding Updates, as long as they carry the Session-Specific
Extension.  However, this would disrupt some ongoing implementation
efforts and I do not see that the change is really warranted.

CEP> The respecification of the Registration Request draft is also
CEP> faulty, and exhibits the well-known fallacy of doing the same
CEP> thing in two different ways.  In this particular instance, we
CEP> see that the alt-Registration Request message has failed to keep
CEP> up with recent developments regarding the 'V' bit.  We can expect
CEP> this to continue, especially given the strong likelihood that
CEP> some new Mobile IP developments will involve interactions between
CEP> the Registration Request message and AAA services.

The draft was not intended as a re-specification of the Mobile IP
Registration Request message.  It was designed to be used intact
from RFC 2002, and I believe the format was only included here for
reference.  I'm sure Yingchun would be happy to remove the 'V' bit
so as to conform with 2002-bis, but this is a really minor point.
The basic Registration Request message format should eventually
stabilize in an RFC (we were working with 2002 at the time) and
any changes will then be accommodated with the Mobile IP extension
mechanism.  Do you foresee any other changes to the Registration
Request message?

CEP> Figuring out when to send an alt-Registration Request will be
CEP> additionally complicated by the standardization of the upcoming
CEP> Regional Registration protocol specification, which is currently
CEP> in Last Call.

This is the point at which I think you have misunderstood the purpose
of the draft.  The 3gwireless protocol is designed to be used between
an RNN and a PDSN, for establishing a tunnel over which the MN's data
will be sent.  It is established in response to a link-layer
connection event and NOT in response to any IP-layer message sent by
the MN.  This is very important, because it was decided a long time
ago in 3GPP2 that we cannot afford to bring up a traffic channel for
sending IP packets every time the MN changes its RNN - that should be
done only when changing PDSNs.  This has the effect of making the PDSN
the first-hop IP point of attachment: the whole R-P interface is just
one logical link according to the IP stack on the MN.

This degree of transparency is important for two reasons: one, to
reduce the burden on the traffic channels, as above, but also two, to
provide some "limited mobility support" to MNs that do not even
possess Mobile IP client code.  For this very reason, the draft will
never interact with any new features proposed for Mobile IP - they are
always a matter of the MIP client interacting with its first-hop
router.

CEP> Another element of confusion is represented by the lack of
CEP> IP addressability for mobile nodes subordinate to the protocol
CEP> operations described in the 3gwireless draft.  In fact, nowhere
CEP> in the draft is there any indication that mobile nodes in their
CEP> system will have IP addresses.

The draft defines an interface between RNNs and PDSNs - that is all.
It does not specify what the MN is allowed to do once it is connected
to the PDSN; that is properly the subject of other work in the Mobile
IP WG.  Even though the draft does not standardize any aspect of MN
behavior, we felt it was important to specify this interface in the
IETF because the RNN and PDSN will share an IP network and the IETF is
the best possible place to get feedback, exposure, and consensus for
this interface.  This is a perfectly proper role for an Experimental
RFC to play.

CEP> Furthermore, mobile nodes in
CEP> this draft are basically identified by a MN ID field, which is
CEP> expected to be the same as the mobile node's IMSI.  Recent work
CEP> within the mobile-ip working group has gone in the direction of
CEP> using the NAI for analogous purposes of allowing a Registration
CEP> Request to emanate from a mobile node that does not yet have
CEP> a home address assigned.  I would suggest that the 3gwireless
CEP> draft use the NAI extension instead of their current MN ID.
CEP> The IMSI is widely expected to show up as data within NAI
CEP> extensions to Mobile IP registration requests, so this should
CEP> not cause any problems to the 3gwireless authors.

As I said, the R-P interface runs as a side-effect of link
establishment, before *any* IP packets are received from the MN.  As
such we do not know the NAI that the client may later use when sending
an actual Mobile IP Registration Request, but we do have a link-layer
identifier (which in our case has been properly authenticated by means
outside the scope of Mobile IP).  This identifier is included in an
extension to allow the PDSN to perform handoff without receiving any
IP packets from the MN.

CEP> As an example to support my contention that this draft is actively
CEP> harmful to current work items within the mobile-ip working group,
CEP> say that a PDSN implements Regional Registrations.  This is very
CEP> likely, given recent discussion.  How then would such a PDSN manage
CEP> its route tables if it ever received a message on port 697?
CEP> It might be very difficult to figure this out.  It would be
CEP> possible to get messages that required incompatible operations.

Not true.  Messages received on port 697 would only come from RNNs.
Other messages that may be defined in the future, such as regional
handoff messages, would come from MNs or from neighboring PDSNs (FAs).
Think of the R-P connection as a logical interface.

CEP> Similarly, if a mobile node implements smooth handover messages
CEP> using IPv4 Binding Updates, then there would be a conflict between
CEP> actions required by the Binding Update message and the port 697
CEP> messages.

Also not true.  A Binding Update from anywhere else in the network should
be treated by the PDSN in its normal role as Mobile IP Foreign Agent.
It would then redirect traffic to another PDSN and stop sending packets
down the R-P tunnel (assuming the BU was properly authenticated, of
course, the key distribution/PKI for which has not yet been solved).

CEP> I have numerous other syntactic and editorial comments that I
CEP> think would need attention before the draft should be considered
CEP> at all.  If need be, I will supply these additional comments.
CEP> However, before going to that trouble, I think that it is more
CEP> important to consider the viability of the draft.  I hope that the
CEP> authors of the draft will follow through on their previous agreement
CEP> to find a better integration strategy with other existing mobile-ip
CEP> working group drafts, specifically including Route Optimization and
CEP> Regional Registration.  If it is the contention of the 3gwireless
CEP> authors that the previous drafts are too complicated for their
CEP> implementation purposes, then we should have the discussion.
CEP> I have offered to do so, more than once.  One possible outcome
CEP> would be to get simpler drafts for specific protocol features
CEP> needed by the 3gwireless authors.

A "better integration strategy" than complete transparency to any
existing and future Mobile IP standards is not to be found.

At this late date I would prefer to stick with the messages as they
have been defined.  The draft has been available for comment for
quite some time.  However, I have no objection in principle to changing
from Registration Update to Binding Update and I certainly agree that
the "V" bit should be dropped.  If you have any other comments waiting
could you please share them soon?

CEP> I note that Nortel Networks had brought some similar concerns to
CEP> light a couple of years ago, and we reached a beneficial improvement
CEP> to the Route Optimization draft which allowed the inclusion of
CEP> multiple correspondent node addresses in the Binding Warning
CEP> message.  I fully expect that we can make similar improvements
CEP> as needed to the IPv4 Binding Update message for use in the
CEP> role needed by the authors of the 3gwireless draft.

That's fine but I do not think the IPv4 Route Optimization draft could
ever subsume the functionality described here.  This draft is needed
to define the Session-Specific Extension and to describe the behavior
of RNNs and PDSNs as they establish and tear-down R-P connections.

CEP> I also note that the name of the draft is misleading.  As far as
CEP> I know, there is no consensus behind this protocol specification
CEP> within 3GPP or within MWIF.  I also do not think there is any
CEP> consensus behind this protocol within 3GPP2, but I note that
CEP> several of the listed authors are indeed active within 3GPP2.
CEP> My guess is that this draft has limited support even there.  But
CEP> either way, it seems very clear to me that the draft should NOT
CEP> be named in any way to imply that it represents _the_ 3G solution
CEP> for wireless mobility management.  Far from it.

This draft has rock-solid support in 3GPP2.  It has been codified into
IOSv4 and is being implemented by several vendors.  MWIF, as far as I
know, is not a standards-setting body.  I agree that this draft has
come from the 3GPP2 community rather than 3GPP, but nothing in the
draft is specific to 3GPP2 or cdma2000.  The IMSI is an international
identifier recognized by both bodies.  3GPP has shown very limited
IETF participation so far, choosing to go its own way with GPRS.

Would you be satisfied if we changed the name to "in A 3rd Generation
Wireless Network?"

CEP> Lastly, I note that this draft has attracted almost no discussion
CEP> within the mobile-ip working group.  When I asked several others
CEP> about it, they said it was because most people generally don't care.
CEP> But I care.  I care because I think it is damaging to the progress of
CEP> other longstanding mobile-ip working group items.  In order to best
CEP> meet the needs of all parties, I offer my best effort to work with
CEP> the authors of the 3gwireless draft to make the other drafts meet
CEP> their needs.  I hope this will be sufficient to resolve what could
CEP> otherwise be a situation causing problems for the future.

None of the other drafts are capable of satisfying the transparency
requirements that are met by 3gwireless.  I think your impression of
"damage" is due to a misunderstanding of this draft's proposed role in
the network.  Nothing in the draft precludes Regional Registrations
from being deployed and used, but we need a solution that handles some
amount of mobility in a transparent manner that does not require
IP-layer messages from MNs, and in a timeframe that will meet the
deployment requirements of cdma2000 (next year).  The uncertainty
about the availability of MIPv4 clients, let alone even more elaborate
solutions like Regional Registrations, strongly argues that something
like 3gwireless is needed.  I don't see what harm is done by allowing
it to proceed to Experimental status, and I don't see why we need to
choose between this draft and the other drafts currently out there.

-Pete

CEP> Sincerely,
CEP> Charles E. Perkins

CEP> PS. I regret that I have only now been able to make time for this
CEP>     set of comments.  It would have been much better to raise the
CEP>     discussion during working-group last call, but that slipped
CEP>     right by me and was over before I knew it.

cc: Yingchun Xu/Mw/Us/3Com @3Com   Wenzel @Nortelnetworks.Com
    Rajesh_Bhalla @3Com.Com        Becker @Nortelnetworks.Com
    Karl_Freter @3Com.Com          Jjiang @Nortelnetworks.Com
    Ed Campbell/Mw/Us/3Com @3Com   Shikano471 @Oki.Co.Jp
    Mcgrath.Hadwen @Worldnet.Att.Net  Keg @Telecom.Samsung.Co.Kr
    Gopal Dommety <Gdommety @Cisco.Com>  Yong @Telecom.Samsung.Co.Kr
    Kjoshi @Cisco.Com              Bsemper @Telecom.Samsung.Com
    P.Yeqani @Ericsson.Com         Jmkoo @Sktelecom.Com
    Matumura @Mcs.Ts.Fujitsu.Co.Jp "Lipford, Mark" <Mlipfo01
@Sprintspectrum.Com>
    Atsushi_Teshima @Cm.Tcd.Hitachi.Co.Jp     Flerou01 @Sprintspectrum.Com
    Jihs @Hei.Co.Kr                Jgately @Uswest.Com
    Nao-Itoh @Ido.Co.Jp            Tom Hiller <Tom.Hiller @Lucent.Com>
    Ki-Ohki @Kdd.Co.Jp             Phil Roberts <Qa3445 @Email.Mot.Com>
    Bklim @Lgic.Co.Kr              "Basavaraj Patil
    Mccap @Lucent.Com              David Oran <Oran @Cisco.Com>
    Ttowle @Lucent.Com             Rob Coltun <Rcoltun @Redback.Com>
    Jayapal @Cig.Mot.Com