Subject: RE: F-HMIPv6 ( was Re: [mobile-ip] RE: Address config for FMIPv6)

From: Soliman Hesham <[email-masked]>
Date: Sun, 29 Jun 2003 21:18:57 -0400

Greg, 

 > >>I think that the tunnel extension (to the MN) for
 > >>F-HMIPv6 is a bit like co-located CoA in MIPv4:-
 > >>It's fine but why would you if you've got an FA?
 > > 
 > > 
 > > I'm sorry but I don't understand what you mean by this :-)
 > > Cold you clarify this ?
 > 
 > What I'm talking about is that there's no need for the
 > tunnel extension MAP<=>MN, if the nAR provides tunneling
 > and decapsulation support (allows MAP<=>nAR).
 > 
 > If the nAR provides this, then the it is almost always
 > better to use the decapsulaion support in nAR (especially
 > if the access network link has a low MTU).
 > 
 > The tunnel extension to MN is only really useful if the
 > tunnel may not be easily established.

=> The tradeoff here of course is between
implementing additional messages Vs tunnelling
over the air. But of course you're assuming that
the tunnels are actually sent over the air
(i.e. no header compression). If HC exists,
then it's a lot simpler to tunnel to the MN.

Hesham

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 Jun 2003 11:58:13 +1000

Hi Hesham,

> then it's a lot simpler to tunnel to the MN.

I agree that HC can help, but if there's an issue
with MTU, it is likely to show itself with the addition
of a single additional octet in the encapsulating header.
I don't see any benefit of running F-HMIPv6 tunnel extension
in this case, even with HC.

If there are no MTU troubles then this is a different
matter.  If this is (basically) guaranteed to be the case,
there's no need to complicate issues with oAR/nAR tunnels
(so long as the MAP can provide prediction).

Greg

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 Jun 2003 13:11:18 +1000

Hi Hesham et al,

Sorry about replying to myself,
but I was informed that the statements I've made
about F-HMIPv6 tunnel extension have a different
effect from that intended.

Firstly, I'd like to say that I'm interested
in BOTH of the methods, with MAP<=>MN and MAP<=>nAR.
tunnelling.   What I was trying (badly) to indicate
is the applicability of each system.

Here are two issues which may impact on the
validity of each mechanism in certain circumstances.

1) Availability of FMIPv6 ARs

On access networks without FMIPv6 Modified access
infrastructure, prediction may not be available from ARs.

In this case, the MN can use bidirectional tunnel
interface to MAP for SolRtrPr and PrRtrAdv.
Note that a MAP<=>MN tunnel must be available (to
keep the packet exchange to a single hop),
although it may not be in use for all traffic.

2) MTU on Access Links:

Addition of encapsulating IP header may have
ill-effects for user data, if MAP<=>MN tunnels are
used.

If MTU issues are likely, Header Compression on the
tunneled packets may be used (but may be ineffective).
If FMIPv6 ARs are available, then MAP<=>nAR tunnels
should be used.

The default case where FMIPv6 capable ARs are available
is to use MAP<=>nAR tunnels.  There is no major
advantage in not using the available features of the
visited network in this case.

Greg