Re: [802.21] MIH commands for handover
I am slowly catching up the discussion. I have some comments.
- PAR can perform IS query even before receiving a
MIH_MN_HO_Candidate_Query request message from the MN and cache the
resulting information about list of NARs. So the latency problem can
be easily solved.
- There is a fundamental protocol design issue as to whether (i) the
MIH_*_HO_Candidate_Query and MIH_N2N_HO_Query_Resources commands
should be able to optionally carry network-layer parameters as much as
possible and keep adding new ones to work with every mobility
management protocol, or (ii) the commands should not carry
network-layer parameters at all, recommending use of Information
Service to obtain those parameters separately from the Command
Service.
Regards,
Yoshihiro Ohba
On Fri, Apr 27, 2007 at 09:56:12PM +0530, Sanjib Das wrote:
> Handover Using MIH Messages:
> a) Predictive Mode:
>
>
>
>
>
> Explanation of above depicted flow:
>
>
> MN can generate the NCoA from the available prefix info (from IS Server).
>
>
>
> 1. For initiating the handover MN sends MIH_MN_HO_Candidate_Query.Request
> query to PAR. As per the draft (version 4) MN sends following information
> in this command.
>
> MIH_MN_HO_Candidate_Query.request (
> DestinationIdentifier,
> CurrentLinkIdentifier,
> CandidateLinkList,
> QueryResourceList,
> CandidatePoAList
> )
>
> But once the request query is received by PAR it needs to send the
> MIH_N2N_HO_Query_Resources.Request to NAR. But in Candidate query the MN
> never sends NAR?s IP address. Now there are two ways to get the NAR?s IP
> address.
> PAR can query the IS Server for NAR?s address using CandidatePoA address
> as the key. But this method can increase the latency. But this brings out
> a scenario where IS Handler in ACR/AR can exist.
>
> MN should send the NAR?s address (as it can get it from IS Server) to PAR,
>
> so that Resource Query can be send easily. In this approach, one more
> parameter should be added into the Candidate query request message.
>
> 2. Once the PAR gets MIH_N2N_HO_Query_Resources.Confirm , it needs to
> create the tunnel for sending all the packets to NAR (until the handover
> is over). But for creating the tunnel, PAR should have the NCoA of MN &
> PAR in turn should send the NCoA to NAR for duplicity checking. This is
> analogous to FBU & FBack mechanism of FMIPv6.
>
> 3. As per the above discussed point, the candidate Query should contain
> two more parameters.
>
> MIH_MN_HO_Candidate_Query.request (
> DestinationIdentifier,
> CurrentLinkIdentifier,
> CandidateLinkList,
> QueryResourceList,
> CandidatePoAList,
> CandidateNwAddrList, /*Access router?s addresses*/
> MN_NCoAList, /*List of NCoA as per Target n/w prefix*/
> )
> MN_NCoA should be there in both MIH_N2N_HO_Query_Resources.Request &
> MIH_N2N_HO_Query_Resources.Response messages also.
>
>
> NAR should verify the New CoA for duplicity.
> If the NAR is an ACR, then it can check the New Address against its list
> of MN?s addresses (This list is maintained by the ACR).
> In case of AR also the same method can be adopted.
>
>
>
> MIH_N2N_HO_Query_Resources.Response should contain MN?s confirmed NCoA
> along with requested resource list. Once the Response message is received,
> PAR should create the tunnel now.
>
>
>
> MIH_MN_HO_Candidate_Query.Response should contain MN?s confirmed NCoA &
> the requested resource list.
>
>
>
> L2 connection is established with target link.
>
>
>
> 1. This is analogous to FMIPv6 FNA message. This should initiate sending
> all buffered packets in NAR (which it received over tunnel from PAR) to
> MN. As per the definition in draft, MN sends following parameters in
> request message.
>
> MIH_MN_HO_Complete.request (
> DestinationIdentifier,
> LinkIdentifier,
> HandoverStatus
> )
>
> Once this is received by NAR, it should inform PAR for closing the tunnel
> & flushing all the information for that MN. This can be done using the
> message MIH_N2N_HO_Complete (Network<->Network).
>
> MIH_N2N_HO_Complete.request (
> DestinationIdentifier,
> MNIdentifier,
> CurrentLinkIdentifier,
> HandoverStatus
> )
>
> But this message does not include the PAR?s IP address. So it is MN?s job
> to send the PAR?s address in MIH_MN_HO_Complete.request message, which in
> turn can be used by NAR for sending MIH_N2N_HO_Complete request to PAR.
>
> There can be one more parameter in MIH_N2N_HO_Complete request message.
>
> MIH_MN_HO_Complete.request (
> DestinationIdentifier,
> LinkIdentifier,
> HandoverStatus,
> PreviousARAddress /*PAR?s IP Address*/
> )
>
>
>
>
> Please Comment
>
> thanks & regards
> Sanjib
>
> ______________________________________________________________________