Version 4 (modified by ibaldin, 11 years ago)


Integrating BEN and Orca Phase I: VLAN Support

This pages describes the first phase of integrating BEN and Orca. In this phase Orca will enable users to allocate virtual machines across all BEN sites and network the virtual machines using VLAN provisioned by BEN. We refer to this approach as Phase I of the integration steps. Future phases will make it possible to sliver and configure lower-level layers of BEN, e.g., point-to-point links, fiber spectrum, bandwidth, etc.


The goal of this phase is to enable the dynamic allocation of virtual machines from all BEN sites connected by a VLAN provisioned from BEN. Once this phase is complete, it should be possible for an end user to use the Orca portal to allocate multiple virtual machines and connect them using a VLAN.


The system contains of the following Orca actors:

  • BEN RENCI Site Authority - site authority controlling the XEN VMMs at BEN's site at RENCI. We refer to this actor as 'site_renci'.
  • BEN Duke Site Authority - site authority controlling the XEN VMMs at BEN's site at Duke. We refer to this actor as 'site_duke'
  • BEN VLAN Site Authority - site authority controlling the creation of BEN VLANs. We refer to this actor as 'site_vlan'
  • BEN Clearinghouse - broker responsible for the allocation of resources from site_renci, site_duke, and site_vlan.
  • End user service manager - one or more service managers to use resources from all sites.

To bootstrap the system, each site exports to the clearing house a ticket that grants the clearinghouse the right to allocate resources from that site. The ticket specifies the amount of resources and the period of time for which the clearinghouse is granted control.

To create a slice an end user first must obtain a lease for a VLAN to span all BEN sites. To do this, the user's service manager issues a ticket request for a new VLAN to the BEN clearinghouse. If the clearing house has an available VLAN, it issues a ticket to the service manager. We refer to the reservation holding this ticket as the VLAN reservation.

To obtain virtual machines from each BEN site, the user's service manager issues several ticket requests for the needed virtual machines to the BEN clearinghouse: one request per BEN site that it needs resources from. If the broker can satisfy the request it issues a ticket for each BEN site from which the user requested resources. We refer to the reservations holding each of these tickets as the VM reservations.

The sequence of redeeming the VLAN and VM reservations is important. For simplicity, we require that the VLAN reservation is redemed before the VM reservations, i.e., a VM reservation cannot be redeemed until the VLAN reservation has been redeemed successfully. There are several reasons for this approach:

  • VLAN configuration on each VM requires that a specific XEN bridge is created and that it is associated with a specific VLAN tag
  • While it may be possible to perform VLAN configuration for a given VM after it has been created, this approach requires site_renci and site_duke to export a configuration interface that can be invoked by a service manager to bind a VM to a given VLAN. Implementing and exposing such an interface is technically feasible, but requires more effort

While processing a redeem request for a VLAN, site_vlan chooses an available VLAN tag and configures the VLAN to span across all BEN sites (currently site_duke and site_renci). The VLAN tag is added to the VLAN reservation's resource properties list and is sent back to the service manager. Service managers extract the VLAN tag from the VLAN reservation and add it to the configuration properties list of each VM reservation. When sites process a VM reservation they configure each VM with an additional interface bound to a XEN bridge associated with the corresponding VLAN tag.

QUESTION: Where do the IPs and subnet information for each VLAN come from? Are these specified by the service manager? Does site_vlan need to know the subnet base and mask when setting the VLAN? ANSWER: We want to leave the user the freedom to assign addresses on the data interfaces as they see fit. For now this assignment should be part of the pre-configured guest controller logic.

What Do We Need

  1. BEN VLAN site policy This policy will be responsible for choosing a VLAN tag and activating the VLAN (if necessary).
  2. BEN VLAN broker policy This policy will be used by the clearing house to determine if a VLAN is available over a requested period.
  3. BEN VLAN site handler A handler to activate a BEN VLAN with a given VLAN tag
  4. BEN VLAN guest controller A guest controller responsible for issuing requests for resources from BEN. The controller is responsible for sequencing the VLAN and VM reservations.
  5. Sample guest handler to install something interesting on the allocated VMs.
  6. Modifications to Orca's XEN VMM driver to create xen bridges and to bind them a specific VLAN tag

The BEN VLAN guest controller will provide a portal plugin with several custom views to enable users to:

  • list the existing BEN slices they have
  • select what resources they want from each site and to which slice they want to bind these resources