Subject: RE: [mobile-ip] Mobile Prefix Advertisements ... additional thoug ht

From: "Powell, Ken" <[email-masked]>
Date: Wed, 27 Jun 2001 13:35:57 -0400

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 6:59 PM
> To: Powell, Ken
> Cc: [email-masked]; 'T.J. Kniveton'
> Subject: Re: [mobile-ip] Mobile Prefix Advertisements ... additional
> thought
> 
> 
> 
> Hello Ken,
> 
> I didn't see any other discussion about this on the mailing
> list, so I didn't make the corresponding change to the
> document.  However, I think that one can go even farther.
> - The Binding Acknowledgement could be a destination
>    option in the Mobile Prefix Advertisement (MPA).

Yes.
It makes sense for this to be a SHOULD type
requirement to save on bandwidth. However, I
think for code complexity reasons, I would
prefer not to mandate this. This may be
a difficult thing to implement on home agents
where the Mobile Prefix Advertisement logic
is in a user space daemon and the Binding Update
logic is in kernel space.

> If the mobile node does NOT get the MPA, then it
> would retransmit the Binding Update since the Binding
> Acknowledgement was never received.
> 
> In the case, if the mobile node only had one home address
> and it was getting renumbered to have a new prefix, then
> the home agent does NOT need to get
> a Binding Update, since it can assume that either:
> - the mobile node will receive the Binding Acknowledgement
> - the mobile node will retransmit the Binding Update.
> 
> So, a typical exchange could be exactly two messages.

Sounds like a great thing to allow as an option for
home agents to implement.

> 
> What do you think about that?  Of course, if there are
> lots of prefixes and lots of home addresses involved, the
> same logic does not necessarily hold.  But perhaps we
> ought to make the simple cases really simple.  Maybe
> there should be another bit in the MPA to say whether
> the Binding Update is requested or not.

I thought that is what the Binding Request destination
option was being sent for (section 9.8.3). Do we need
a bit in addition to that?

If the mobile prefix ack proposal is accepted, then
I could see adding a bit to the mobile prefix
advertisement to say whether the mobile prefix ack
is requested.

> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> "Powell, Ken" wrote:
> 
> > I've been wondering about the coupling between mobile
> > prefix solicitation/advertisement and binding request/
> > update/ack.
> >
> > Specifically:
> >  - Section 9.8.2 describes how a binding update could
> >    trigger a mobile prefix advertisement
> >  - Section 9.8.3 describes how a binding request/update is
> >    used to acknowledge the mobile prefix advertisement
> >
> > This leads me to consider the following exchange:
> >
> >    mobile node <--> home agent
> >    ===========================
> >    --> binding update w/ ack bit set
> >        (destination option processing on home agent handles
> >         processes binding update and sends binding ack,
> >         then signals ICMP mobile prefix handler to check
> >         for pending advertisements)
> >    <-- binding ack
> >    <-- mobile prefix advertisement w/ binding request
> >    --> binding update w/ ack bit set
> >    <-- binding ack
> >
> >    It seems we could simplify the exchange rules by
> >    adding an ICMP mobile prefix ack message that could be
> >    used to replace the final binding request/update/ack
> >    exchange.
> >
> >    --> binding update w/ ack bit set
> >    <-- binding ack
> >    <-- mobile prefix advertisement
> >    --> mobile prefix ack
> >
> > Ken
>