|
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、Fast HMIP、Fast 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、duplicate 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、HMIP
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、Fast HMIP、Fast 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、duplicate 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，
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!
**********************************************************************
______________________________________________________________________
______________________________________________________________________
|
|