|
Hi Srini,
As we all know, the main idea of FMIP is to configure the
nCoA MN over the old link before handover, so that the MN can use this new CoA
when it attaches to the new AR, which would reduce part of L3 latency. Yet
the MN still can't send FNA message to NAR until it establishes L3 connection.
Because IETF focuses on Layer 3, what it do can't beyond the scope of layer 3.
FMIP does help to reduce some L3 latency. But it doesn't exclude other
method to perform handover optimization.
If we think of carrying some IP layer information in L2
(L2.5) message, L3 mobility management procedure and L2 mobility management
procedure could be carried out concurrently, which would reduce total latency
obviously. Actually, in current 802.21, there are some MIH messages which
contain IP layer information.
B.R.
Yan
Hi Yan,
Please go through draft-ietf-mip4-fmipv4-06.txt or RFC 4068 on how the procedure
works. New CoA and New AR/FA info can be provided over the serving link
(old) in ProxyRtrAdv before L2 connection has to be established on new
link. If you want to do the same thing again in MIH, please explain
why.
Regards,
Srini
Hi Srini,
Usually, MN can't begin L3 mobility
management procedure until it attaches to the target
network.
So the total handover latency is
the sum of L2 latency and L3 latency, which can be described with the
following equation:
T = L2 latency + L3 latency
If L2 message is allowed to carry some
IP layer information, some L3 function (i.e. configuration,
conflict detection and tunnel management etc.) can be performed before
the completion of L2 handover, which would reduce the total handover
latency obviously. Ideally, it can be reduced to the bottom limit:
T = max {L2 latency, L3 latency}
I don't think it's
redundant, restrictive and conflicting IMHO. On the
contrary, it's a feasible way to perform cross-layer
optimization.
B.R.
Yan
Hi,Srini,
Yes,
current IP Fast handover procedures have own messages, they do
not work on any the link specific information which can be
useful in handovers. But since the IP Fast handover procedure
happened before MN attached target network, and IEEE 802.21
purpose is prepare for handover, why we cannot use the existing
MIH messages to carry some IP information such as IP address and
so on to finish configuration, conflict detection and tunnel
management in advance, thus it may reduce some signalings
spending(such as FBU, HI, HAck, FBack messages in FMIP
protocol), and accelerate handover completion? I just think
it maybe a feasible method.
Regards,
Jing
**********************************************************************
This
e-mail and its attachments contain confidential information
from
HUAWEI, which is intended only for the person or entity
whose address
is listed above. Any use of the information
contained herein in any way
(including, but not limited to,
total or partial disclosure,reproduction,
or dissemination)
by persons other than the intended recipient(s)
is
prohibited. If you receive this e-mail in error, please
notify the
sender by phone or email immediately and delete
it!
**********************************************************************
----- Original Message -----
Sent: Wednesday, May
09, 2007 12:27 AM
Subject: RE: [802.21]
MIH commands for handover
Hi Jing,
> Whereas, for fast handover
protocol,such as FMIP$B!"(BFast HMIP$B!"(BFast PMIP and so
on, it implements before MN attached target network, so we can
use MIH commands to finish the procedure of IP address
configuration$B!"(Bduplicate address detection and tunnel
building during handover preparation, thus it will reduce the
handover delay and enhance handover
efficiency.
While I do not understand the reasoning
behind this, I can say that the IP Fast handover procedures
are defined with exactly the same goals in mind - to reduce
the service disruption to under 150ms. The IETF WG have
carefully identified and worked with everything related to IP
layer and above - IP addresses, conflicts,
configuration, tunnel management and so on in the respective
protocols. But they do not work on any the link specific (L2)
information which can be useful in handovers. The best value
MIH can add is in this area. Anything more, specially IP
related information, would be redundant,
restrictive and conflicting at best,
IMHO.
Regards,
Srini
Hi
Michael,Srinivas,All
Of
cource, MIH User may be different mobility management
protocol.
For MIP protocol,such as
PMIP$B!"(BHMIP and NetLMM, it implements only after MN
attached the target network, so it is outside IEEE 802.21
standard.
Whereas, for fast handover
protocol,such as FMIP$B!"(BFast HMIP$B!"(BFast PMIP and so
on, it implements before MN attached target network, so we can
use MIH commands to finish the procedure of IP address
configuration$B!"(Bduplicate address detection and tunnel
building during handover preparation, thus it will reduce the
handover delay and enhance handover efficiency.
Different
fast handover protocol may need different parameters, whether
we may define some latent parameters in optional way in MIH
messages, thus in different fast handover protocol it may
select different parameters to carry?
Regards$B!$(B
Jing
**********************************************************************
This
e-mail and its attachments contain confidential information
from
HUAWEI, which is intended only for the person or
entity whose address
is listed above. Any use of the
information contained herein in any way
(including, but not
limited to, total or partial disclosure,reproduction,
or
dissemination) by persons other than the intended recipient(s)
is
prohibited. If you receive this e-mail in error, please
notify the
sender by phone or email immediately and delete
it!
**********************************************************************
----- Original Message
-----
Sent: Tuesday, May
01, 2007 12:20 AM
Subject: Re:
[802.21] MIH commands for handover
Anurag, Sanjib,
All,
Would it be possible to spin
these contributions to illustrate .21 services interacting
with PMIPor MIP as well?
Best
Regards,
Michael
Hello Anurag and Sanjib,
The intention of
the MIH handover command is not to replace FMIP signaling,
but to complement FMIP in aspects that are not present in
FMIP. The assumption of MIH as a handover control protocol
is not valid, but it is provides services for
facilitating/aiding hanadovers with the assumption that
there is a different handover control protocol. There is no
reason to spin the wheels and redo a published and validated
protocol again in
802.21.
Regards,
Srini
-----Original
Message-----
From: ext Anurag Uxa [mailto:Anurag.Uxa@LNTINFOTECH.COM]
Sent:
Mon 4/30/2007 3:05 AM
To:
STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] MIH
commands for handover
Dear Jing n All ,
As per
your concern about the DAD. It has already taken care. You
are just
considering the predictive situation, BUT we had
thought predictive and
reactive both a, b cases.
(a)
able to send fast binding update PAR and information
Reached to NAR
and confirmation has received by PAR but
not MN
(b) information has not reach to
NAR.
Sanjib query is relate to extend the command
with some IPaddress
related
TLV.
MIH_MN_HO_Candidate_Query.request
(
DestinationIdentifier,
CurrentLinkIdentifier,
CandidateLinkList,
QueryResourceList,
CandidatePoAList,
CandidateNwAddrList,
/*Access router?s addresses or a single
address of
NAR*/
MN_NCoAList,
/*List of NCoA as per Target n/w prefix or
a single
NCoA*/
)
MIH_MN_HO_Complete.request
(
DestinationIdentifier,
LinkIdentifier,
HandoverStatus,
PreviousARAddress
/*PAR?s IP Address*/
PreviousCoA
NewCoA
)
If
every body is ok with such changes, we will go ahead with
our
assumptions.
Regards
----------------------------------------------------------------------
Anurag
Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
(
) L&T Infotech Proprietary & Confidential
(+)
L&T Infotech Confidential
( ) L&T Infotech
Internal Use only
( ) General Business
Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
liujing
<jxli1979@HUAWEI.COM>
04/29/2007 08:21 AM
Please
respond to
liujing
<jxli1979@HUAWEI.COM>
To
STDS-802-21@listserv.ieee.org
cc
Subject
Re:
[802.21] MIH commands for
handover
Hello?Sanjib
I agree your idea using MIH messages to carry some
MMP(mobility
management protocol) information during
handover procedure. But the
implementation method you
proposed may exist some problems. From the chart
we can
see MN can generate the NCoA from the available prefix
info
obtained from IS Server, then MN sends these
configured NCoAs to all
candidate NARs existed in each
candidate networks to make Duplicate
Address Detection.
After duplicity checking, PAR in serving network
will
create the tunnel with these candidate NARs for
sending the packets. So
these steps such as NCoA
configuration?duplicity checking and tunnel
building work
with all candidate networks, that will increase the
spending
of network resources.
I suggest
whether we can do these works after network decision,
namely
once the target network is chosen, MN can generate
the NCoA only for
target NCoA in target network, and
sends this NCoA to the target NAR
by
MIH_MN_HO_Commit.request and MIH_N2N_HO_Commit.request
messages. Target
NAR will make duplicity checking after
receiving these messages, and
return the result of DAD to
PAR in serving network. Then PAR will create
the tunnel
with the target NAR. This will save network resources
and
enhance the efficiency of
handover.
regards,
Jing
Liu
**********************************************************************
This
e-mail and its attachments contain confidential information
from
HUAWEI, which is intended only for the person or
entity whose address
is listed above. Any use of the
information contained herein in any way
(including, but
not limited to, total or partial
disclosure,reproduction,
or dissemination) by persons
other than the intended recipient(s) is
prohibited. If
you receive this e-mail in error, please notify
the
sender by phone or email immediately and delete
it!
**********************************************************************
______________________________________________________________________
______________________________________________________________________
|
|
|