| Hi Jing, >   
Whereas, for fast handover protocol,such as FMIP、Fast HMIP、Fast PMIP and so on, 
it implements before MN attached target network, so we can use MIH commands to 
finish the procedure of IP address configuration、duplicate address detection and 
tunnel building during handover preparation, thus it will reduce the handover 
delay and enhance handover efficiency.   While 
I do not understand the reasoning behind this, I can say that the IP Fast 
handover procedures are defined with exactly the same goals in mind - to reduce 
the service disruption to under 150ms. The IETF WG have carefully identified and 
worked with everything related to IP layer and above -  IP addresses, 
conflicts, configuration, tunnel management and so on in the respective 
protocols. But they do not work on any the link specific (L2) information which 
can be useful in handovers. The best value MIH can add is in this area. Anything 
more, specially IP related information, would be redundant, 
restrictive and conflicting at best, IMHO.   Regards,Srini
   
 
 Hi Michael,Srinivas,All
 Of cource, MIH User may be different mobility management 
protocol.
 For MIP protocol,such as PMIP、HMIP and NetLMM, it 
implements only after MN attached the target network, so it is outside IEEE 
802.21 standard.
 Whereas, for fast handover protocol,such as 
FMIP、Fast HMIP、Fast PMIP and so on, it implements before MN attached target 
network, so we can use MIH commands to finish the procedure of IP address 
configuration、duplicate address detection and tunnel building during handover 
preparation, thus it will reduce the handover delay and enhance handover 
efficiency.
 Different fast handover 
protocol may need different parameters, whether we may define some latent 
parameters in optional way in MIH messages, thus in different fast handover 
protocol it may select different parameters to carry?
   Regards,     Jing **********************************************************************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!
 **********************************************************************
 
 
  ----- Original Message -----  Sent: Tuesday, May 01, 2007 12:20 AM Subject: Re: [802.21] MIH commands for 
  handover 
 Anurag, Sanjib, All,   Would it be possible to spin these contributions to 
  illustrate .21 services interacting with PMIPor MIP as 
  well?   Best Regards, Michael 
 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!
 **********************************************************************
 
 ______________________________________________________________________
 
 
 ______________________________________________________________________
 
 
 |