| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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!
**********************************************************************
______________________________________________________________________
______________________________________________________________________