| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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.
It is supporting the mobility management protocol, not performing
the handover execution itself.
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.
As mentioned above, the MIH has a beauty of providing the network selection
among heterogeneous networks.
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.
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.
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. 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.
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 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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! ********************************************************************** ______________________________________________________________________ ______________________________________________________________________
|