Hi Karim,
few comments:
- From Section 3.3,
"
... The Proxy
Router Advertisement Solicitation unicast to oFA is an agent
solicitation with a special extension. The solicitation MUST have an
extension containing an IP address identifier because the MN is
soliciting another specific FA's advertisement from the oFA. This
specific FA will be the MN's nFA. The IP address identifier contains
the IP address of the nFA or an identifier that can be used by the
oFA to resolve to nFA's IP address. If the identifier is not an IP
address, it MAY be specific to the underlying wireless technology,
for example, an Access Point or Base Station ID."
>From this, IP address identifier is required (MUST) in PrRtSol, but MAY
instead contain an AP of BSS ID? Doesn't that require you to implement
the IP address identifier? Even otherwise, I just cannot understand the
entire LLH protocol working without L3 information. For instance, how
do L2-ST, L2-TT work, how does post-reg work? They require the triggers
to contain the L3 information.
- Naming of messages: they come from FMIPv6, no changes. Not from LLH.
- Anticipated HA/GFA registration: We did not "eliminate" that option. We do
not believe in tying the two together. Implementations are free to use the
two together if they both exist. Efficiency of those two working together,
if needed, can be achieved by means outside the specification of FMIP.
This also brings another important difference we have listed. (An earlier
e-mail from Charlie included the other major differences). Our design is
minimalistic in the sense that it requires no changes to MIPv4 processing,
default router processing, RegReg processing etc. All those things can
take place as they normally do, but we disengage them from the critical path
for real-time traffic. In other words, we set up routing to support on-going
traffic, while other protocol processing can take its time.
An example where tying protocols together leads to unpredictable behavior is
changing the default router when Registration Reply is received even if the
MN is still on the old link due to whatever radio conditions. How can the
MN send packets ? Don't you end up changing the behavior here?
- L3-handover-before-L2-handover: There are important differences between FMIP
and LLH. At the time of an impending L2 handover, FMIP uses a single message,
FBU, LLH needs at least 3. (If you use post-reg, there are no messages, but the
L2 triggers must support L3 information). FMIP has the concept of neighborhood
discovery, in which a MN resolves its neighborhood L2 devices to their L3
parameters in a link-independent way, which is decoupled from the handover timing.
LLH does not decouple Proxy messages from Registration messages (presumably
because it does not define such a concept). Granted the FMIPv4 design is adapted
from FMIPv6, but these are imprtant differences wrt LLH. And, since the design of
FMIPv6 and FMIPv4 is identical, it is very easy to implement the two together.
This was enumerated as one of the differences in our original e-mail.
- L3-handover-after-L2-handover: LLH has no such design, and hence the reference
to PFANE. As said earlier (and below), the difference between PFANE and FMIPv4 is
that FBU is sent as soon as the new link is available without having to perform
agent discovery. This comes from doing neighborhood discovery before leaving the
old link.
An important design aspect of decoupling neighborhood discovery and handover
signaling is that it allows you to initiate FBU either from the old link or
from the new link without having to do movement detection and agent discovery
on the new link. And, FMIP does this without changing the MIP and default router
behaviors.
- Performance: In Charlie'e presentation, you can see we get about 80 ms
for FMIPv4 handover on a Prism2 chipset. The IP overhead during
handover is time for FBU message, which is 2-3 ms over WLAN. The performance
of FMIPv6 is similar. With improvements in L2 delay, the entire handover delay
can be better.
I have not seen evaluations of pre-reg LLH performance other than from
James Kempf, which seems to conclude that it is not suitable for deploying
for certain link technologies. Perhaps it can be made to work.. Post-reg, on
the other hand, requires L3 information from triggers.
So, my summary is that there are important differences. Perhaps LLH is suitable for
certain environments, and likewise for FMIPv4. One particular environment
we are interested in is deploying FMIPv6 and FMIPv4 together.
That's all for me :-)
-Rajeev
Karim El-Malki (AL/EAB) wrote:
I understand your point that you took FMIPv6 and applied
it to v4 to make FMIPv4. But that doesn't make it
substantially different from Low Latency. Your spec does
use link-layer triggers to be able to send the RtSolPr.
An interface coming up in the MN is used just the same in
Low Latency and is defined as a mobile trigger in Low
Latency (L2-LU). PRE-REG involves the MN getting such a
mobile trigger and sending a PrRtSol and receiving a
PrRtAdv. What's the difference compared to your spec?
As I explained below (and also itemized in the List below), the
essential
difference is that LLH requires L2 to provide L3 information (nFA, MN
IP addresses, their MAC addresses etc.) via various L2-*T type of
triggers.
This is a Big difference for us since we do not wish to change L2 to
implement fast handovers. Both FMIPv6 and FMIPv4 work without
requiring such changes to L2.
That's not correct.
Let's take the case where the L3 handoff is initiated before
L2 handoff. Taking WLAN for example, in LLH the MN gets info
from L2 (e.g. AP scan) and sends a PrRtSol to get a PrRtAdv
containing information of the subnet it may move to. I can't
see any change required to L2. Where is the difference compared
to what you have described? The only difference is that we
definied all "handoff hints" as L2 triggers, just as a result
of the AP scan is defined as a mobile trigger. The LLH spec doesn't
mandate the presence of all trigger types in all cases. It
depends on what the L2 has to offer.
The messages are even called the same. Nothing special
or L2-dependent about this L2 trigger. For example PRE-REG
Well, the essential difference is what requirements LLH imposes on L2
triggers. Table 1 in LLH specifies what information is expected from
L2 triggers including the nFA, MN IP addresses from the various L2-*T
triggers.
LLH can work with different types of L2 triggers (which is very
different from requiring L2 changes) and supports the case you
have described in FMIPv4. Table 1 specifies the different types
of triggers that LLH can utilise. Note that it includes very
simple triggers that work even on WLAN. It is wrong to say
that all triggers in Table 1 are required on all L2s for LLH
to work.
can be applied to WLAN using AP scans. I don't think that
the difference in packet formats makes it a substantially
different spec from low latency. Also, the other case you
are considering involves an L3 handoff that happens after
the MN attaches to the new link. This cannot really be
considered a "fast" handoff, which would instead be where
the handoff happens before or in parallel with the L2 handoff.
Perhaps you have missed something.. The FMIP design allows movement
detection and router/FA discovery phases to be done prior to L2
handover. The
"reactive" handover we refer to is the one where the FBU is sent from
the
new link. But, the MN uses the neighborhood information via Proxy Router
messages to determine movement detection and router/FA config
information of the
new subnet. So, your description above is not accurate.
Note that I first addressed the L3-movement-before-L2 (where I
am saying that FMIPv4 is no different from LLH) and then
I wrote "the other case you are considering....".
Am I incorrect in saying that FMIPv4 also supports the
L3-handoff-after-L2-handoff case? I think I had read that
case in FMIPv4 (i.e. FBU sent from new link).
That's why I had asked about PFANE.
This L3-handoff-after-L2-handoff was already covered in the
route optv4 spec using PFANE. You may have missed the question
so I'll repeat it: did you consider the PFANE? Why aren't
you just reusing the PFANE (Previous FA Notification
Extension) work for that scenario?
Please see above. The key difference with respect to Previous FA (what
used to be Previous AR
notification in v6) Notification is that you don't incur delays due to
movement detection and
router/FA discovery.
If you are only considering the L3-handoff-before-L2-handoff case
then there are very little differences between FMIPv4 and LLH for
the reasons given above.
So, apart from the independence from L2 to provide L3 information, the
other
crucial difference is the decoupling of neighborhood discovery from the
actual
handover signaling. This not only reduces the number of signaling
messages
during the handover itself, but also makes the reactive fast handovers
possible.
Again I can't see the crucial difference from LLH.
The ND messages are basically the same (even almost called the same):
PrRtSol and PrRtAdv. LLH uses standard MIPv4 naming (Registration
Request and Reply) while FMIPv4 achieves the same result but calls
this an FBU. Tunnelling between FAs is supported in both specs.
LLH furthermore supports anticipated HA updating or "local" HA
updating (regional registrations). It seems to me that to make
things "faster" one would want to update the local/global HA directly
if possible since FA-FA routing can be inefficient in a tree-like
network structure compared to updating a local HA. I am curious to
understand why you have eliminated that option in FMIPv4 compared
to LLH. Measurements performed on FMIPv6+HMIPv6 integration
prove that it makes sense to combine local/global HA updating with
the FMIP mechanism.
/Karim
|
