Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

From: "Tom K. Weckström" <[email-masked]>
Date: Thu, 2 Nov 2000 09:02:45 +0200

Hello Charlie.

"Charles E. Perkins" wrote:
>
> I have studied your examples, and I have two overall
> comments.
>
> It seems to me that using the Previous Foreign Agent
> Notification (PFAN) extension (from the Route Optimization
> draft) solves the problems that you posed.  This message
> forces an acknowledgement from the previous foreign agent
> after it receives the Binding Update.  Thus, the mobile
> node has a way to know its registration status at previous
> foreign agents.  All along, we tried to make the regional
> registration draft coexist well with the Binding Update
> mechanism specified in the Route Optimization draft, while
> still remaining sufficiently independent so that the
> regional registration draft could be considered separately.
>
> Do you agree that this is a good solution?

I understand. Syncing with other drafts makes sense.
However, can you refer to a draft from an RFC? I mean, what if the
current Route optim. I-D is not accepted as is? This means you might
need to change your RFC also...

Let me tell you how I understood the scheme. Correct my
misunderstandings. I did not have time to read the Route optim. I-D
through.

This describes FA4-->FA3 handoff in the picture below. MN is changing
its FA. Regional registration request has been sent. The request
arrives to the new FA, FA3. It does not know the MN so it forwards the
request upwards in the hierarchy. The next FA, FA1, knows the MN and
has a binding for it. The old care of address (previous FA IP, FA4's
IP) is in that binding. FA1 processing the request sends a
registration reply to MN. FA1 also sends the PFAN extension in some
rot of a message (authentication???) to the previous FA, FA4. The
previous FA sets the MN's new COA to its binding cache for a while.
The previous FA sends an acknowledgement to MN about having received
the PFAN. MN knows now that
A) the registration to FA3 was successful (because of the reg.reply)
B) the previous FA, FA4, has been informed.

Now, consider a deeper hierarchy example. MN changes from FA6 to FA4
in the picture below. Registration rewuest goes to GFA. GFA knows MN.
GFA sends reg.reply. GFA sends PFAN. To which FA does the GFA send
that PFAN? To FA2? To FA6? The PFAN must go through FA2 also. Does GFA
need to have both the FA2 and the FA6 addresses in its binding?
Meaning, GFA would know the entire path from GFA to MN. How can a FA
know, whether it should process the request or not? I mean, having a
binding for the MN ("knowing" the MN) is not enough, because a FA can
not trust the unreliable network. So, we agree that FA needs to get
info about the prefious FA. But do the FAs also need information about
the hierarchy? I.e., does each FA have to know, which FAs are under
it? I would say yes. Then the PFAN or "previous FA NAI" approaches
will work.

I haven't modeled all the scenarios, but if a FA does not know what
FAs are under it in the hierarchy, it can not be sure whether it
should process the request or consider its own binding an obsolete
"relic" because of a lost PFAN message that was previously send to it.

The knowledge about FAs under each FA should be complete. I.e., it is
not enough for a FA to only know the path to the MN through the FAs
under the FA. This is because of a possibility of lost protocol
messages in the hierarchy.

Of course, one can always say that the protocol recovers from this
kind of situations with timeouts (reg.reply timeout in MN and binding
timeout in FAs) but that would not support efficient, fast roaming in
a network with slight probability of lost packets...

What do you think?
Should the FAs know about all the FAs under them?

> I am very tempted to agree with you about the need to
> insure that regional registration messages work with multilevel
> hierarchies.  And, in fact, I think that the messages in the
> current draft do work in multilevel hierarchies.  We all
> thought about this problem of multi-level hierarchies many
> times, and that was a partial motivation for using different
> message types.  However, if you see any particular place where
> there is any existing problem in the protocol, where the
> regional messages would not work for the multi-level hierarchy,
> please let us know.

The only thing I am little bit unsure of, is the knowledge about other
FAs below each FA as I explained above. I am quite sure there will be
problems because of lost messages, if each FA does not know the FAs
underneath.

> For convenience, I have reproduced your example hierarchy
> and mobility patterns below.  I think that, given PFAN,
> the existing draft solves your concerns, but again if I am
> wrong I hope you will help us find out what is still wrong.

If you also considered cases of lost messages, please let me know and
tell me how the "PFAN only" approach with FAs not knowing the FAs
underneath solved those cases.

Best regards,
                Tom

> > Again, I use the example hierarchy:
> >
> >                                  ------
> >                                  | HA |
> >                                  ------
> >                                    |
> >                                (Internet)
> >                                    |
> >                                 -------
> >                                 | GFA |
> >                                 -------
> >                               /         \
> >                       -------             -------
> >                       | FA1 |             | FA2 |
> >                       -------             -------
> >                        /   \               /   \
> >                  -------   -------   -------   -------
> >                  | FA3 |   | FA4 |   | FA5 |   | FA6 |
> >                  -------   -------   -------   -------
> >                                   \
> >                                    \
> >                                  ------
> >                                  | MN |
> >                                  ------
> >
> > In the initial situation in the figure, IFA (FA1) is the intermediate
> > FA on a path from HA to MN, GFA has its own special name and role, and
> > LFA (FA4) is the lowest FA on a path from HA to MN. MN has registered
> > with a home registration and has received a reply through FA4 (LFA).
> >
> > Now, consider a situation, in which MN changes its lowest FA (the FA
> > to which it sends its registrations) in the following order:
> > -- FA4, FA3, FA6, FA5, FA4,...
> >
> > Now, what entities send the regional registration reply to MN?
> > In the corresponding order:
> > -- FA1, FA1, GFA, FA2, GFA,...
> >
> > Now, also FA1 and FA2, and even GFA may send agent advertisements.
> > MN could also roam vertically and register like this:
> > -- FA4, FA1, FA2, FA3, FA2, FA6, FA1
> >
> > And the FA sending the registration reply would be:
> > -- FA1, FA1, GFA, GFA, GFA, FA2, GFA

--
        Tom Weckström           [email-masked]
        Korppaanmäentie 16 B 14 Helsinki University of Technology
        00300 Helsinki          Department of Computer Science
        040-5642709             http://www.niksula.cs.hut.fi/~tweckstr