 Recap the proposal  Questions from last meeting and answers

M M bit: 1 = migrated VDP request 0 = newly started VDP request

 to facilitate switch port configuration and restore the states ◦ DHCP snooping based filtering ◦ Multicast group join

 Problems: ToR port snoops DHCPACK and binds IP/MAC/port to filter the following traffic. When VM moves, VM won’t resend DHCP request and hence new port won’t listen any DHCPACK. Therefore filter won’t be enabled on new port. NIC DCN VM Server vSwitch DHCP Server TOR DHCP Ack 5. DHCPACK 4 4. DHCP Snooping and set up IP/MAC /port filter 1. DHCP request 2. DHCP Request VM Server vSwitch migration DHCP Snooping based filter on new port. How? 6. VM migration. Note ： DHCP Discover and DHCP Offer exchanges are ignored in picture

 With M bit: trigger some standard DHCP in-band mechanism to be used. E.g. DHCP leasequery NIC VM Server vSwitch DHCP Server TOR VDP request w/ M bit 4 VM Server vSwitch migration 6 1. VM migration. 3. DHCP leasequery 4. DHCP Ack 5. DHCP Snoops ACK and set up IP/MAC /port filter 6 。 VDP response

 Problems: VM1 sends IGMP join so that ToR would have a multicast membership list including VM1 on certain port for certain multicast group address. After migration, VM1 won’t resend IGMP join as it has no awareness of movement of itself. Multicast membership list won’t have VM1’s info enabled on new port until vm1 receives and responds the general IGMP query from IGMP querier. NIC VM Server vSwitch TOR NIC VM Server vSwitch 3 、 vm migration TOR GW 1 、 IGMP JOIN2 、 multicast group traffic IGMP 查询器 4. New port joins VM’s multicast groups. How? 1 2 GW IGMP querier 3

 With M bit: trigger some standard IGMP in-band mechanism to be used. E.g. new ToR port fakes IGMP query to VM NIC VM Server vSwitch TOR NIC VM Server vSwitch 1.VM migration TOR GW 3. IGMP query IGMP 查询器 4. IGMP report 1 2 GW IGMP querier 3 2. VDP request w/ M bit 4

 Q: Without M bit, we can still use standard VDP associate to trigger the DHCP/IGMP behavior we want.  A: No, because of the timing. M bit (migration completes) is a signal to do the triggering at the right time. Conventional VDP is not strictly coupled to VM’s state. (see next slide). Wrong timing implies the high possibility to get wrong information.

Uncertain time duration ‘old’ EVB Station ‘old’ EVB Bridge ‘new’ EVB Bridge ‘new’ EVB Station assoc_req assoc_rsp Dataframe VSI power on Start migration assoc_req assoc_rsp Dataframe Migration completes assoc_req w/ M-bit assoc_rsp Trigger DHCP/IGMP procedures VSI can still join/leave multicast group and update its DHCP lease Uncertain time duration Conclusion: M-bit indicates the completion of the migration which is the right time to trigger DHCP/IGMP procedures described before pre-assoc/assoc can be sent at any time, it is not coupled to the migration state of VSI. And it is also used for keepalive.

 Q: Can hypervisor perform like DHCP relay/IGMP relay to send the DHCP leasequery and IGMP query instead of bridge?  A: Hypervisor could do that but we believe it would be better to put all the functions on adjacent bridge for the following reason ◦ Bridges have already implemented the features like DHCP relay or IGMP relay/proxy. There is little extra functions required. While hypervisors are not. ◦ There may come more real time configurations/provisions other than DHCP/IGMP in future. It is tedious to have hypervisor add features on demands of network requirements every time.

Questions from last meeting (3)  Q: Can hypervisor know the state of VM?  A: Yes. Take VMWare’s vSphere as example. It has the event to indicate the start and end of a migration with event type VmBeingHotMigratedEvent and VmMigratedEvent. Hence it is considered implementation practical for hypervisor being able to set M bit at right time.