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! **********************************************************************
______________________________________________________________________
______________________________________________________________________
|