Abstract:
Methods for supporting migration of virtual machines across multiprotocol label switching network and corresponding devices are disclosed. A method for supporting migration of virtual machines across multiprotocol label switching network comprises the steps of: a first label edge router (LER) receiving a migration enablement function (MEF) discovery message from a first virtual machine that wishes to register with the first LER; the first LER updating its own virtual machine binding database to reflect binding of the first virtual machine to the first LER; and the first LER sending a MEF advertisement message to the first virtual machine to indicate that the first LER completes the registration of the first virtual machine. According to this invention, no complex registration hierarchy is needed. Furthermore, the virtual machine has no need to get aware of the registration hierarchy and only a few registration signaling and processes involve the virtual machine.

Description:
TECHNICAL FIELD OF THE INVENTION 
       [0001]    The present invention relates to communication technology, more particularly, to methods for supporting migration of virtual machines (VMs) across multiprotocol label switching network and corresponding devices. 
       BACKGROUND OF THE INVENTION 
       [0002]    Cloud Computing has emerged with the development of the traditional computer technologies and network technologies such as Grid Computing, Distributed Computing, Parallel Computing, Utility Computing, Network Storage Technologies, Virtualization, Load Balance, etc. It is intended to integrate multiple low-cost computing entities into one system with powerful computing capability through the network, and distribute such powerful computing capability to end users with the help of such modes as SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), IaaS (Infrastructure-as-a-Service), MSP (Manage Service Provider), etc. 
         [0003]    The virtualization technology can perform re-mapping of virtual machines and physical resources based on variation in workload by encapsulating services into the virtual machines and mapping them to the physical resources, namely a cloud center, thereby dynamically realizing the workload balance of the whole system. That is, the virtual machines may be dynamically migrated from one cloud center to another so as to realize the workload balance of the system. 
         [0004]    From users&#39; point of view, no matter how the virtual machines are migrated, their services should be continuous during the virtual machine migrations. 
         [0005]    In practice, multiprotocol label switching (MPLS) network can be employed to interconnect the respective cloud centers. 
       SUMMARY OF THE INVENTION 
       [0006]    The purpose of the present invention is to provide a solution to support the migration of the virtual machines across the multiprotocol label switching network. 
         [0007]    According to a first aspect of the present invention, there is provided a method for supporting migration of virtual machines across multiprotocol label switching network, which comprises the steps of: 
         [0008]    a first label edge router (LER) receiving a migration enablement function (MEF) discovery message from a first virtual machine that wishes to register with the first LER; 
         [0009]    the first LER updating its own virtual machine binding database to reflect binding of the first virtual machine to the first LER; and 
         [0010]    the first LER sending a MEF advertisement message to the first virtual machine to indicate that the first LER completes the registration of the first virtual machine. 
         [0011]    According to a second aspect of the present invention, there is provided a first label edge outer (LER) of supporting migration of virtual machines across multiprotocol label switching network, which comprises: 
         [0012]    migration enablement function (MEF) discovery message receiving means that receives a migration enablement function (MEF) discovery message from a first virtual machine that wishes to register with the first LER; 
         [0013]    updating means that updates its own virtual machine binding database to reflect binding of the first virtual machine to the first LER; and 
         [0014]    MEF advertisement message sending means that sends a MEF advertisement message to the first virtual machine to indicate that the first LER completes the registration of the first virtual machine. 
         [0015]    According to a third aspect of the present invention, there is provided a method for supporting migration of virtual machines across multiprotocol label switching network, which comprises the steps of: 
         [0016]    a first area route reflector (ARR) receiving a virtual machine binding update message from a first label edge outer (LER) located in an area of the first ARR, the virtual machine binding update message indicating that the first virtual machine is bound to the first LER; 
         [0017]    the first ARR updating its own virtual machine binding database based on the received virtual machine binding update message to reflect the binding of the first virtual machine to the first LER. 
         [0018]    According to a fourth aspect of the present invention, there is provided a first area route reflector (ARR) of supporting migration of virtual machines across multiprotocol label switching network, which comprises: 
         [0019]    virtual machine binding update message receiving means that receives a virtual machine binding update message from a first label edge router (LER) located in an area of the first ARR, the virtual machine binding update message indicating that the first virtual machine is bound to the first LER; and 
         [0020]    updating means that updates its own virtual machine binding database based on the received virtual machine binding update message to reflect the binding of the first virtual machine to the first LER. 
         [0021]    With the present invention, no complex registration hierarchy is needed. Furthermore, the virtual machine has no need to get aware of the registration hierarchy and only a few registration signaling and processes involve the virtual machine. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0022]    Other objects and effect of the present invention will become more apparent and comprehensive from the following description in conjunction with drawings and with the full understanding of the present invention, in which: 
           [0023]      FIG. 1  illustratively shows an environment in which an embodiment of the present invention may be implemented; 
           [0024]      FIG. 2  shows virtual machine migration enablement function discovery and registration process according to an embodiment of the present invention; 
           [0025]      FIG. 3  illustratively shows the format of an ICMP router solicitation message according to an embodiment of the present invention; 
           [0026]      FIG. 4  illustratively shows the format of an ICMP router advertisement message according to an embodiment of the present invention; 
           [0027]      FIG. 5   a  illustratively shows the basic encoding format of MP_REACH_VMB; 
           [0028]      FIG. 5   b  illustratively shows the basic encoding format of MP_UNREACH_VMB; 
           [0029]      FIG. 5   c  illustratively shows a virtual machine binding update extension field; 
           [0030]      FIG. 6  shows the related process when a client initiates a communication with a virtual machine; 
           [0031]      FIG. 7  illustratively shows the basic encoding format of MP_VMB_QUERY; 
           [0032]      FIG. 8  illustratively shows the basic encoding format of MP_VMB_NTFC; 
           [0033]      FIG. 9  illustratively shows the related process when the virtual machine is being migrated according to an embodiment of the present invention; 
           [0034]      FIG. 10  illustratively shows the related process when the virtual machine is being migrated according to another embodiment of the present invention; 
           [0035]      FIG. 11  shows a block diagram of the label edge router according to an embodiment of the present invention; 
           [0036]      FIG. 12  shows a block diagram of the area route reflector according to an embodiment of the present invention. 
       
    
    
       [0037]    The same reference number refers to the same, similar or corresponding feature or function throughout the above drawings. 
       DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0038]    Now the preferred embodiments of the present invention are described in detail in conjunction with the accompany drawings. 
         [0039]      FIG. 1  illustratively shows the environment in which an embodiment of the present invention may be implemented. 
         [0040]    As shown in  FIG. 1 , the MPLS network  100  for a service provider is divided into three serving areas  101 ,  102 ,  103 . The serving area  101  includes one area route reflector ARR 1 and two label edge routers LER 11, LER 12. The serving area  102  includes one area route reflector ARR 2 and two label edge routers LER 21, LER 22. The serving area  103  includes one area route reflector ARR 3 and three label edge routers LER 31, LER 32, LER 33. 
         [0041]    Assume that the virtual machine  41  is currently registered with the LER 11, the virtual machine  42  is currently registered with the LER 21, and the virtual machine  43  is currently registered with the LER 31. More specifically, the virtual machine  41  is instantiated at a cloud center connected to the LER 11, the virtual machine  42  is instantiated at a cloud center connected to the LER 21, and the virtual machine  43  is instantiated at a cloud center connected to the LER 31, these cloud centers are not shown in  FIG. 1 . In addition, assume that the client  51  that wishes to communicate data packets with the virtual machine is connected to the LER 11, the client  52  is connected to the LER 21, and the client  53  is connected to the LER 31. 
         [0042]    To support the VM migration, the LERs and ARRs in each serving area are implemented with migration enablement function (MEF), as will be described in detail below. 
         [0043]    Considering extensibility, the ARR is introduced in the embodiments of the present invention as described below. The ARR is used to limit the direct transmission of some messages between the LERs, instead, these messages are forwarded via the ARR. That is to say, some messages are not directly transmitted between the LERs, instead, they are transmitted between the LER and the ARR or between the ARRs, as will be described in detail below. 
         [0044]    In addition, it is to be noted that although the interconnections between the LERs are not shown in  FIG. 1 , the LERs are capable of communicating with each other through label switching paths (LSPs) established therebetween. Similarly, although the interconnections between the ARRs are not shown in  FIG. 1 , the ARRs are capable of communicating with each other through label switching paths (LSPs) established therebetween. And, although the connections between each LER and the ARR in an area where the LER is located are not shown in  FIG. 1 , each LER and the ARR in the area where the LER is located can communicate with each other. 
         [0045]    Of course, it should be appreciated by those skilled in the art that the ARR is not necessary in other embodiments of the present invention. 
         [0046]    In the embodiments of the present invention, some public IP addresses are reserved, which define virtual machine identifiers (VMIDs) supporting the VM migration. These VMIDs are meaningless for all the intermediate label switching routers (LSRs) not shown in  FIG. 1 . That is to say, in the embodiments of the present invention, forwarding equivalence class (FEC) of the data packet destined to the virtual machine is determined by an ingress LER for the data packet based on the IP address of the LER with which the virtual machine is registered, and is independent of the IP address of the virtual machine itself. 
         [0047]    The embodiments of the present invention will be described below taking IPv4 for example. However, those skilled in the art should understand that the present invention is not limited to IPv4, and also applicable to IPv6. 
         [0048]    Table 1 shows the assumed IP addresses of the VMs, LERs and ARRs in the MPLS network  100  shown in  FIG. 1 . 
         [0000]    
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Node 
                 IP address 
               
               
                   
                   
               
             
             
               
                   
                 VM 41 
                 210.101.34.25 
               
               
                   
                 VM 42 
                 210.101.34.30 
               
               
                   
                 VM 43 
                 210.101.34.35 
               
               
                   
                 LER 11 
                 211.140.111.1 
               
               
                   
                 LER 12 
                 211.140.222.1 
               
               
                   
                 ARR 1 
                 211.136.10.1 
               
               
                   
                 LER 21 
                 212.140.111.1 
               
               
                   
                 LER 22 
                 212.140.222.1 
               
               
                   
                 ARR 2 
                 212.136.10.1 
               
               
                   
                 LER 31 
                 213.140.111.1 
               
               
                   
                 LER 32 
                 213.140.222.1 
               
               
                   
                 LER 33 
                 213.140.233.1 
               
               
                   
                 ARR 3 
                 213.136.10.1 
               
               
                   
                   
               
             
          
         
       
     
         [0049]      FIG. 2  shows the virtual machine migration enablement function discovery and registration process according to an embodiment of the present invention. 
         [0050]    Assume that the virtual machine migration enablement function discovery and registration process shown in  FIG. 2  is executed between the VM 41 and the LER 11. Those skilled in the art should understand that the virtual machine migration enablement function discovery and registration processes between the VM 42 and the LER 21 and between the VM 43 and the LER 31 are similar to the process shown in  FIG. 2 . In addition, the virtual machine migration enablement function discovery and registration process shown in  FIG. 2  is not only applicable to the MEF discovery and registration initiated by the VM for the first time, but also applicable to the MEF discovery and registration initiated when the VM is being migrated. 
         [0051]    Firstly, at step S 210 , the first LER, namely LER 11, receives a migration enablement function (MEF) discovery message from the first virtual machine (i.e. VM 41) that wishes to register with the first LER. 
         [0052]    When the LER 11 discovers that the VMID contained in the MEF discovery message falls within the IP address range for supporting the migration of the virtual machine, at step S 220 , the first LER updates its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER. 
         [0053]    Finally, at step S 230 , the first LER sends a MEF advertisement message to the first virtual machine to indicate completion of the registration of the first virtual machine. 
         [0054]    The virtual machine is only registered with the routers at the edge of the MPLS network, i.e. the LERs. That is to say, the MEF discovery and registration process will not be extended to the intermediate LSRs behind the LERs. 
         [0055]    The MEF discovery message may be sent through an ICMP (Internet Control Message Protocol) router solicitation message. 
         [0056]    More specifically, the ICMP router solicitation message may be extended to send the MEF discovery message. 
         [0057]    For the ICMP router solicitation message, the ICMP Type field should be set to “10”. The ICMP router solicitation message is identified as being used to send the MEF discovery message by setting the ICMP Code field of the ICMP router solicitation message with the unused value C1 or other value. 
         [0058]    The MEF discovery message may carry the following information, including but not limited to: 
         [0059]    1) Type Flag; 
         [0060]    2) Virtual Machine ID; 
         [0061]    3) Last LER ID; 
         [0062]    4) Last ARR ID; 
         [0063]    5) Association ID. 
         [0064]    The Type Flag “0” indicates that this message is the MEF discovery message. The Virtual Machine ID indicates the IP address of the virtual machine to be registered, and the LER will register this virtual machine only when the VM ID is within a specified range. The Last LER ID indicates the IP address of the LER with which the virtual machine is lastly registered before the current registration. When the virtual machine initiates the MEF discovery and registration for the first time, the Last LER ID equals to “0”. The Last ARR ID indicates the IP address of the ARR of the area where the LER with which the virtual machine is lastly registered prior to the current registration is located. When the virtual machine initiates the MEF discovery and registration for the first time, Last ARR ID equals to “0”. Association ID is a sequence number used to keep track of the registration message pairs—MEF discovery/MEF advertisement. 
         [0065]      FIG. 3  illustratively shows the format of the ICMP router solicitation message according to an embodiment of the present invention. 
         [0066]    As shown in  FIG. 3 , the ICMP router solicitation message includes a Type field  310  with 1 byte, a Code field  312  with 1 byte, a Checksum field  314  with 2 bytes, an Unused field  316  with 4 bytes, a Type Flag field  318  with 1 byte, a Length field  320  with 1 byte, a VM ID field  322  with 4 bytes, a Last LER ID field  324  with 4 bytes, a Last ARR ID field  326  with 4 bytes, and an Association ID field  328  with 4 bytes. The Type Flag field  318 , the Length field  320 , the VM ID field  322 , the Last LER ID field  324 , the Last ARR ID field  326  and the Association ID field  328  are extensions to the MEF Discovery message. The Length field  320  indicates the lengths (the number of bytes) of the VM ID field  322 , the Last LER ID field  324 , the Last ARR ID field  326  and the Association ID field  328 . 
         [0067]    As described above, the LER 11 updates its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER. 
         [0068]    The following Table 2 shows the virtual machine binding database of the LER 11. 
         [0000]    
       
         
               
               
               
             
           
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 VMID 
                 LER ID 
               
               
                   
                   
               
             
             
               
                   
                 210.101.34.25 
                 211.140.111.1 
               
               
                   
                 210.3.2.4 
                 211.140.111.1 
               
               
                   
                   
               
             
          
         
       
     
         [0069]    As shown in Table 2, the first LER 11 has registered the first virtual machine VM 41, 210.101.34.25, in its virtual machine binding database. 
         [0070]    After registering the first VM 41 in its virtual machine binding database, the LER 11 replies the MEF advertisement message to the first VM 41. 
         [0071]    The MEF advertisement message may be sent through the ICMP router advertisement message. 
         [0072]    More specifically, the ICMP router advertisement message may be extended to send the MEF advertisement message. 
         [0073]    For the ICMP router advertisement message, the ICMP Type field should be set to “9”. The ICMP router advertisement message is identified as being used to send the MEF advertisement message by setting the ICMP Code field of the ICMP router advertisement message with an unused value C2 or other value. 
         [0074]    The MEF advertisement message may carry the following information, including but not limited to: 
         [0075]    1) Type Flag; 
         [0076]    2) Serving LER ID; 
         [0077]    3) Serving ARR ID; 
         [0078]    4) Association ID. 
         [0079]    The Type Flag “1” indicates that the message is the MEF advertisement message. The Serving LER ID indicates the IP address of the LER with which the virtual machine is currently registered, i.e. the IP address of the LER 11 in this embodiment. The Serving ARR ID indicates the IP address of the ARR of the area where the LER with which the virtual machine is currently registered is located, i.e. the IP address of ARR 1 in this embodiment. The Association ID is a sequence number used to keep track of the Registration message pairs—MEF discovery/MEF advertisement. 
         [0080]      FIG. 4  illustratively shows the format of the ICMP router advertisement message according to an embodiment of the present invention. 
         [0081]    As shown in  FIG. 4 , the ICMP router advertisement message includes a Type field  410  with 1 byte, a Code field  412  with 1 byte, a Checksum field  414  with 2 bytes, a Number of Address field  416  with 1 byte, an Address Entry Size field  418  with 1 byte, a Life Time field  420  with 2 bytes, a Router Address [1] field  422  with 4 bytes, a Preference Level [1] field  424  with 4 bytes, a Type Flag field  426  with 1 byte, a Length field  428  with 1 byte, a Serving LER ID field  430  with 4 bytes, a Serving ARR ID field  432  with 4 bytes, and an Association ID field  434  with 4 bytes. The Type Flag field  426 , the Length field  428 , the Serving LER ID field  430 , the Serving ARR ID field  432  and the Association ID field  434  are extensions to the MEF advertisement message. The Length field  428  indicates the lengths (number of bytes) of the Serving LER ID field  430 , the Serving ARR ID field  432  and the Association ID field  434 . 
         [0082]    Upon completion of the registration, the first LER 11 can forward the data packets received from the first virtual machine  41  to the LER to which the corresponding client is connected, such as the second LER 31 connected with the client  53 . 
         [0083]    According to an embodiment of the present invention, after completion of the registration, the process shown in  FIG. 2  may further comprise the following step: the first LER 11 sends a virtual machine binding update message to the area route reflector ARR1 of the area where the first LER 11 is located, such that the ARR 1 can update its own virtual machine binding database to reflect the binding of the first virtual machine  41  to the first LER 11. 
         [0084]    The virtual machine binding update message may be sent through a BGP (Boundary Gateway Protocol) update message. 
         [0085]    More specifically, the BGP update message may be extended to send the virtual machine binding update message. 
         [0086]    For example, the virtual machine binding update message is sent using MP_REACH_NLRI by defining a new &lt;AFI(=A1), SAFI(=S1)&gt; pair. The AFI is the Address Family Identifier, and the SAFI is the Subsequent Address Family Identifier. 
         [0087]    That is to say, MP_REACH_NLRI is extended to send the virtual machine binding update message. 
         [0088]    Such extended MP_REACH_NLRI attribute is specifically represented as MP_REACH_VMB. 
         [0089]      FIG. 5   a  illustratively shows the basic encoding format of the MP_REACH_VMB. 
         [0090]    As shown in  FIG. 5   a , MP_REACH_VMB attribute includes an AFI field  510  with 2 bytes (the value of which is A1), a SAFI field  512  with 1 byte (the value of which is S1), a Length of Next Hop Network Address field  514  with 1 byte, a Network Address of Next Hop (variable) field  516  with 4 bytes, a Reserved field  518  with 1 byte, and a VM Binding Update Extension field  520  with several bytes. The VM Binding Update Extension field  520  is the extension to the virtual machine binding update message. 
         [0091]      FIG. 5   c  illustratively shows the virtual machine binding update extension field  520 . 
         [0092]    As shown in  FIG. 5   c , the virtual machine binding update extension field  520  includes: a Length field  5201  with 1 byte, which indicates the length of the virtual machine binding update extension field  520 ; a VMID field  5202  with 4 bytes, which indicates the IP address of the registered virtual machine; a Target Router ID field  5203  with 4 bytes, which indicates the IP address of the LER or ARR receiving the virtual machine binding update message; a Serving LER ID field  5204 , which indicates the IP address of the LER with which the virtual machine is registered; a Serving ARR ID field  5205 , which indicates the IP address of the ARR of the area where the serving LER with which the virtual machine is registered is located; a Last LER ID field  5206 , which indicates the IP address of the LER with which the virtual machine is lastly registered prior to registering with the current serving LER, and if the virtual machine initially initiates the MEF discovery and registration, the Last LER ID=0; a Last ARR ID field  5207 , which indicates the IP address of the ARR of the area where the LER with which the virtual machine is lastly registered prior to registering with the current serving LER is located, and if the virtual machine initially initiates the MEF discovery and registration, the Last ARR ID=0. 
         [0093]    For example, the LER 11 can send to the ARR 1 the virtual machine binding update message including: &lt;VMID=210.101.34.25, Target Server ID=211.136.10.1, Serving LER ID=211.140.111.1, Serving ARR ID=211.136.10.1, Last LER ID=0, Last ARR ID=0&gt;. After receiving the virtual machine binding update message, the ARR 1 updates its own virtual machine binding database to reflect the binding of the first virtual machine  41  to the first LER 11. 
         [0094]    Table 3 shows the recording format in the virtual machine binding database for the ARR 1. 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                 VMID 
                 Serving LER ID 
                 Serving ARR ID 
                 Querying LER ID 
                 Querying ARR ID 
               
               
                   
               
             
             
               
                 210.101.34.25 
                 211.140.111.1 
                 211.136.10.1 
                   
                   
               
               
                 210.101.27.88 
                 211.140.222.1 
                 211.136.10.1 
                 201.171.101.32 
                 201.168.153.1 
               
               
                   
                   
                   
                 201.235.202.11 
                 201.232.131.1 
               
               
                   
               
             
          
         
       
     
         [0095]    In Table 3, the first three columns represent the ID of the VM, the ID of the serving LER with which the VMID is registered and the ID of the serving ARR of the area where the serving ARR is located, respectively. The latter two columns respectively represent query logs of the previous binding record of the virtual machine to the LER, that is, the ID of the LER which queries the binding record of the VM to the LER, and the ID of the ARR of the area where the LER is located. 
         [0096]    The virtual machine binding database of the ARR differs from that of the LER in that it further comprises a query log entry. In addition, the virtual machine binding database of the ARR only records the VM bindings to the LERs within its area, but not records the VM bindings to the LERs outside its area. 
         [0097]    Here, since the VM 41 is just registered with the LER 11 and no other LER and ARR queries this binding record, the query log for this binding record is null. 
         [0098]    If the MEF discovery and registration is initiated when the VM is being migrated, after completion of the registration, the process shown in  FIG. 2  may further comprise the following step: 
         [0099]    the first LER sends the virtual machine binding update message to a third LER (e.g., the LER 22) with which the first virtual machine is lastly registered prior to registering with the first LER, such that the third LER can update its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER. 
         [0100]    The first LER forwards to the first virtual machine the data packets received from the third LER with which the first virtual machine is lastly registered prior to registering with the first LER, or the first LER forwards to the first virtual machine the data packets received from the second LER connected with the client. 
         [0101]      FIG. 6  shows the related process when the client initiates communication with the virtual machine. 
         [0102]    Assume  FIG. 6  shows the related process when the client  51  connected to the first LER 11 initiates the communication with the second VM 43 registered with the LER 31. 
         [0103]    Of course, those skilled in the art should appreciate that the process shown in  FIG. 6  can apply to the case in which any client initiates the communication with any virtual machine. 
         [0104]    When the client  51  initiates the communication with the second VM 43 registered with the LER 31, the data packet is sent (step S 602 ) to the first LER 11 to which the client  51  is connected. 
         [0105]    The first LER 11 learns the destination address (i.e., the ID of the VM 43) from the data packet, and queries (step S 604 ) its own virtual machine binding database based on this VMID so as to find the binding record of the second VM 43. 
         [0106]    If the binding record of the second VM 43 is found in its own virtual machine binding database, the first LER 11 determines the forwarding equivalence class of the data packet destined to the second VM 43 based on the IP address of the LER with which the second VM 43 is registered, and the process ends. 
         [0107]    If the binding record of the second VM 43 is not found in its own virtual machine binding database, the first LER 11 sends (step S 606 ) the first virtual machine binding query message to the ARR 1 of the area where the first LER 11 is located to obtain the binding of the second VM 43. 
         [0108]    After receiving the first virtual machine binding query message, the ARR 1 queries (step S 608 ) its own virtual machine binding database to find the binding record of the second VM 43. 
         [0109]    If the binding record of the second VM 43 is found in its own virtual machine binding database, the ARR 1 sends the first virtual machine binding query advertisement message to the first LER 11 to notify the first LER 11 of the binding of the second virtual machine VM 43 to the corresponding LER, and records the query log in its virtual machine binding database. 
         [0110]    After receiving the first virtual machine binding query advertisement message, the first LER 11 updates its own virtual machine binding database, and determines the forwarding equivalence class of the data packet destined to the second VM 43 based on the IP address of the LER with which the second VM 43 is registered, and the process ends. 
         [0111]    In the process shown in  FIG. 6 , assume that the ARR 1 does not find the binding record of the second VM 43 in its own virtual machine binding database, then the ARR 1 sends (step S 610 ) the second virtual machine binding query message to any other ARR to obtain the binding of the second VM 43. 
         [0112]    After receiving the second virtual machine binding query message, the ARR (e.g., ARR 3) queries (step S 612 ) its own virtual machine binding database to find the binding record of the second VM 43. 
         [0113]    Since the ARR 3 finds the binding record of the second VM 43 in its own virtual machine binding database, the ARR 3 sends (step S 614 ) the second virtual machine binding query advertisement message to the ARR1 to notify the ARR 1 of the binding of the second virtual machine VM 43 to the corresponding LER (i.e., the LER 31), and records the query log in its virtual machine binding database. 
         [0114]    After receiving the second virtual machine binding query advertisement message, the ARR 1 sends (step S 616 ) the first virtual machine binding query advertisement message to the first LER 11 to notify the first LER 11 of the binding of the second virtual machine VM 43 to the corresponding LER. 
         [0115]    After receiving the first virtual machine binding query advertisement message, the first LER 11 updates (step S 618 ) its own virtual machine binding database, and determines the forwarding equivalence class of the data packet destined to the second VM 43 based on the IP address of the LER with which the second VM 43 is registered. Thereafter, as shown by step S 620 , the data packets can be transmitted between the client  51  and the VM 43. 
         [0116]    The above described virtual machine binding query messages and virtual machine binding query advertisement messages may be sent through the BGP update message. 
         [0117]    Furthermore, considering extensibility, the virtual machine binding query message and the virtual machine binding query advertisement message are only transmitted between the LER and the ARR or between the ARRs, and are not transmitted between the LERs. 
         [0118]    More specifically, the BGP update message can be extended to send the virtual machine binding query message and the virtual machine binding query advertisement message. 
         [0119]    The virtual machine binding query message can be sent using MP_REACH_NLRI by defining a new &lt;AFI(=A1), SAFI(=S2)&gt; pair. 
         [0120]    That is to say, the MP_REACH_NLRI is extended to send the virtual machine binding query message. 
         [0121]    Such extended MP_REACH_NLRI attribute is specifically represented as MP_VMB_QUERY. 
         [0122]    The virtual machine binding query advertisement message can be sent using MP_REACH_NLRI by defining a new &lt;AFI(=A1), SAFI(=S3)&gt; pair. 
         [0123]    That is to say, the MP_REACH_NLRI is extended to send the virtual machine binding query advertisement message. 
         [0124]    Such extended MP_REACH_NLRI attribute is specifically represented as MP_VMB_NTFC. 
         [0125]      FIG. 7  illustratively shows the basic encoding format of the MP_VMB_QUERY. 
         [0126]    As shown in  FIG. 7 , the MP_VMB_QUERY attribute includes an AFI field  710  with 2 bytes (the value of which is A1), a SAFI field  712  with 1 byte (the value of which is S2), a Length of Next Hop Network Address field  714  with 1 byte, a Network Address of Next Hop (variable) field  716  with 4 bytes, a Reserved field  718  with 1 byte, a Length field  722  with 1 byte which indicates the lengths of the following fields, a Type Flag field  724  with 1 byte, a Querying LER ID field  726  with 4 bytes which indicates the IP address of the LER that makes a virtual machine binding query, a Querying ARR ID field  728  with 4 bytes which indicates the IP address of the ARR of the area where the LER that makes the virtual machine binding query is located, a Number of Queries field  730  with 4 bytes which indicates the number of the virtual machine binding queries carried in this message, VMID fields  732 - 1 ,  732 - 2 , . . . ,  732 -N which indicate the IP addresses of the virtual machines on which the binding query is to be performed. 
         [0127]    The Length field  722  and the fields thereafter are extensions to the virtual machine binding query message. 
         [0128]    The Type Flag field  724  may be set with two values, for example, 1 and 2. 
         [0129]    When the value of the Type Flag field is “1”, it indicates that the virtual machine binding query message is the virtual machine binding query message from the LER to the ARR of the area where the LER is located, for example, the first virtual machine binding query message described above. 
         [0130]    When the value of the Type Flag field is “2”, it indicates that the virtual machine binding query message is the virtual machine binding query message from the ARR of the area where the LER is located to any other ARR, for example, the second virtual machine binding query message described above. 
         [0131]    For example, the LER 11 can send to the ARR 1 the first virtual machine binding query message including: &lt;Type Flag=1, Querying LER ID=211.140.111.1, Querying ARR ID=, Number of Queries=1, VMID=210.101.34.35&gt;. 
         [0132]    For the first virtual machine binding query message, since it is sent from the LER 11 to the ARR 1 of the area where the LER 11 is located, the Querying ARR ID field may be omitted. 
         [0133]    The ARR 1 may send to any other ARR the second virtual machine binding query message including: &lt;Type Flag=2, Querying LER ID=211.140.111.1, Querying ARR ID=211.136.10.1, Number of Queries=1, VMID=210.101.34.35&gt;. 
         [0134]    For the second virtual machine binding query message, the Querying ARR ID field cannot be omitted. 
         [0135]      FIG. 8  illustratively shows the basic encoding format of the MP_VMB_NTFC. 
         [0136]    As shown in  FIG. 8 , the MP_VMB_NTFC attribute includes an AFI field  810  with 2 bytes (the value of which is A1), a SAFI field  812  with 1 byte (the value of which is S3), a Length of Next Hop Network Address field  814  with 1 byte, a Network Address of Next Hop (variable) field  816  with 4 bytes, a Reserved field  818  with 1 byte, a Length field  820  with 1 byte which indicates the lengths of the following fields, a Type Flag field  822  with 1 byte, a VM ID field  824  with 1 byte which indicates the IP address of the virtual machine on which the binding query is performed, a Serving LER ID field  826  with 4 bytes which indicates the IP address of the LER with which the queried virtual machine is registered, a Serving ARR ID field  828  with 4 bytes which indicates the IP address of the ARR of the area where the LER with which the queried virtual machine is registered is located, a Number of Queries field  830  with 4 bytes which indicates the number of LER-ARR pairs which queries the binding record of the virtual machine, Querying LER-Querying ARR pair fields  832 - 1 ,  832 - 2 , . . . ,  832 -N with 4 bytes respectively, which indicate the IP addresses of the LER-ARR pairs that conduct the binding query on the virtual machine in the above VM ID field  824 . 
         [0137]    The Length field  822  and the fields thereafter are extensions. 
         [0138]    The Type Flag field  822  may be set with four values, for example, 1, 2, 3 and 4. 
         [0139]    When the value of the Type Flag field is 1, it indicates that the virtual machine binding query advertisement message is sent from the ARR of the area where the LER that initiates the virtual machine binding query is located to the LER, for example, the above-described first virtual machine binding query advertisement message. In this case, the pair of Querying LER and Querying ARR fields may be omitted. 
         [0140]    When the value of the Type Flag field is 2, it indicates that the virtual machine binding query advertisement message is sent from other ARR to the ARR of the area where the LER that initiates the virtual machine binding query is located, for example, the above-described second virtual machine binding query advertisement message. 
         [0141]    When the value of the Type Flag field is 3, it indicates that the MP_VMB_NTFC attribute sends the first virtual machine binding database advertisement message, and the first virtual machine binding database advertisement message is sent from the ARR to the LER. In this case, the pair of Querying LER and Querying ARR pair fields may be omitted. The Number of Queries may be set to 0. 
         [0142]    When the value of the Type Flag field is 4, it indicates that the MP_VMB_NTFC attribute sends the second virtual machine binding database advertisement message, and the second virtual machine binding database advertisement message is sent from one ARR to another ARR. 
         [0143]    For example, the ARR 3 can send to the ARR 1 the second virtual machine binding query advertisement message including: &lt;Type Flag=2, VMID=210.101.34.35, Serving LER ID=213.140.111.1, Serving ARR ID=213.136.10.1, Number of Queries=1, Querying LER ID 1=211.140.111.1, Querying ARR ID 1=211.136.10.1&gt;. 
         [0144]    The ARR 1 may send to the LER 11 the first virtual machine binding query advertisement message including: &lt;Type Flag=1, VMID=210.101.34.35, Serving LER ID=213.140.111.1, Serving ARR ID=213.136.10.1, Number of Queries=0&gt;. 
         [0145]      FIG. 9  illustratively shows the related process when the virtual machine is being migrated according to an embodiment of the present invention. 
         [0146]    In the embodiment shown in  FIG. 9 , assume that the VM 41 currently registered with LER 11 is to be migrated to the LER 12. That is, the VM 41 is migrated between the LERs within the area served by the same ARR (referred to as intra-domain migration hereinafter). In addition, assume that the VM 41 currently communicates the data packets with the client  53  connected to the LER 31, and therefore, the query log that the querying LER is LER 31 and the querying ARR is ARR 3 is included in the virtual machine binding database of the ARR 1. 
         [0147]    Firstly, at step S 902 , the VM 41 sends to the fourth LER (i.e. the LER 12) the MEF discovery message including: &lt;Type=0, VMID=210.101.34.25, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1, Association ID=14&gt;. 
         [0148]    After receiving the MEF discovery message, the LER 12 knows that the VM 41 performs the intra-domain migration, because the Last ARR ID is same as the ID of the ARR of the area where the LER 12 is located. At step S 904 , the LER 12 updates its own virtual machine binding database to reflect the binding of the VM 41 to the LER 12. 
         [0149]    Next, at step S 906 , the LER 12 sends to the VM 41 the MEF advertisement message including: &lt;Type=1, Serving LER ID=211.140.222.1, Serving ARR ID=211.136.10.1, Association ID=14&gt;. 
         [0150]    Upon completion of the MEF discovery and registration process, as shown in step S 908 , the data packet sent from the VM 41 to the client  53  will be directly transferred to the LER 12, which forwards the data packet to the LER 31 to which the client  53  is connected, and the LER 31 forwards the data packet to the client  53 . 
         [0151]    Then, at steps S 909  and S 910 , the LER 12 sends the virtual machine binding update message to the LER 11 with which the VM 41 is lastly registered prior to registering with the LER 12 and to the ARR 1 of the area where the LER 12 is located, respectively. 
         [0152]    The virtual machine binding update message sent to the LER 1 lincludes: &lt;VMID=210.101.34.25, Target Router ID=211.140.111.1, Serving LER ID=211.140.222.1, Serving ARR ID=211.136.10.1, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1&gt;. 
         [0153]    The virtual machine binding update message sent to the ARR 1 includes: &lt;VMID=210.101.34.25, Target Router ID=211.136.10.1, Serving LER ID=211.140.222.1, Serving ARR ID=211.136.10.1, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1&gt;. 
         [0154]    After receiving the virtual machine binding update message sent by the LER 12, the LER 11 knows that the VM 41 has been migrated from the LER 11 to the LER 12. Therefore, at step S 911 , the LER 11 updates its own virtual machine binding database to reflect the binding of the VM 41 to the LER 12. 
         [0155]    Thereafter, as shown in step S 914 , the LER 11 forwards to the LER 12 the data packet received from the LER 31 to which the client  53  is connected and destined to the VM 41 in step  912 , and the data packet is forwarded to the VM 41 by the LER 12 at step S 916 . 
         [0156]    After receiving the virtual machine binding update message from the LER 12, the ARR 1 knows that the VM 41 is still within its serving area, and updates its own virtual machine binding database to reflect that the VM 41 has been migrated from the LER 11 to the LER 12, as shown in step S 918 . 
         [0157]    Next, the ARR 1 sends the second virtual machine binding database advertisement message to all of the other ARRs that have queried the binding of the VM 41. 
         [0158]    As described above, the ARR 3 has queried the binding of the VM 41. Therefore, at step S 920 , the ARR 1 sends to the ARR 3 the second virtual machine binding database advertisement message including: &lt;Type Flag=4, VMID=210.101.34.25, Serving LER ID=211.140.222.1, Serving ARR ID=211.136.10.1, Number of Queries=1, Querying LER ID 1=213.140.111.1, Querying ARR ID 1=213.136.10.1&gt;. 
         [0159]    After receiving the second virtual machine binding database advertisement message, at step S 922 , the ARR 3 sends the first virtual machine binding database advertisement message to the LER 31. The first virtual machine binding database advertisement message includes: &lt;Type Flag=3, VMID=210.101.34.25, Serving LER ID=211.140.222.1, Serving ARR ID=211.136.10.1, Number of Queries=0&gt;. 
         [0160]    After receiving the first virtual machine binding database advertisement message, the LER 31 knows that the VM 41 has been migrated from the LER 11 to the LER 12. Therefore, at step S 924 , the LER 31 updates its own virtual machine binding database to reflect the migration of the VM 41. Furthermore, the forwarding equivalence class of the data packet sent to the VM 41 is determined based on the IP address of the LER 12 with which the VM 41 is registered, at step S 926 , the data packet destined to the VM 41 are directly sent to the LER 12 instead of the LER 11 through the label switching path (LSP). That is to say, after the step S 926 , there is no necessary to forward the data packet from the LER 31 to the LER 12 via the LER 11. 
         [0161]    In addition, step S 925  is further comprised after step S 924 . At step S 925 , the LER 31 sends additional virtual machine binding update message to the LER 11, such that the LER 11 removes the binding record of the VM 41 from its virtual machine binding database. 
         [0162]    The additional virtual machine binding update message can be sent through the BGP (Boundary Gateway Protocol) update message. 
         [0163]    More specifically, the BGP update message can be extended to send the virtual machine binding update message. 
         [0164]    For example, the additional virtual machine binding update message can be sent using MP_UNREACH_NLRI by defining a new &lt;AFI(=A1), SAFI(=S1)&gt; pair. The AFI is the address family identifier, and the SAFI is the subsequent address family identifier. 
         [0165]    That is to say, MP_UNREACH_NLRI is extended to send the additional virtual machine binding update message. 
         [0166]    Such extended MP_UNREACH_NLRI attribute is specifically represented as MP_UNREACH_VMB. 
         [0167]      FIG. 5   b  illustratively shows the basic encoding format of MP_UNREACH_VMB. 
         [0168]    As shown in  FIG. 5   b , MP_UNREACH_VMB attribute includes an AFI field  510  with 2 bytes (the value of which is A1), a SAFI field  512  with 1 byte (the value of which is S1), and a VM Binding Update Extension field  520  with several bytes. The VM Binding Update Extension field  520  is an extension to the additional virtual machine binding update message. 
         [0169]    The VM Binding Update Extension field  520  has been described above in conjunction with  FIG. 5   c  and it will not be described here again. 
         [0170]      FIG. 10  illustratively shows the related process when the virtual machine is being migrated according to another embodiment of the present invention. 
         [0171]    In the embodiment shown in  FIG. 10 , assume that the VM 41 currently registered with the LER 11 is to be migrated to the LER 21. That is, the VM 41 is migrated between the LERs in the areas served by different ARRs (referred to as inter-domain migration hereinafter). In addition, assume that the VM 41 currently communicate the data packets with the client  53  connected to the LER 31, and therefore, the query log that the querying LER is LER 31 and the querying ARR is ARR 3 is included in the virtual machine binding database of the ARR 1. 
         [0172]    First, at step S 1002 , the VM 41 sends to the fourth LER (i.e. the LER 21) the MEF discovery message including: &lt;Type=0, VMID=210.101.34.25, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1, Association ID=15&gt;. 
         [0173]    After receiving the MEF discovery message, the LER 21 knows that the VM 41 performs the inter-domain migration, because the Last ARR ID is different from the ID of the ARR of the area where the LER 21 is located. At step S 1004 , the LER 21 updates its own virtual machine binding database to reflect the binding of the VM 41 to the LER 21. 
         [0174]    Next, at step S 1006 , the LER 21 sends to the VM 41 the MEF advertisement message including: &lt;Type=1, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Association ID=15&gt;. 
         [0175]    Upon completion of the MEF discovery and registration process, as shown in step S 1008 , the data packet sent from the VM 41 to the client  53  will be directly transferred to the LER 21, which forwards the data packet to the LER 31 to which the client  53  is connected, and the LER 31 forwards the data packet to the client  53 . 
         [0176]    Then, at steps S 1009  and S 1010 , the LER 21 sends the virtual machine binding update message to the LER 11 with which the VM 41 is lastly registered before registering with the LER 21, and to the ARR 2 of the area where the LER 21 is located, respectively. 
         [0177]    The virtual machine binding update message sent to the LER 11 includes: &lt;VMID=210.101.34.25, Target Router ID=211.140.111.1, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1&gt;. 
         [0178]    The virtual machine binding update message sent to the ARR 2 includes: &lt;VMID=210.101.34.25, Target Router ID=212.136.10.1, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1&gt;. 
         [0179]    After receiving the virtual machine binding update message sent by the LER 21, the LER 11 knows that the VM 41 has been migrated from the LER 11 to the LER 21. Therefore, at step S 1011 , the LER 11 updates its own virtual machine binding database to reflect the binding of the VM 41 to the LER 21. 
         [0180]    Thereafter, as shown in step S 1014 , the LER 11 forwards the data packet received from the LER 31 connected to the client  53  and destined to the VM 41 in step  1012  to the LER 21, which forwards the data packet to the VM 41 at step S 1016 . 
         [0181]    After receiving the virtual machine binding update message from the LER 21, the ARR 2 knows that the VM 41 is migrated into its serving area, and as shown in step S 1018 , the ARR 2 sends to the ARR 1 the virtual machine binding update message which includes: &lt;VMID=210.101.34.25, Target Router ID=211.136.10.1, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Last LER ID=211.140.111.1, Last ARR ID=211.136.10.1&gt;. 
         [0182]    Upon receiving this message, the ARR 1 knows that VM 41 has been migrated outside of its serving area, and as shown in step S 1020 , the ARR 1 updates its own virtual machine binding database to modify the serving LER of the VM 41 from the LER 11 to the LER 21 and modify the serving ARR of the VM 41 from the ARR 1 to the ARR 2. 
         [0183]    Then, at step S 1022 , the ARR 1 sends the binding record about the VM 41 including the query log of the VM 41 to the ARR 2 through the second virtual machine binding database advertisement message. For example, the ARR 1 sends to the ARR 2 the second virtual machine binding database advertisement message including: &lt;Type Flag=4, VMID=210.101.34.25, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Number of Queries=3, Querying LER ID 1=213.140.111.1, Querying ARR ID 1=213.136.10.1, Querying LER ID 2=211.142.109.1, Querying ARR ID 2=211.130.10.1, Querying LER ID 3=213.145.111.1, Querying ARR ID 3=213.130.10.1&gt;. 
         [0184]    After receiving the second virtual machine binding database advertisement message from the ARR 1, as shown in step S 1024 , the ARR 2 updates its own virtual machine binding database to add a triple &lt;VMID=210.101.34.25, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1&gt; and three query logs &lt;Querying LER ID 1=213.140.111.1, Querying ARR ID 1=213.136.10.1&gt;, &lt;Querying LER ID 2=211.142.109.1, Querying ARR ID 2=211.130.10.1&gt;, &lt;Querying LER ID 3=213.145.111.1, Querying ARR ID 3=213.130.10.1&gt; into its virtual machine binding database. 
         [0185]    Then, at step S 1026 , the ARR 2 sends the second virtual machine binding database advertisement message to each of the ARRs that query the binding of the VM 41 (e.g., the ARR 3). The second virtual machine binding database advertisement message, for example, includes &lt;Type Flag=4, VMID=210.101.34.25, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Number of Queries=1, Querying LER ID 1=213.140.111.1, Querying ARR ID 1=213.136.10.1&gt;. 
         [0186]    After receiving the second virtual machine binding database advertisement message, at step S 1028 , the ARR 3 sends to the LER 31 the first virtual machine binding database advertisement message which includes: &lt;Type Flag=3, VMID=210.101.34.25, Serving LER ID=212.140.111.1, Serving ARR ID=212.136.10.1, Number of Queries=0&gt;. 
         [0187]    After receiving the first virtual machine binding database advertisement message, the LER 31 knows that the VM 41 has been migrated from the LER 11 to the LER 21. Therefore, at step S 1030 , the LER 31 updates its own virtual machine binding database to reflect the migration of the VM 41. The forwarding equivalence class of the data packet sent to the VM 41 is determined based on the IP address of the LER 21 with which the VM 41 is currently registered. At step S 1032 , the data packet destined to the VM 41 is directly sent to the LER 21 instead of the LER 11 through the label switching path (LSP). That is to say, after step S 1032 , there is no necessary to forward the data packet from the LER 31 to the LER 21 via the LER 11. 
         [0188]    In addition, after step S 1030 , step S 1031  is further comprised. At step S 1031 , the LER 31 sends to the LER 11 additional virtual machine binding update message as described above in conjunction with  FIG. 9 , such that the LER 11 removes the binding record about the VM 41 from its virtual machine binding database. 
         [0189]      FIG. 11  shows a block diagram of the label edge router (LER) according to an embodiment of the present invention. 
         [0190]    The LER as shown in  FIG. 11  may be any one of the LERs shown in  FIG. 1 . Assume that the LER shown in  FIG. 11  is the first LER, i.e. the LER 11. 
         [0191]    As shown in  FIG. 11 , the LER 11 comprises: migration enablement function (MEF) discovery message receiving means  1102  configured to receive the migration enablement function (MEF) discovery message from the first virtual machine that wishes to register with the first LER; updating means  1104  configured to update its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER; and MEF advertisement message sending means  1106  configured to send the MEF advertisement message to the first virtual machine to indicate that the first LER completes the registration of the first virtual machine. 
         [0192]    According to an embodiment of the present invention, when finding that the VMID contained in the MEF discovery message falls within the IP address range for supporting the migration of the virtual machines, the updating means updates its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER. 
         [0193]    According to an embodiment of the present invention, the LER 11 further comprises: virtual machine binding update message sending means  1108  configured to send the virtual machine binding update message to the first area route reflector (ARR) of the area where the first LER is located, such that the first ARR can update its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER, and/or to send the virtual machine binding update message to the third LER with which the first virtual machine is recently registered prior to registering with the first LER, such that the third LER can update its own virtual machine binding database to reflect the binding of the first virtual machine to the first LER. 
         [0194]    According to an embodiment of the present invention, the LER 11 further comprises: data packet forwarding means  1110  configured to forward the data packets received from the first virtual machine to the second LER to which the client is connected, and/or to forward, to the first virtual machine, the data packets received from the third LER with which the first virtual machine is lastly registered prior to registering with the first LER, and/or forward, to the fourth LER, the data packets received from the second LER to which the client is connected and destined to the first virtual machine. The data packet forwarding means forwards the data packets based on forwarding equivalence classes of the data packets, wherein the forwarding equivalence class of the data packet destined to the first virtual machine is determined, by an ingress LER for the data packets, based on the IP address of the LER with which the first virtual machine is registered, instead of the IP address of the first virtual machine itself. 
         [0195]    According to an embodiment of the present invention, the LER 11 further comprises: virtual machine binding update message receiving means  1112  configured to receive the virtual machine binding update message from the fourth LER with which the first virtual machine is lastly registered after being registered with the first LER; and wherein the updating means is further configured to update its own virtual machine binding database to reflect the binding of the first virtual machine to the fourth LER. 
         [0196]    According to an embodiment of the present invention, the LER 11 further comprises: virtual machine binding query message sending means  1114  configured to send the first virtual machine binding query message to the first ARR of the area where the first LER is located to obtain the binding of the second virtual machine, wherein the client connected to the first LER wishes to send the data packets to the second virtual machine; and virtual machine binding query advertisement message receiving means  1116  configured to receive the first virtual machine binding query advertisement message from the first ARR of the area where the first LER is located; and wherein the updating means  1104  is further configured to update its own virtual machine binding database to reflect the binding of the second virtual machine to the corresponding LER. 
         [0197]    According to an embodiment of the present invention, the LER 11 further comprises: virtual machine binding database advertisement message receiving means  1118  configured to receive the first virtual machine binding database advertisement message from the first ARR of the area where the first LER is located; and wherein the updating means  1104  is further configured to update its own virtual machine binding database to reflect the migration of the second virtual machine between the LERs. 
         [0198]      FIG. 12  shows a block diagram of the area route reflector (ARR) according to an embodiment of the present invention. 
         [0199]    The ARR as shown in  FIG. 12  can be any one of the ARRs shown in  FIG. 1 . Assume that the ARR shown in  FIG. 12  is the first ARR, i.e. ARR 1. 
         [0200]    As shown in  FIG. 12 , the ARR 1 comprises: virtual machine binding update message receiving means  1202  configured to receive the virtual machine binding update message from the first label edge router (LER) located in the area of the first ARR, the virtual machine binding update message indicating that the first virtual machine is bound to the first LER; and updating means  1204  configured to update its own virtual machine binding database based on the received virtual machine binding update message to reflect the binding of the first virtual machine to the first LER. 
         [0201]    According to an embodiment of the present invention, the ARR 1 further comprises: virtual machine binding query message receiving means  1206  configured to receive the first virtual machine binding query message from the first LER, wherein the first virtual machine binding query message is intended to obtain the binding of the second virtual machine; and virtual machine binding query advertisement message sending means  1208  configured to send the first virtual machine binding query advertisement message to the first LER to notify the first LER of the binding of the second virtual machine to the corresponding LER. 
         [0202]    According to an embodiment of the present invention, the ARR 1 further comprises: virtual machine binding query message sending means  1210  configured to send the second virtual machine binding query message to any other ARR to obtain the binding of the second virtual machine; and virtual machine binding query advertisement message receiving means  1212  configured to receive the second virtual machine binding query advertisement message from at least one of the any other ARR, the second virtual machine binding query advertisement message reflecting the binding of the second virtual machine to the corresponding LER. 
         [0203]    According to an embodiment of the present invention, the virtual machine binding query message receiving means  1206  is configured to receive the second virtual machine binding query message from the second ARR, wherein the second virtual machine binding query message is intended to obtain the binding of the first virtual machine, and the second ARR is the ARR 3; and the virtual machine binding query advertisement message sending means is configured to send the second virtual machine binding query advertisement message to the second ARR to notify the second ARR of the binding of the first virtual machine. 
         [0204]    According to an embodiment of the present invention, the ARR 1 further comprises: virtual machine binding database advertisement message sending means  1214  configured to send the first virtual machine binding database advertisement message to the first LER to notify the first LER of the migration of the second virtual machine between the LERs. 
         [0205]    According to an embodiment of the present invention, the ARR 1 further comprises: virtual machine binding database advertisement message receiving means  1216  configured to receive the second virtual machine binding database advertisement message from at least one of the any other ARR, the second virtual machine binding database advertisement message indicating the migration of the second virtual machine between the LERs. 
         [0206]    According to an embodiment of the present invention, the virtual machine binding database advertisement message sending means  1214  is configured to send the second virtual machine binding database advertisement message to the second ARR to notify the second ARR of the migration of the first virtual machine between the LERs. 
         [0207]    According to an embodiment of the present invention, the ARR 1 further comprises: virtual machine binding update message sending means  1218  configured to send the virtual machine binding update message to the third ARR, wherein the virtual machine binding update message indicates that the first virtual machine is migrated from one LER in an area served by the third ARR to the first LER, and the third ARR is the ARR 2; and virtual machine binding database advertisement message receiving means  1216  configured to receive the second virtual machine binding database advertisement message from the third ARR, the second virtual machine binding database advertisement message indicating the query log about the first virtual machine. 
         [0208]    According to an embodiment of the present invention, the virtual machine binding update message receiving means  1202  is further configured to receive the virtual machine binding update message from the fourth ARR, and the virtual machine binding update message received from the fourth ARR indicates that the first virtual machine is migrated from the first LER to one LER in the area served by the fourth ARR, the fourth ARR is the ARR 2; the updating means  1204  is further configured to update its own virtual machine binding database to reflect that the first virtual machine is migrated from the first LER to the one LER in the area served by the fourth ARR; and the virtual machine binding database advertisement message sending means  1214  is configured to send the second virtual machine binding database advertisement message to the fourth ARR to notify the fourth ARR of the query log about the first virtual machine. 
         [0209]    It should be noted that in order to ease the understanding of the present invention, the above description has omitted some more specific technical details known to those skilled in the art but may be necessary to implement the present invention. 
         [0210]    Those skilled in the art should also appreciate that the present invention is not limited to the above described steps, and the present invention also encompasses combination, or order change, etc. of the above described steps. The final scope of the present invention is defined by the appended claims. 
         [0211]    Therefore, the above embodiments are chosen and described in order to explain the principles and practical application of the present invention, and to enable those skilled in the art to understand that, without departing from the essence of the invention, all such modifications and alterations will fall into protection scope of the invention defined by claims. 
         [0212]    Furthermore, those skilled in the art will appreciate that the steps of the various methods described above may be implemented by a programmed computer. Here, some embodiments cover the program storage, which is machine or computer readable and encoded with machine executable or computer executable instruction program, wherein the instructions perform some or all of the steps of the above methods. The program storage may be magnetic storage medium such as magnetic disk or magnetic tape, hard disk driver or optical readable digital data storage medium. The embodiments also cover the computer programmed to perform the steps of the above methods.