12
Recap the proposal Questions from last meeting and answers
M
M bit: 1 = migrated VDP request0 = 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
DCNDCN
NIC
VM
VM
ServervSwitchvSwitch
DHCP Server
TOR
1 5
2
33. DHCP Ack
5. DHCPACK
44. DHCP Snooping and set up IP/MAC
/port filter
1. DHCP request
2. DHCP Request
VM
VM
ServervSwitchvSwitch
migration
6
7 7. 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
NICNIC
VM
VM
ServervSwitchvSwitch
DHCP Server
TOR
1
5
2
3
2. VDP request w/ M bit
4
VM
VM
ServervSwitchvSwitch
migration
6
1. VM migration.
3. DHCP leasequery4. 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
VM
Server
vSwitchvSwitch
TOR
NIC
VM
VM
Server
vSwitchvSwitch
3 、 vm migratio
n
TORGW
1 、 IGMP JOIN
2 、 multicast group
traffic
IGMP 查询器
4. New port joins VM’s multicast groups. How?
12
GW IGMP querie
r
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
VM
Server
vSwitchvSwitch
TOR
NIC
VM
VM
Server
vSwitchvSwitch
1.VM migration
TORGW
3. IGMP query
IGMP 查询器
4. IGMP report
1
2
GW IGMP querie
r
32. 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
Stationassoc_reqassoc_rsp
Dataframe
VSI power on
Start migration
assoc_reqassoc_rsp
Dataframe Dataframe
Migrationcompletes
assoc_req w/ M-bit
assoc_rspTrigger 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.
