How It Works

The successful operation of OSCARS essentially centers on two fundamental processes:

1. Resource scheduling
2. Path routing based on resource availability and existing reservations, i.e., multi-constrained path computation

Both processes belong to a class of decision problems for which the time required to solve a problem increases rapidly as the size of the problem grows. To address this, OSCARS aggressively pares away any extraneous information prior to executing the path computation.

The OSCARS Reservation User Interface

A user accesses OSCARS software through a Web-browser interface, or a user-application via an API. The userʼs reservation request at minimum indicates the source, destination, bandwidth required, and start and end time. Upon receiving the request, OSCARS authenticates the identity of the user, and determines if he/she has the appropriate authorization. The OSCARS API is designed to be accessed directly by user software or middleware applications. This greatly increases efficiency by automating the reservation process. Once OSCARS has authenticated and authorized the userʼs requests, it determines if there is a solution path that meets all the constraints of the user. This path computation process is a core function of OSCARS.

Determining the Best Network Path

To make this path-computation process more efficient, the network link topology graph is first simplified. For example, if the user makes a bandwidth request for 6 gigabits/second, the software removes any edges in the network link topology graph that have less than 6 gigabits/second of available capacity prior to determining a solution path. If the path computation successfully finds a solution path, the software updates the resource manager database with the new reservation information (see Figure 1, where A, B, C, and D represent the userʼs connection to the network).

Figure 1: OSCARS determines an optimal solution path for data to travel and books reservations for network resources. (Solution path shown in blue.)

The path-computation engine in OSCARS is built on a uniquely flexible framework that allows distinct path computation elements to be composed an arbitrary workflow sequence (See Figure 2). These path-computation elements can distinctly take into account basic network properties such as bandwidth (the transmission capacity of the link), and latency (the time it takes to transmit a unit of data), as well as more esoteric constraints such as energy consumption to promote green networking, which is a growing movement to reduce the energy consumption of data centers.

Figure 2: OSCARS provides a flexible path-computation framework for arbitrary Path Computation Element (PCE) execution.

Communicating with the Network

OSCARS utilizes the network link topology to determine a solution path, but it is up to the network administrator to determine how much information to make available to OSCARS. For example, a network-administration system might select only certain links that it wants OSCARS to control, and in that case, it would build a network link topology with only those links. In essence, OSCARS does not know that there are other links outside of what it has been given in the network link topology, and will compute a solution path based only on the available information.

If OSCARS cannot find a solution path, it sends a response indicating that it was unable to meet the user’s request. Currently, only about 5 percent of requests fail, primarily due to insufficient unreserved bandwidth in the network. In these cases, the user simply makes a new request at a lower bandwidth rate.

Seamless Transit in Multiple Domains

The advancement of todayʼs large-scale sciences revolves around widely distributed resources utilized by global collaborations. As an example, ESnet connects more than 40 institutions serving thousands of DOE scientists. However, a majority of the traffic that ESnet handles crosses multiple network domains. Support for end-to-end guaranteed bandwidth circuits that transit multiple networks is extremely critical for modern science activities. If the userʼs requested source and destination span multiple network domains or cross over to different networks (see Figure 3), the OSCARS instance that receives the userʼs request (i.e., Domain 1) will execute the path-computation process in two iterations—the first one general, and the second more specific. If any one of the network domains is unable to provision the path because it cannot meet the userʼs requirements (e.g., bandwidth, number of hops, etc.), the first domain that initiated the request has the option to either communicate the failure to the user, or recompute the path over a different set of network domains.

Figure 3: OSCARS negotiates a path across multiple networks by iteratively determining the best way forward. (Intermediate and final solution paths shown in blue.)

Components of OSCARS

The OSCARS software incorporates complex technologies that allow network operators to automate and deliver a reliable guaranteed network service to the end-user. The various components of the OSCARS functionality are provided by the following eight components, here described briefly:

1. Web-browser interface/programmatic API: Interacts directly with the user or user application to get information regarding the connectivity requirements (e.g., how much bandwidth, what is the duration, where are the end-points, etc.)
2. Authentication/Authorization/Accounting module: Authenticates the user, and authorizes the userʼs request. This component also provides accounting information for billing or auditing.
3. Topology manager: Maintains and updates the network link topology information so the path-computation engine can accurately calculate solution paths.
4. Resource manager: Keeps information to track the various states of each reservation, e.g., “reserved,” “active,” “cancelled,” or “completed.” In essence, the resource manager is a database that stores all information about every reservation.
5. Notification broker: Notifies the user or any other entity (e.g., a network management system) if the state of the reservation changes. The notification can take the form of Web-service messages, e-mails, and Short Message Service (SMS) text messages.
6. Path-computation engine: Determines if a solution path that meets all the constraints specified by the user exists within the network link topology graph.
7. Device drivers: Communicate directly with the network elements (e.g., routers, switches, etc.) to set up and tear down the circuits as specified by the path-computation engine for the duration and bandwidth requested by the user. This component understands vendor platform-specific technologies (e.g., GMPLS, MPLS, Ethernet bridging, Quality of Service). This ability to abstract the underlying network element hardware is a critical aspect to making OSCARS vendor- and technology-agnostic. It has allowed OSCARS to quickly assimilate new and emerging technologies such as OpenFlow.
8. Workflow coordinator: Coordinates the workflow of the other components and user requests across network domains to facilitate the network reservation process. At the heart of the work-flow coordinator is the OSCARS state diagram, which dictates the behavior of the OSCARS software. Another core function of the work-flow coordinator is to communicate and coordinate user requests to OSCARS instances in other network domains to support multinetwork domain reservations. The multidomain aspect of OSCARS is a fundamental requirement, but it has exponentially increased the complexity of the work-flow coordinator.