RE: [802.21] MIH commands for handover
Hi Anurag,
The design principle was to not provide a handover control
protocol. There are many flavors of those and 802.21 should provide services
that can fit with and in any handover scenario. There is no implicit assumption
or implication that FMIPv6 is used. The use of addresses, as you suggest,
provides a partial replacement for FMIPv6, but is not needed if a different
mobility management protocol like PMIP is used. Further, you are tying 802.21
with access router functionality, while this is not an excluded it is not the
orly architectural model how 802.21 can be deployed. Further, the handover
commands defined here are not mandatory to be used in a certain sequence. One
can use these to get the services required for that specific scenraio and
continue on with a different protcol.
Regards,
Srini
Hi Srini,
Yes you are correct. This is not a moto of 802.21 but can
we say it is the mazor functioanlity or the achivement to facilitate the
entities to know prior information of different networks with out attaching to
the network.
But in practical
scenarios for multiple interfaces generally (discussed technologies like WLAN,
WiFi, WiMax etc) most of the time handset will fall on over lap condition there
only FMIPv6 can solve the fast handover and then MIpv6 will further take place.
We will not go back to the discussion of requirement.
My concern was here why should we follow the FMIPv6
messages which we can't use for PMIPv6 further like michal concern. Bcoz we have
multiple interface which will give us a liberty to do the L2 Authentication
prior to switch to L3 messages. So for such kind of reasons if we can enhance
the MIH message TLV as i or sanjib had given for replacing example for
FMIPv6. Depending on MIH USER we can directly use MIH commands without wrapping
in to some different protocol messages.
One more thing i want to bring out here that we are not asking to change
the command as per the concern of so many people of mailing list to make fix
size of TLV. I am started thinking of limitation of these messages , It will be
good if we can use IP addresses in these commands. Otherwise IS handler we need
to implement in all the entities (like ARs, or ACRs) which is not required. Only
having in PSS or MN can solve the porpose.
Regards
----------------------------------------------------------------------
Anurag
Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
(
) L&T Infotech Proprietary & Confidential
(+) L&T Infotech
Confidential
( ) L&T Infotech Internal Use only
( ) General Business
Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Srinivas Sreemanthula
<Srinivas.Sreemanthula@NOKIA.COM>
04/30/2007 09:28 PM
|
Please respond
to
Srinivas.Sreemanthula@NOKIA.COM |
|
|
To
| STDS-802-21@listserv.ieee.org
|
|
cc
|
|
|
Subject
| Re: [802.21] MIH commands for
handover |
|
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!
**********************************************************************
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________