Re: [802.21] MIH commands for handover
$)C
Hello Junghoon,
Thanks for your comments. I am agree
with your explanation.
Pls find comments inline
Regards
----------------------------------------------------------------------
Anurag Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
( ) L&T Infotech Proprietary & Confidential
(+) L&T Infotech Confidential
( ) L&T Infotech Internal Use only
( ) General Business Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| "Junghoon Jee"
<jhjee@etri.re.kr>
05/02/2007 08:07 PM
|
|
To
| "Anurag Uxa" <Anurag.Uxa@LNTINFOTECH.COM>,
<STDS-802-21@listserv.ieee.org>
|
|
cc
|
|
|
Subject
| Re: [802.21] MIH commands for handover |
|
Hello Anurag,
Please find the comments inline:
From: ext Anurag Uxa [mailto:Anurag.Uxa@LNTINFOTECH.COM]
Sent: Wednesday, May 02, 2007 12:11 AM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] MIH commands for handover
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.
Junghoon> Yes, the core functionality
of MIH is to provide the network selection among heterogeneous networks.
Uxa> Agree.
It is supporting the mobility management protocol,
not performing the handover execution itself.
Uxa > If it is only
for support mobility, These many commands are not required if we
need to club MIH support with existing protocol or a NEW one. Just a concern
its fine with me.
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.
Junghoon> IEEE 802.21 is not
defining a fast IP handover protocol which aims to reduce the packet loss
or delay caused by changing the IP subnet.
Uxa > But as you said it
is for support for FMIPv6. Thats why we discussed few events which is essential
for FMIPv6.
As mentioned above, the MIH has a beauty of providing
the network selection among heterogeneous networks.
Uxa >TRUE
The higher layer handover protocol like FMIP can utilize
this functionality to expect which target NAR to access in the upcoming
network thus can pre-configure the NCoA and make a binding at the PAR in
advance of the movement that network.
Uxa >In
case of FMIPv6 which is only talks about minimize the latency and reduce
the packet loss. Here is my concern. why we need to send MIH commands for
QoServices as well FMIP6 messages for DAD functionality we are adding
RTT of messages as well increasing the buffer size at NAR. I was thinking
if we can use only send MIH messages we can also implement Proxy DAD by
setting flag in MIH mesage. Any way I was giving my idea not opposing for
MIH current capabilities.
My concern was here why should we follow the FMIPv6 messages which we can't
use for PMIPv6 further like michal concern.
Junghoon> The utilization of
the FMIP is a standardized way to provide a fast handover solution for
MIP.
I DO NOT think IEEE 802.21 need to define uniform
fast handover messages that can be used for all the moblity management
protocol.
Uxa >I don't want to define
the same or uniform messages we can bring some good result by changing
FMIP6 or MIH messages. Actually MIH messages are not yet imlemented fully
that why i wanted to suggest such minor changes for MIH messages.
If you want to provide a fast handover solution
for PMIP in case you are not comfortable with that performance,
you need to make an enhancement for that or
inventing a new one under the current standardization status at IETF.
Uxa >
Yes new one is required
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.
Junghoon> If you are thinking
about the Make-before-Break mode, you may not depend on the fast handover
solution in case where enough time is available to make a new MIP binding
for the target network before
the current Link is down. Moreover, please keep in
mind that the N2N*** MIH message which can traverse among PoSs are exchanged
with L3 transport in most cases.
Therefore, the motioned benefit is not so clear to
me. IMO, it seems more complicated in interacting with the higher layer
mobility protocol if we open that kind of already defined functionality
into our specification.
Uxa
> Yes Junghoon, To keep in mind Make-Before-Break
situation for multiple interfaces with single home address (where home
boundries of different interfaces are different. Need to revised RFC 3484
) is always bring some limitations of existing protocols. Either we need
to redirect flow on multiple interfaces or keep buffer for packets while
switching. As mentioned in PMIP6 case also NAI concen is there.
Thank & Regards
Anurag
BR,
Junghoon
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!
**********************************************************************
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________