liyizhou@huawei.com

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

4

4. 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 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

VM

Server

vSwitchvSwitch

TOR

NIC

VM

VM

Server

vSwitchvSwitch

3 、 vm migratio

n

TOR

GW

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

TOR

GW

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_req

assoc_rsp

Dataframe

VSI power on

Start migration

assoc_req

assoc_rspDataframe

Dataframe

Migrationcompletes

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.