Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> 
> ______________________________________________________________________