WhatIF-Driven-Multi-Constrained-OSCARS

What-IF Driven Multi-Constrained OSCARS
Technical Report
On
By
Bharath H. Ramaprasad

Contents
1. About the Report on What-IF .................................................................................................................3
1.1 About This Document..............................................................................................................................3
1.2 Intended Audience...................................................................................................................................3
1.3 Related Documentation...........................................................................................................................3
1.4 How This Report Is Organized ................................................................................................................3
1.5 Document Conventions ...........................................................................................................................4
1.6 Distribution Information ...........................................................................................................................4
1.7 Questions and Suggestions ....................................................................................................................4
2. Introduction..............................................................................................................................................5
2.1 Scope and Purpose.................................................................................................................................5
2.2 Abstract ...................................................................................................................................................6
2.3 Definitions and Abbreviations..................................................................................................................7
3. Assumptions and Risks..........................................................................................................................8
4. Background on OSCARS........................................................................................................................9
5. Problem Definition.................................................................................................................................14
6. Design.....................................................................................................................................................17
7. Implementation......................................................................................................................................26
8. Case Studies..........................................................................................................................................28
9. Conclusion .............................................................................................................................................52
10. Future Work .........................................................................................................................................53
11. References ...........................................................................................................................................54

1. About the Report on What-IF
1.1 About This Document
This document contains a comprehensive report on the project titled “What-IF driven multi-
constrained OSCARS” which includes the following: requirements analysis, high level design, low-
level design, implementation details, results and conclusion. The scope of the project includes
defining an independent offline inter-domain messaging protocol along with creation of new
module(s) or changes to the existing module(s) to achieve the deliverable.
1.2 Intended Audience
This document is intended for OSCARS users and developers, UMASSD’s Advanced Computing
Networks Laboratory’s PI, DOE-COMMON researchers and students and Lawrence Berkeley National
Laboratories ESnet employees who will be involved with further development extensions and
implementation of new features on top of this project. Also, this document may be used by DOE’s
Product Management while harvesting additional features of What-IF in the subsequent versions of
the core product.
1.3 Related Documentation
Other documentation that may be helpful includes the following:
http://www.es.net/services/virtual-circuits-
oscars/documentation/
Documentation on OSCARS
<Internal Document- Available upon request &
Subject to authorization>
PCE Architecture by Eric Pouyoul
http://www.es.net/services/virtual-circuits-
oscars/software/
A-Z on OSCARS
1.4 How This Report Is Organized
This document contains the following topics.
Introduction Describes the scope and purpose of the
document.
Assumptions and Risks Contains the assumptions and risks made while
aligning with the processes.
Related Work Describes the related work
Problem Definition Defines the problem at hand currently with
OSCARS
Requirements Analysis Describes and analyses the requirement.
Design Describes the high level and low level design

Implementation Describes the implementation details
Results Lists and Describes the results
Conclusion Concludes the report with objectives and
benefits achieved
Future Work Describes the future work related to What-IF.
References List of referenced articles
1.5 Document Conventions
...
1.6 Distribution Information
Please be aware that, due to copyright considerations, updates to documentation are sent only via
the UMASSD ACNL/ DOE-COMMON / LBNL-ESnet’s mailing list(s).
1.7 Questions and Suggestions
Please e-mail your questions or suggestions about this document to bharath.hr@umassd.edu or
vvokkarane@umassd.edu or cpguok@es.net

2. Introduction
2.1 Scope and Purpose
Current e-science applications have high bandwidth, deadline driven and volume constrained
requirements. To be able to transport these large and demanding payloads in the data plane,
the control plane algorithms have to be efficient in the way they process the requests and
allocate resources for them on the network. Succinctly put today’s resource intensive e-
science applications require the best quality of service from the network while abiding by the
Service Level Agreement (SLA) etched before. These requirements have become all the more
relevant as in the next generation networks, support for advanced multi-layer and multi-
domain control plane capabilities providing differentiated services to user demands are
expected. In this context the Network Scheduler (NS) / Network Resource Broker (NRB) are
expected to provide efficient resource allocation to the two broad classification of dynamic
network traffic types namely, Immediate reservation (IR) and Advance reservation (AR). For
IR requests as the name suggests, resources are required instantaneously and is provisioned
by the NS if available or blocked otherwise. For AR requests as the name suggests, resources
are required at a future time and is reserved by the NS if feasible or blocked otherwise. It has
been observed that IR has higher blocking probability when compared to AR as the latter
brings to the table flexible resource provisioning mechanisms given its nature of booking
resources ahead of time ~cite{LiCh02-toc}. AR request types are especially applicable to
grid and cloud applications ~cite{CoFaSt11-ton}~cite{TaNaTaKuTa11-cloudcom}. To
support such varied services an on-demand advance reservation request provisioning system
is needed.
An example of such an advance reservation system is the On-Demand Secure Circuits and
Advance Reservation System (OSCARS), which provides multi-domain, high-bandwidth
virtual circuits that guarantee end-to-end network data transfer performance for large scale
science applications ~cite{GuRo08-oscars}. OSCARS is currently deployed on the U.S
Department of Energy’s nation-wide Energy Sciences network (ESnet) ~cite{esnet}.
OSCARS is an open source AR provisioning software and is the most widely adopted inter-
domain dynamic circuit services application within the global research and networking
community~cite{esnetoscars}. OSCARS facilitates the ability to engineer, manage and
automate the network according to user-specified requirements. The wide range of large scale
science applications supported today by OSCARS includes high energy physics experiments
conducted at particle physics labs using the Large Hadron Collider (LHC) ~cite{lhc},
computational astrophysics experiments on the OptiPortal~cite{optiportal}, biological and
environmental research, genomics, climate research conducted by the earth sciences grid
applications. Currently OSCARS virtual circuits carry fifty percent of ESnet’s annual 60
petabytes of traffic. To provision for more requests without blocking and to provide large
scale applications with higher bandwidth (better service) the DOE’s ESnet is scaling up its
network from 10 Gbps to 100 Gbps network. To scale up, is a network design level decision
and comes with a huge cost. As the network traffic and data generated by these large scale
applications is always exploding exponentially, scaling up the network might not always be
possible. Thus further investigation on the problems faced by such a network and
implementation of efficient control plane mechanisms to better provision AR requests
successfully is needed. Some of the core issues currently faced by large scale science
applications supporting networks are as presented below:

As the network demand increases the probability of requests being rejected also increases.
This leads to user re-attempts with possibly modified user constraints at these failed
reservation requests causing wastage of network bandwidth and additional processing
overhead. The time, bandwidth overhead and resource lock-in period in the control plane for
processing these re-attempts at reservation substantially increases, especially for multi-
domain reservations with larger inter-domain hops. Furthermore this may lead to starvation
of queued requests which have shorter book-ahead times, eventually causing new advance
reservation requests to be blocked. This also leads to blind probing the network which
increases the probability of blocking new requests as the bandwidth and time in the network
will be taken up by the reservation workflow control packets. This blocking could have been
avoided if there were no re-attempts at failed reservation requests and blind probing.
In this work, we propose a solution that provides OSCARS a new perspective with an offline
inter-domain based messaging protocol based reservation workflow approach called What-IF
for negotiating network resources for provisioning of advance reservation requests more
efficiently. This feature allows the user to indirectly query a set of customizable What-if
based Path Computation Elements (PCE's) independently or in chains according to the multi-
constrained requirements specified by the user, which after suitable processing returns a set
of suggestive reservation solutions. These returned solutions are optimal with respect to the
weighted constraints specified by the user. The returned solutions are then ranked on the
basis of the balancing factors of the multi-constraints involved in determining the candidate
solutions and provide a way to help the user to choose the best solution amongst viable
solutions and best match the user constraints.
2.2 Abstract
Today’s large scale science applications present extensive, resource intensive demands to the
network. To cater to these demands, the network must be able to support voluminous data
transfer with guaranteed quality of service. This requires an intelligent centralized/distributed
network provisioning software to provision network resources across multiple layers and
multiple domains efficiently. In this paper we discuss and investigate the problems faced by
one such widely used network provisioning software called OSCARS. OSCARS (On-
demand Secure Circuits and Advance Reservation System) is known to provide multi-
domain, high bandwidth virtual circuits that guarantee end to end network data transfer
performance for large scale science applications. In this work we propose an offline inter
domain messaging protocol implementation for OSCARS called What-IF to significantly
reduce the bandwidth and processing overheads in the control plane for addressing re-
attempts at failed reservations. The proposed solution enables the user to query for the best
solution available to them at a future time without actually committing to reserve. The
proposed solution fetches all the candidate reservation solutions based on the user constraints
and ranks them based on the SLA the user is entitled to. The proposed solution thereby
reduces blocking, user effort and prevents blind probing of the network to best match the user
constraints. The proposed implementation performs parallel computations of candidate
reservation solutions which lead to faster response time for the user and aids for quicker
decision making.

2.3 Definitions and Abbreviations
Term/Abbreviation Definition
What-IF What-IF driven multi constrained OSCARS solution
OSCARS On Demand Secure Circuits and Advance Reservation System
SLA Service level agreement
PCE Path Computation Element
What-IF Only Workflow meant for performing What-IF Analysis on reservation
solution sets
What-IF On Failure Workflow mean for handling PCE errors and returning alternative
solutions
What-IF On Either
Success or Failure
Workflow meant for returning candidate reservation solutions.

3. Assumptions and Risks
• The solution approach elaborated in this document is based on availability of source code of
OSCARS 0.6 at https://oscars.es.net/repos/oscars/trunk/
• The What-IF features are designed considering OSCARS 0.6 as the base.

4. Background on OSCARS
OSCARS aims at exploring composable services and configuring highly modular, atomic network
services on-demand via SOAP based web services. OSCARS is composed of several modules whose
tasks include authorization, resource management, path computation, and inter-domain control
management. Fig.~ref{fig:oscars_modules} shows the relationship between the different OSCARS
modules. The core of the OSCARS architecture is comprised of the Coordinator and the PCE
framework. The Coordinator essentially handles the entire reservation workflow by managing the
control flow between different modules. The PCE framework is responsible for identifying and
computing the virtual circuit for a given AR, which is in-turn stored in the Resource Manager. The
Resource Manager then spools for reservations which are due to be active in the next time interval
and triggers the technology-specific path setup module to rig up the circuit for each such pending AR
request.
OSCARS also supports the inherently multi-domain environment of large-scale science by allowing
inter-operation with similar services in other network domains. In this context, OSCARS is also an
IDC(Inter-Domain Controller). DICE (Dante, Internet2, Canarie, ESnet) consortium~cite{dice},
standardized the IDC protocols to set up end-to-end circuits across multiple domains with diverse
circuit signaling protocols. These domains exchange topology information containing at the very
least, the potential virtual circuit (VC) ingress and egress points. The VC setup request (via IDC
protocol) is initiated at one end of the circuit and passed from domain to domain as the VC
segments are authorized and reserved.
For inter-domain AR requests (requests spanning multiple domains managed by different instances
of OSCARS), OSCARS uses a non-RSVP-style signaling across domain boundaries to signal the circuit
setup. The solution proposed by OSCARS to accomplish the multi-domain circuit setup is two-fold.
Firstly, explicit agreement/registration between IDCs managing each domain are established so that
they are mutually aware of each other's controllers, given the need to contact a particular domain as
part of circuit setup for an inter-domain request. Secondly, the IDCs communicate using the OSCARS
IDC protocol in accordance with local-domain policy along with available resources, which
determines the setup of the inter-domain AR request. These inter-domain circuits are terminated at
the domain boundary. Subsequently, a separate control plane service is used to stitch the circuits
together into an end-to-end path. Interestingly, the OSCARS IDC has successfully interoperated with
several other IDCs to set up end-to-end path, cross-domain circuits.
OSCARS 0.6 currently supports the setup of unicast virtual circuits. As shown in
Fig.~ref{fig:oscars_modules} the PCE framework is responsible for computation of the path from a
specific source to a specific destination based on the user constraints provided like bandwidth, start
and end date-time, suggested vlan etc. The PCE framework is highly modular and language neutral
such that independent vendors of OSCARS can implement their own custom PCEs in a language of
their choice, in accordance with their business requirements. Furthermore the PCEs can be deployed
at runtime, thus allowing Hot Plug and Play (PnP) into a live system. This is achieved by adhering to
the SOAP based API signatures along with the security related parameters, as well as having proxies

which interface between the coordinator and the PCE modules to ensure loose coupling. Further
there are two basic types of proxies in this context: namely, Aggregator proxy and PCE proxy. The
latter is used for user constraint specific computation of path and the former is used for aggregating
the results from one or more chain of PCE proxies and returning the unified result to the
coordinator.
The PCE framework available in OSCARS 0.6 is as shown in
Fig.~ref{fig:oscars_default_pce_framework}. The coordinator’s PCE Runtime builds a dynamic proxy
interface tree based on a dynamic PCE configuration meta-descriptor file which specifies the various
PCEs to be included with their contact endpoints and their relationships with each other. Now the
dynamic proxy interface tree builds the PCE stack according to the semantics specified by PCE meta-
descriptor. The PCE stack built by default is as shown by the Flexible PCE Stack block in the
Fig.~ref{fig:oscars_default_pce_framework}.
Further, when the Aggregator proxy is instantiated, it creates and processes its child PCE proxies
before processing itself. Each PCE proxy can have one or more child PCE proxies. These PCE proxies
use the information provided by the PCE meta- descriptor and contact their respective PCEs services
running at some endpoint on a given host. A tag is assigned to each of the branch stemming from
the aggregator proxy to identify the resulting path from the PCE stack. In this example as there is
only one linear branch to the aggregator proxy a Tag 1 has been associated with it to identify the
result set resulting from its child PCE proxies. Before we discuss the PCE’s in detail we need to
discuss the data structure of the data passed between them, called PCE Data which is as shown in
the Fig.~ref{fig:oscars_pce_data}. User constraints field contains the constraints passed by the end
Connectivity PCE
Bandwidth PCE
Vlan PCE
Dijkstra PCE
Aggregator Proxy
PCE Proxy
PCE Proxy
PCE Proxy
PCE Proxy
PCE
Data
PCE
Data
PCE
Data
Null Aggregator
PCE
Data
for
Tag1
Tag 1
Tag 1
Tag 1
Tag 1
Coordinator
Proxy Interface Flexible PCE Stack
PCE Runtime
Action
PCE
Framework

user. Reserved Constraints field contains the partial or the end to end path along with other feasible
constraints like bandwidth, start time, end time and vlan leading towards a successful reservation.
Optional constraints field may optionally contain user specific or business logic specific constraints or
extra control plane information. Topology Content field is used to retrieve or store thus far pruned
topologies while performing path computation.
Next we discuss the PCE stack where in each PCE module is an independent single instance service
by itself. Connectivity PCE builds a domain stack for reaching from source to destination and fetches
the topologies of the domains involved from the TopoBridge module which contacts perfSonar
~/cite{perfsonar}, an infrastructure for network performance monitoring which provides a host of
services including Topology and Lookup services. The topology information retrieved from perfsonar
is stored in the topology content field in the PCEData. The same PCEdata is passed onto the next PCE
which is the Bandwidth PCE. Bandwidth PCE is responsible for pruning of the topology for the
requested bandwidth for the entire duration of the request along the reserved path if any. This
bandwidth pruned PCEData is passed into VLAN PCE. VLAN PCE is responsible for pruning of the
topology for VLAN availability along with any suggested vlan range specified by the user. If OSCARS
is functioning in the Layer 2.5 MPLS mode then only the ingress and the egress VLANs are considered
for pruning. This VLAN pruned PCEData is passed onto the Dijkstra PCE. Dijkstra PCE is responsible
for computing the shortest path between the source and destination with the available pruned
topology on hand. Finally the shortest partial or complete path is returned to the Null Aggregator.
The null aggregator checks the PCEMessage accompanied with the PCEData for the number of
required tags and identifies it with the tag label. Once the required tags containing the required
results are received the first resulting aggregated path is returned to the PCE Runtime Action for
further inter-domain processing if any before persisting the reservation to the resource manager
which indicates a successful reservation. Note, if at any point in time during the path computation in
any of the PCEs, if the constraint assertions are not satisfied then an exception is raised and the user
is notified about the error.
Multi-Domain IDC Reservation Protocol for OSCARS
The OSCARS multi-domain IDC reservation protocol for an unicast AR request is shown in
Fig.~ref{fig:unicast-oscars-multidomain}. For the sake of simplicity, consider an IDC as a single
OSCARS instance. A multi-domain unicast request is first submitted to the local IDC (source IDC is IDC
1 in this case). In this example workflow, the anycast request specifies Node X in Domain 1 which is
found locally in the network managed by IDC 1. The request also specifies Node Y as the destination,
which is remote to IDC 1. Now the Coordinator in IDC 1 initializes the PCE workflow. The
User
Constraints
Optional
Constraints
Topology
Content
PCE
Data
Reserved
Constraints

ConnectivityPCE loads all the partially (ingress and egress only) or fully visible (sister network
domains share entire topology) topologies as a topology stack to reach from the source to the
destination domain. In this example Domain 2 and Domain 3 are loaded. The BandwidthPCE and
VlanPCE then prune all the local nodes, ports, links in the topology stack which do not fit the user's
constraints of bandwidth and VLAN. This pruned topology stack is then fed into the DijkstraPCE,
which finds the best local path to the egress node for the destination of the local domain and returns
this path to the local Coordinator. Now the local Coordinator within IDC 1 determines that the
request is inter-domain, flags the unicast request to be in the CREATE phase and forwards this
request by loading the profile of the next inter-domain hop in the path which helps to communicate
suitably over the inter-domain network with the next IDC responsible for the inter-domain hop. In
Fig.~ref{fig:unicast-oscars-multidomain}, IDC 1 forwards the inter-domain unicast request to IDC 2.
Now, IDC 2 performs actions similar to IDC 1. If a local path is found feasible, IDC 2 then forwards
this request to IDC 3 which manages the destination domain, Domain 3. Now, IDC 3 performs actions
similar to IDC 2 in computing the best path to the destination and returns the path which has the
shortest number of hops back to the Coordinator. Upon successful receipt of the path, the
Coordinator for IDC 3 then locally saves the path in its local database as reserved and changes the
unicast request phase to COMMIT and forwards the request back to the sender of the request, IDC
2. IDC 2 sees the phase of the request to be COMMIT, and thus it merges the local path with the
global path and saves this merged path as the reserved path in the local database. IDC 2 again
forwards the updated request to the original sender, IDC 1, which after merging the local and global
paths, persists the full end-to-end path in its local database. Subsequently, IDC 1 changes the
request status to RESERVED to indicate that the end-to-end path is stitched and forwards this end to
end reserved path to IDC 2. IDC 2 now overwrites the entire end-to-end unicast path again into its
local database and forwards it to IDC 3 which performs similar action of persisting the end-to-end
reserved path to its local database. IDC 3 flags the reservation as completed by setting the unicast
request status to RESERVATION-COMPLETE phase, which is then recursively transmitted back to IDC
1 (the original sender). The user is notified that the unicast AR request has been successfully
reserved. If the request cannot be provisioned locally in the CREATE phase by any of the domains in
the path, then the user is notified that the reservation has failed and the request is blocked.

5. Problem Definition
As the network demand increases the probability of requests being rejected also increases. As
far as OSCARS is concerned, this leads to user re-attempts with possibly modified user
constraints at these failed reservation requests causing wastage of network bandwidth and
additional processing overhead. The time, bandwidth overhead and resource lock-in period in
the control plane for processing these re-attempts at reservation substantially increases,
especially for multi-domain reservations with larger inter-domain hops. Furthermore this may
lead to starvation of queued requests which have shorter book-ahead times, eventually
causing new advance reservation requests to be blocked. This also leads to blind probing the
network which increases the probability of blocking new requests as the bandwidth and time
in the network will be taken up by the reservation workflow control packets.
This blocking could have been avoided if there were no re-attempts at failed reservation
requests and blind probing. Therefore, in this work we propose a solution for error handling
when reservations fail and also provide OSCARS a new perspective with an offline inter-
domain based reservation protocol based reservation workflow approach called What-IF for
negotiating network resources for provisioning of advance reservation requests more
efficiently. What-IF aims to significantly reduce the bandwidth and processing overheads in
the control plane for addressing re-attempts at failed reservations. What-IF also aims to
enable the user to query for the best solution available to them at a future time without
actually committing to reserve. The proposed solution fetches all the candidate reservation
solutions based on the user constraints and ranks them based on the SLA the user is entitled
to. QoS (Quality of Service) can be provided by providing appropriate feasible candidate
solutions to the users based on the SLA and type of application using OSCARS.
In this section we formally define the problem. We consider the dynamic traffic model
whereuser requests arrive according to some stochastic process. We assume that the user
request arrives either at a centralized scheduler(Meta Scheduler Messaging Model - A
scheduler of schedulers) or a distributed scheduler(Daisy Chained Scheduler Messaging
Model) and processed accordingly as discussed in ~cite{OSCARS-IDC-0.6-Protocol-Spec}.
Irrespective of the type of messaging model chosen by the inter-domain scheduler
architecture, we assume, that we have a set of network schedulers, $Z
={NS_{1},NS_{2},ldots}$ wherein each $NS_{i}$ is a network scheduler that manages a
unique, network domain. Under reasonable assumptions we interchangaebly use network
scheduler as an Inter-Domain controller(IDC) assuming each network scheduler is capable
enough to manage multi-domain/inter-domain requests. Each IDC knows the existence of the
directly connected neighbouring peer IDC's and networks managed by each of them. We
define each such network monitored by its corresponding IDC as follows:
A network $G$ is defined as, $G =(V, E, H)$, where $V$ is the set of nodes,$E$ is the set of
edges. We consider a time-slotted network with fixed-size time slots.
We define horizon ($H$) as the number of future time slots for which the state information is
maintained in the network scheduler for allocation of network resources. The horizon limits
how large the holding times or duration of the requests can be. Each network scheduler in the
set $Z$ maintains a local state information, which is updated for every newrequest provided
that the request's path has an incoming or an outgoing edge

belonging to the domain that the network scheduler manages. The state information consists
of local or global edges if there are any that are used in each timeslot. It canbe thought of as a
two-dimensional list $U[E,H]$. The What-IF user request, $R_{WhatIF}$, can be defined as
$(s,d,alpha,eta,chi,beta,tau,nu,delta,omega,kappa,sigma,psi,varphi,phi,epsilon,iota)
$ where $s in V$ is the source node and $d in V$ is the destination node,$alpha$ is the start
time, $eta$ is the end time which can be interchangaebly used for duration of the request
defined as $eta - alpha + 1$, $chi$ is the bandwidth desired, $beta$ is the bandwidth
weight for denoting bandwidth centerdeness of the request, $tau$ is the time weight for
denoting time centerdeness of the request, $nu$ indicates that the request is volume based,
$delta$ is the deadline constraint for the request, $omega$ indicates the type of workflow
chosen by the user according to the requirement, $kappa$ indicates the mode of
interpretation of QoS parameters (whether to use QoS parameter values supplied, manual
mode or deduce QoS parameter values based on the QoS parameters for centerdness and user
SLA, $sigma$ is the minimum bandwidth required for the request, $psi$ is the maximum
bandwidth if possible for the request,$varphi$ is the earliest start time, $phi$ is the latest
start time ,$epsilon$ is the earliest end time for the request, $iota$ is the latest end time for
the request.
When a dynamic What-IF request arrives at the scheduler, it must find and return suitable
candidate reservation solutions by checking the available network resources depending upon
the various QoS parameters that are discussed next. The scheduler must return a vector of
textit{candidate reservation solutions}, $VC$ called as the textit{Viable Candidates}. Each
candidate reservation solution must find resources according to the request and the QoS
parameters, abiding by the SLA for the user and then return a vector of textit{segments},
$S$, called as the textit{schedule}. Thus a textit{candidate reservation solution} represents
a textit{schedule}. We define a textit{segment} as a channel(path) used to transfer data
between a specified start and end time. A segment can be defined as a three tuple, $(t, d, P)$,
where $t$ is the start time, $d$ is the duration of the segment and $P$ is the path used by the
segment. We assume that $t$ refers to a specific timeslot and $d$ is specified in number of
timeslots. The start time is inclusive, so the segment transmits data from $[t, t+d-1]$. In
continuous transmission of request, only a single segment lasting from $t$ to $t+d-1$ is
returned as part of the schedule and in a non-continuous transmission of request, the
scheduler returns several segments as part of the returned schedule. In this paper we consider
and discuss only continuous transmission of a request.
In the case of a traditional online network scheduler like OSCARS, the scheduler attempts to
generate an online schedule for provisioning a five tuple traditional request,
$R_{Traditional}$, defined as $(s,d,alpha,eta,chi)$ wherein the request parameters have
the same meaning as discussed before, for a What-IF request.
Now the traditional online network schedulers attempt to generate an online schedule for a
request $R_{Traditional}$, might be unoptimized if the schedule generation is successfull or
blocked if the schedule generation is unsuccessfull, causing unnecessary online processing
and time overheads due to blind probing of the network for more optimal schedules in case of
successfull reservation or due to re-attempts for a blocked reservation, respectively.
Thus instead of trying to generate an online schedule for provisioning a request, we propose
an offline generation of feasible, optimized schedules. An optimized schedule is an SLA

abiding schedule, that meets the user constraints and the QoS parameters as closely as
possible. The main difference between an online schedule generator and an offline schedule
generator is that, the former is committal and thereby allocates network resources to a
request, and the latter is non-committal and thereby doesn't allocate any network resources to
a request.
We will call our proposed solution as textit{What-IF}, since we are only interested in
fetching a set of optimized reservation schedules without actually committing to reserve any
of the schedules generated.

6. Design
To achieve the objectives as defined in the problem definition and the motivation sections,
we propose the design of the What-IF architecture as shown in Fig. Fig.~ref{fig:whatif-
architecture} along with the interaction with other modules of OSCARS.
The modules which are part of the core What-IF architecture are discussed below:
1. What-IF Engine: This is the workflow engine of the offline IDC messaging protocol.
In a nut shell it is responsible for processing inter-domain What-IF requests and
generating ranked candidate reservation solutions. The What-IF engine comprises of
four sub-modules which are as described below:
Query Engine – This sub-module is comprised of two components described below:
• Query generator and (Re) Optimizer : is responsible for generating optimized What-
IF queries based on the multi-constraints specified by the What-IF request and
processed by the QoS-SLA constraint processor sub-module.
• Query Result Processor: is responsible for processing and packing the successful
candidate reservation solutions based on the ranking performed by the What-IF KPI
Analyzer.
QoS-SLA Constraint Processor – is responsible for balancing the multi-constraint
equations based on the SLA and thus provides QoS by determining whether the user is
entitled to a particular service requested or not. An SLA or Service Level SLA can be simply
thought of as a set of 3 tuple <Resource, Permission, Constraint> RPC objects attached with
a User Role. Resource defines the application/module/entity/service that the permission and
constraint is being defined for. Permission defines the permitted actions/operations on the
resource. Constraint defines the properties, limits, longevity and scope of the permissions.
These RPC objects are stored and retrieved by the AuthZ module from and to the authz
database as shown in Fig.~ref{fig:whatif-architecture}.
What-IF KPI Analyzer: is responsible for ranking the candidate reservation solutions
based on the constraint centeredness for a What-IF request. KPI(Key Performance Indicator)
determines what is important to achieve the determined objectives in general. KPI in the
context of multi-constrained What-IF request identifies the subset of constraints which are
most important amongst the set of multi-constraints. Thus it analyzes the KPI by ranking the
candidate reservation solutions based on the key performance indicating subset of constraints
which are important to the user, according to the weights specified by the user on the multi-
constraints.

PCE Framework
Constraint based
Path computation
Query Engine
Customized
WBUI for
What-IF
Query
Generator +
(Re)Optimizer
Query Result
Processor
What-If-
Engine
Web
Services
What-IF KPI
Analyser
QoS-SLA
Constraint
Processor
Authn, Authz, RM
Reservation
Failure
Manager
What-IF Engine
Customized
What-IF IDC
API Tool Kit
(CLI/External
Interface)
PCE Service Profiler
Stores/Loads, desired PCE
Stack(Unicast, Anycast, …)
Resource Manager
Query, Store, List
operations with spooling
for reservations
Authn Authz
What-IFFrontEnd/ExternalInterface
Notification
Broker
Lookup

Reservation Failure Manager: is responsible for PCE error handling when a reservation
fails. The reservation failure handled by the failure handlers in the failure manager, handle
both the standard OSCARS unicast reservation request failure as well as What-IF query
related failures. This sub-module processes the failure in accordance with a set of well
defined, What-IF related standard PCE internal error codes. The failure handlers interact with
the Query Engine for optimization/re-optimization of What-IF queries.
2. What-IF Front End/ External Interface : This block in the Fig. ~ref{fig:whatif-
architecture} represents the customized OSCARS WBUI and API modules for supporting
What-IF features.
The WBUI or web user interface module can be used by human end users to interact
with the What-IF driven OSCARS to submit What-IF requests as well as regular
OSCARS reservation request. The IDC API module presents an external application
programming interface using which inter-domain What-IF requests can be submitted
by applications, automated batch scripts and end users alike.
3. PCE Service Profiler: This new module is responsible for loading the appropriate
PCE stack depending upon the type of request and service needed. For example for a
unicast request, the PCE Service profiler dynamically loads a unicast PCE stack and
for an Anycast request, the profiler dynamically loads an Anycast PCE stack.
4. PCE Framework: The revised PCE framework supports multiple instances of PCE’s
instead of PCE’s running as a single instance service. This is done to facilitate parallel
path computations for different optimized/re-optimized queries from different what-IF
requests. Also the error reporting capabilities have been augmented to support new
error handling mechanisms in the what-IF engine to take necessary steps and pursue
query re-optimizations to fetch successful candidate reservation solutions.
Features of What-IF
Our proposed offline inter-domain reservation protocol, What-IF offers three different
workflows flavors namely, What-IF On Failure, What-IF On either success or failure and
What-IF Only. Each of these workflows operate in two modes namely, manual mode and
auto mode. In Manual mode QoS semantics is derived directly from these constraint fields. In
auto mode, first the values of these constraint fields are automatically set by the What-IF
Engine depending upon the SLA and then the QoS semantics is derived from these constraint
fields. The manual mode represents support for fine grained control over the constraints (for
example: manual mode will be useful for a user/application attached with an engineer role)
whereas auto mode represents ease of use (for example: a novice user/application attached
with a scientist role) and possible coarse grained control over the constraints.
Before we discuss the above mentioned What-IF workflows in detail there are a few What-IF
related fields which apply to each of these workflows. Each of these fields individually and
/or collectively determine the QoS provided to user/application.

Bandwidth Weight and DTStampWeight – Fields representing Bandwidth centric and Time
centric application support designated by placing weights for bandwidth and time
respectively. By default both these fields are weighted equally at 0.5
Volume constraint and Deadline constraint – Fields representing support for constant
volume based applications and Deadline based applications support. By default these Boolean
fields are false.
MinBandwidthRange and MaxBandwidthRange – Fields representing support for fixed and
flexible bandwidth provisioning. By default MinBandwidthRange is set to the minimum
bandwidth granularity allowed by the network and MaxBandwidthRange is set to max
capacity supported by the network.
Earliest Start Time, Latest Start Time, Earliest End time, Latest End Time – Fields
representing support for Fixed and Flexible Date-Time. The earliest start time and Latest start
time fields represent the left window for a request to start and these two fields by value
default to Start Time which is part of the User Constraint. The earliest end time and latest end
time fields represent the right window for a request to end and these two fields by value
default to End Time which is part of the User Constraint. Also the semantics for achieving
various time related QoS are derived from these fields.
The offline What-IF IDC control plane protocol header differs from the regular OSCARS 0.6
IDC control plane protocol header in the Optional Constraints partition of the header. All the
What-IF related constraint fields and properties are packed in the optional constraints along
with any other non-What-IF constraint fields. The What-IF IDC control plane protocol header
is as shown in the Fig.~ref{fig: WhatIF-Offline-IDC-Control-Plane-Protocol-Header}.
The internals of the three What-IF workflows work are described in terms of the use-cases
they support:
1. What-IF on Failure workflow – This workflow is used to support users who would
want to choose amongst the various candidate reservation solutions deduced from the
What-IF QoS parameters in the event that their initial reservation request fails. In the
User Constraints
Optional
Constraints
What-IF IDC Control
plane Protocol Header
Reserved
Constraints
Bandwidth Start Time End Time Vlan
Auto Mode What-IF On Failure What-IF On Success or Failure What-IF Only
BandwidthWeight Date-Time Weight Volume based Deadline Based MinBandwidth
MaxBandwidth Earliest Start Time Latest Start Time Earliest End Time Latest End Time

event of failure of an OSCARS request caused due to error in constraint based path
computation (error thrown from the PCE Stack), the What-IF on Failure workflow is
triggered. This workflow is composed of the following action items in that order: (1)
Failure Management (2) Query Re-Optimization (3) QoS-SLA constraint processing
(4) PCE Profiling (5) Constrained based path computation via the PCE Stack (6)
Query Result processing (7) What-IF KPI Analysis. The workflow is repeated until
the entire candidate reservation solution space for the current What-IF QoS
parameters are completely explored in accordance with the user’s SLA. Also this
workflow uses the same GRI(Global reservation request identifier) which was used
for the initial failed online reservation request.
We will discuss only the failure management action item in detail over here as we
have already discussed the rest of the action items as What-IF core modules in the
previous section.
The failure management action item is carried out by the reservation failure manager
module shown in Fig.~ref{fig:whatif-architecture}. To make this failure management
possible we have introduced an internal error reporting format in the PCE framework, an
example of which is as shown in the Fig.~ref{fig:whatif-error-report-format}. The elements
of this error message tell the error handler in the reservation failure manager the following:
Error Item element: non-null value signifies there is atleast a single error item which caused
this failure.
Error Source element: denotes the PCE which signaled the failure.
Error Description element: gives a brief description on the error which can be used to brief
the user that a reservation has failed.
Error Internal Code element: acts as an index to a hash table which maps error codes in
hexadecimal to their respective error handlers.
Error Guard element: acts as a guard condition which prevents the error from recurring by
using it as one of the parameters during query re-optimization.

2. What-IF on either Success or Failure Workflow – This workflow is used to support
users who would want to choose amongst the various candidate reservation solutions
deduced from the What-IF QoS parameters in the event that their initial reservation
request either fails or succeeds. In the event of either a successful or failed OSCARS
reservation request, this workflow is triggered. If the workflow was triggered due to
the failure of a reservation request then the same set of action items is followed as that
of the action items of What-IF on Failure in that order. But, if the workflow is
triggered due to the success of a reservation request then, it performs the following
action items in that order (1) Query (Re)Optimization (2) QoS-SLA constraint
processing (3) PCE Profiling (4) Constrained based path computation via the PCE
Stack (5) Query Result processing (6) What-IF KPI Analysis. The workflow is
repeated until the entire candidate reservation solution space for the current What-IF
QoS parameters are completely explored in accordance with the user’s SLA. Also this
workflow uses the same GRI(Global reservation request identifier) which was used
for the initial online reservation request.
3. What-IF Only Workflow - This workflow is used to support exclusive/experienced
users or trusted applications to explore the various possible candidate reservation
solutions deducible from the What-IF QoS parameters without any trigger condition.
This workflow would be available to users/applications which have the necessary

What-IF only workflow privileges. In essence this workflow is for users who are truly
interested in performing a What-IF analysis on the entire network state across
domains with varied sets of QoS parameters yielding different sets of candidate
reservation solutions. The users can then then optionally choose to pick the best
candidate reservation solution for online reservation after comparing amongst varied
ranked sets of candidate reservation solutions across different QoS parameter
combinations. This workflow allows for instantaneous modifications to the What-IF
QoS determining parameters and fetches the ranked candidate reservation solutions by
performing the following set of action items in that order (1) GRI Generation (2)
Query (Re)Optimization (3) QoS-SLA constraint processing (4) PCE Profiling (5)
Constrained based path computation via the PCE Stack (6) Query Result processing
(7) What-IF KPI Analysis. The first action item, GRI generation in the workflow is
what differs from the other two workflows. GRI generation is a singleton/one-time
operation for a particular What-IF request irrespective of the repetitiveness of the
workflow. A GRI (Global Reservation Request Identifier) is used to identify a
particular reservation request across domains. For instantaneous changes to the What-
IF QoS parameters, all the action items are repeated as it is considered as a new What-
IF request. Action items (2) to (7) are repeated for any repetitions if required. The
workflow is repeated until the entire candidate reservation solution space for the
current What-IF QoS parameters are completely explored in accordance with the
user’s SLA.
What-IF Multi-Domain IDC Reservation Protocol for OSCARS
The What-IF Multi-Domain IDC reservation protocol for OSCARS is as shown in the
Fig.~ref{fig:whatif-multidomain-idc-protocol}. This is an offline/non-committal IDC
reservation protocol which implies that there will be no alterations made to the network
reservation state. For sake of simplicity, consider an IDC as a single instance of OSCARS.
We can observe from the Fig.~ref{fig:whatif-multidomain-idc-protocol}that a multi-domain
What-IF unicast request is first submitted to the local IDC (source IDC is IDC1). Also the
What-IF unicast request specifies amongst other parameters the unicast source which is node
X in Domain 1 (local domain) and unicast destination which is node Y in Domain 3. We can
also observe that the IDC1(which is the local IDC) manages Domain 1, IDC2 manages
Domain 2 and IDC3 manages Domain 3 respectively. Depending upon the What-IF workflow
flavor specified by the user (the eligibility to specify a particular workflow is again
determined by the user privileges as part of SLA) and the What-IF QoS parameters specified
as part of the control plane protocol header the action items are carried out for the specific
workflow resulting in locally ranked candidate reservation solutions. Now the What-IF result
processor sub-module after having received the locally ranked candidate reservation solutions
determines whether the What-IF reservation request is single domain or multi-domain and
processes accordingly. If the What-IF reservation request is single domain and a local request
(i.e., the source and destination are in the local domain) then the What-IF processing is
complete and the locally ranked candidate solutions are persisted with the local resource
manager and the persisted results returned to the user. If the What-IF reservation request is
determined to be multi-domain(i.e., the destination domain is not yet reached) then as and
when the number of candidate reservation solutions generated reach a particular custom
defined packing threshold say T, these locally ranked candidate reservation solutions are

packed into a batch of candidate reservation solutions by the What-IF query result processor
sub-module and flags the What-IF request to be in Query phase. The packed batch is then
marshaled as batched candidate reservation solutions into the optional constraints field of the
control plane protocol header. The control is then transferred to an asynchronous What-IF
request forwarder in the What-IF Runtime engine. The request forwarder then loads the
profile of the next inter-domain hop by contacting the lookup service offered by the lookup
module. This loaded profile helps to communicate suitably over the inter domain network
with the next IDC responsible for the inter-domain hop. In Fig.~ref{fig:whatif-multidomain-
idc-protocol} IDC1 forwards the inter-domain What-IF unicast request to IDC2. Now IDC2
after un-marshaling the batched candidate reservation solutions, simply checks whether the
constraints specified by the batched candidate reservation solutions are locally possible or
not. The candidate reservation solutions which are not possible locally are removed from the
set of batched what-IF reservation solutions. The result processor module checks if the
destination is local or not. If local it returns the pruned set of candidate reservation solutions
back to the source IDC (request originating domain). As the destination is not local for this
particular request it again performs marshaling of pruned set of candidate reservation
solutions into the optional constraints into the control plane protocol header. It subsequently
hands off the request asynchronously to a What-IF IDC forwarder which performs the lookup
to load the profile of the next inter-domain hop to communicates with it. In
Fig.~ref{fig:whatif-multidomain-idc-protocol} this is evident as IDC2 forwards What-IF
request to IDC3. IDC3 performs similar operations as that of IDC2 and checks for feasibility
of the batched candidate reservations solutions in its local domain. The result processor
module then determines that the destination specified in the What-IF request is indeed in the
current domain. Thus it performs a handoff to the forwarder to recursively send the pruned
batched candidate reservation solutions back to the source IDC in this case it is IDC 1
managing Domain 1. Then IDC1’s What-IF runtime engine hands off the un-marshaled
pruned reservation solutions to the What-IF result processor. The What-IF result processor
then calls the What-IF KPI analyzer which ranks the pruned batched candidate reservation
solutions. Subsequently the What-IF result processor sub-module persists the ranked results
to the resource manager and the persisted results are returned to user. Every batching and
forwarding action is parallel and asynchronous which improves the response time for the
user.

7. Implementation

8. Case Studies
There are numerous possibilities and scenarios for What-IF as it has the capability of
handling 3 different workflows (What-IF On Failure, What-If On Either Success Or Failure
and What IF Only), and each workflow has 2 modes (auto and manual mode) and each of
these 6 combinations have 2 constraints each (volume and deadline) which are applicable on
2 windowing mechanisms (Fixed & Flexible) each for bandwidth and Time which vary
according to the 2 weights (bandwidth and time weights) which are in turn used to rank the
candidate reservation solutions. The single domain and multi-domain scenario requests are
run over simulated networks of ESnet and Geant.

Scenario 1:
User tries constraints which is far exceeding the network capacity with all default settings.
(See SC-1-Fig-1)
OSCARS response : Request Failed. (See SC-1-Fig-2)
WhatIF Response : Candidate Solutions with best available bandwidth is displayed that the
user can use. (See SC-1-Fig-3). Note this result will be same irrespective of what the weights
for Bandwidth weight and DTStamp weight as we are working with all default values (Fixed
Request).
What-IF Workflow Used: Only on Failure. (See SC-1-Fig-1)
(SC-1-Fig-1)

(SC-1-Fig-2)
(SC-1-Fig-3)

Scenario 2:
User tries constraints which is far exceeding the network capacity with all default settings
except Volume Constraint is turned on. (See SC-2-Fig-1)
WhatIF Response : Candidate Solutions with best available bandwidth and earliest end time
possibly are displayed . (See SC-2-Fig-3) Note: same result for different bandwidth weight
and time weigthts as it is constant volume and fixed time.
(SC-2-Fig-1 above) & (SC-2-Fig-2 below)

(SC-2-Fig-3)
WhatIf solutions above are ranked by the best bandwidth and earliest ending time.
Also as the constant volume constraint is applied in this scenario, the requested bandwidth which is
100 Gbps is tried first, but as only 10 Gbps is available in the network/circuit leading from source to
destination, the best available bandwidth is used as the upper threshold for bandwidth and searches
bandwidth solutions which are available for a longer duration which matches the constant volume
requirement of 100 Gbps. So expansion of end time is used to cater to the constant volume
constraint requirement with limited available bandwidth as shown by SC-2-Fig-3 above.

Scenario 3:
User tries constraints which is same as in Scenario 2 except Constant Volume is not checked
and there is some flexibility in time. (See SC-3-Fig-1)
WhatIF Response : Candidate Solutions with best available bandwidth and earliest end time
possibly are displayed . (See SC-3-Fig-3)
(SC-3-Fig-1)

(SC-3-Fig-2 above & SC-3-Fig-3 below)

Scenario 4:
User tries constraints which is same as in Scenario 3 except Constant Volume constraint is
checked. (See SC-4-Fig-1)
OSCARS response: Request Failed. (Same as SC3-Fig2)
WhatIF Response: Candidate Solutions with best available bandwidth and earliest end time
possibly are displayed . (See SC-4-Fig-3-Part1 & Part2) Note: different set of results for
different bandwidth weight..
(SC-4-Fig-1)

(SC-4-Fig-3-Part-1 above) & (SC-4-Fig-3-Part-2 below)

Scenario 5:
Un-checked and Deadline Constraint is checked with bandwidth centeredness
( bandwidth Constraint > time constraint). (See SC-5-Fig-1)
WhatIF Response: Candidate Solutions are displayed in (See SC-5-Fig-3-Part1 & Part2)
Note: Solutions returned are deadline safe which means all the possible solutions are
explored before the mentioned latest end time but with higher ranking given to better
bandwidth & earlier starting and ending time. Importantly observe the last tuple in
SC-5-Fig-3-Part2 which has bandwidth = 8000 which proves the correct ranking.

(SC-5-Fig-1)

(SC-5-Fig-3-Part1 above) && (SC-5-Fig-3-Part2 below)

Scenario 6:
Un-checked and Deadline Constraint is checked with Time Centeredness
(Time Constraint > Bandwidth constraint). (See SC-6-Fig-1)
WhatIF Response: Candidate Solutions with best available bandwidth and earliest end time
possibly are displayed . (See SC-6-Fig-3-Part1 & Part2) Note: Solutions returned are
deadline safe which means all the possible solutions are explored before the mentioned latest
end time but with higher ranking given to earlier starting and ending time rather than
bandwidth. Also one can observe a more thorough scanning of the flexible time range to
make use of any slacks big enough to accommodate the requests in between reservations.

(See SC-6-Fig-1)
(SC-6-Fig-3-Part1 above) & (SC-6-Fig-3-Part2 below)

Scenario 7:
User tries constraints which is same as in Scenario 6 except both Constant Volume
constraint and Deadline Constraint is checked with Bandwidth Constraint > Time
constraint. (See SC-7-Fig-1)
WhatIF Response: Candidate Solutions with best available bandwidth and earliest start time
with strictly finishing by deadline (lastest end time) are displayed . (See SC-7-Fig-3-Part1 &
Part2) Note: Solutions returned are both Volume constrained and Deadline safe. Volume
constrained means there will be increased and decreased time spans as durations to match
the constant volume constraint when compared to the original duration. Deadline safe means
all the possible solutions are explored before the mentioned latest end time but with higher
ranking given to earlier starting and ending time rather than bandwidth.

(SC-7-Fig-1)

(SC-7-Fig-3-Part1 & SC-7-Fig-3-Part2 )
Scenario 8:

User tries constraints which is same as in Scenario 7 except both Constant Volume
constraint and Deadline Constraint is checked with Bandwidth Constraint < Time
constraint. (See SC-8-Fig-1)
Apart from this On Either Success or Failure workflow is used which is used to get the best
possible reservation solutions on either success or failure. In this particular scenario upon
success of the regular create reservation workflow the What-IF workflow is triggered to get
all the possible solutions except for the one which got reserved. This mode may be used for
multiple repeat of successful reservations or sequential reservation one after the other which
searches for the next best reservation solution given the constraints.
WhatIF Workflow used: On Either Success or Failure. (See SC-8-Fig-1)
(SC-8-Fig-1)

(SC-8-Fig-3-Part1 above) & (SC-8-Fig-3-Part2)
Scenario 9:

User tries use auto mode in the WhatIF only workflow which is specifically meant for
applications or novice users of OSCARS to fetch them the best reservation solution based on
minimum criteria like bandwidth and time. (See SC-9-Fig-1). In this particular scenario the
user is neither bandwidth centric nor time centric (bw_weight = time_weight).
What-IF Only mode is in general used for probing the network by users who are non-
committal yet and want to try various possibilities of constraints and try to get what suits
them the best. Also with auto mode they can allow the WhatIF auto workflow spend time for
scanning the whole spectrum based on a percentage of the basic constraint values specified
like bandwidth and time. Note: auto mode can be used in any other What-IF workflow as
well.
WhatIF Workflow used: WhatIF Only. (See SC-9-Fig-1)
(SC-9-Fig-1)

(SC-9-Fig-2-Part1) & (SC-8-Fig-2-Part2)

Scenario 10:
User tries to reserve bandwidth exceeding the network capacity across Multi-Domains.
Volume Constraint is applied and is bandwidth centric (See SC-10-Fig-1).
OSCARS response: Request Failed. (Same as SC10-Fig-2)
are displayed . (See SC-10-Fig-3) Note: Solutions returned is Volume constrained and
bandwidth centric.
WhatIF Workflow used: On Either Success or Failure. (See SC-10-Fig-1)

(SC-10-Fig-2 above) & (SC-10-Fig-3 below)

9. Conclusion
We propose and implement a multi-domain offline negotiation protocol for querying for the
best possible circuit by providing different candidate reservation solutions which best suits
the user SLA and deliver the promised QoS. We propose effective error Handling and
candidate reservation solutions prompting for blocked requests. Ranked viable reservation
solutions to support varied application needs. Closer solution matches to user/application
requirements as several viable reservation solutions are ranked. Users having the
necessary privileges for the What-IF Only workflow can probe for the best possible
reservation solutions for various ranges of multi-constraints and various layers. Re-
Attempts of reservation for failed reservation requests are avoided which reduces user
effort and avoids unnecessary overheads for request processing of such re-attempts at
reservation. Thus it lowers the probability of blocking AR requests significantly which have
small book-ahead times.

10. Future Work
We plan to augment the current offline what-IF protocol to a What-IF Inline multi-domain IDC
reservation protocol. Also we propose to support fine Grained layer based QoS support for the
What-IF protocol along with support for NML based topologies when the baseline OSCARS IDC
protocol supports it as part of the ARCHSTONE project ~/cite{archstone}.

11. References
[1] Guok, C.P.; Robertson, D.W.; Chaniotakis, E.; Thompson, M.R.; Johnston, W.; Tierney, B.; , "A User
Driven Dynamic Circuit Network Implementation," GLOBECOM Workshops, 2008 IEEE , vol., no.,
pp.1-5, Nov. 30 2008-Dec. 4 2008
[2] Cohen, R.; Fazlollahi, N.; Starobinski, D.; , "Throughput-Competitive Advance Reservation With
Bounded Path Dispersion," Networking, IEEE/ACM Transactions on , vol.19, no.5, pp.1265-1275, Oct.
2011
[3] Takefusa, A.; Nakada, H.; Takano, R.; Kudoh, T.; Tanaka, Y.; , "GridARS: A Grid Advanced Resource
Management System Framework for Intercloud," Cloud Computing Technology and Science
(CloudCom), 2011 IEEE Third International Conference on , vol., no., pp.705-710, Nov. 29 2011-Dec. 1
2011.
[4] http://www.es.net/services/virtual-circuits-oscars/
[5] http://public.web.cern.ch/public/en/lhc/lhc-en.html
[6] http://wiki.optiputer.net/optiportal/index.php/OptIPortal_Deployments
[7] http://www.perfsonar.net/
[8] http://archstone.east.isi.edu/twiki/bin/view/ARCHSTONE/WebHome
[9] https://wiki.internet2.edu/confluence/download/attachments/19074/IDC-Messaging-
draft.pdf
[10] http://www.es.net/assets/Uploads/20110504-Lessons-Learned-Atlanta.pdf
[11] Chin Guok; Robertson, D.; Thompson, M.; Lee, J.; Tierney, B.; Johnston, W.; , "Intra and
Interdomain Circuit Provisioning Using the OSCARS Reservation System," Broadband
Communications, Networks and Systems, 2006. BROADNETS 2006. 3rd International Conference on ,
vol., no., pp.1-8, 1-5 Oct. 2006
[12] http://www.faqs.org/rfcs/rfc4726.html
…

WhatIF-Driven-Multi-Constrained-OSCARS

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to WhatIF-Driven-Multi-Constrained-OSCARS

Similar to WhatIF-Driven-Multi-Constrained-OSCARS (20)

WhatIF-Driven-Multi-Constrained-OSCARS