OSCARS Reservation Manager Functional Specification

Year 3 Update (DRAFT)

David Robertson, Chin Guok
ESnet

August 11, 2006

Objective

To develop and deploy a new service that can provide secure guaranteed bandwidth circuits within ESnet, and interoperate with reservation servers in other domains.

Introduction

OSCARS is an acronym for On-Demand Secure Circuits and Advance Reservation System. The focus of OSCARS is on facilitating bandwidth-intensive large scientific projects.

This document lists the requirements for the reservation manager (RM) component of OSCARS, updated for year 3 of the project. The requirements for the RM include setting up user accounts, setting up and tracking reservations and circuits, handling security and monitoring, and accounting. Items with a (*) after them are scheduled to be done this year. Items with a (?) may or may not be implemented.

Security is absolutely essential. The impact of an abuse could be very large. A DoS attack could prevent reservations from being processed. If the service is compromised, and thus the routers it has access to, the WAN may be disabled. Discussion of the security implications of requirements are postponed until the section on security.

Current requirements are largely taken from Chin Guok's Powerpoint presentations, the OSCARS project Web page, discussions with QoS/MPLS researchers at other DOE labs, Internet2, and GÉANT2, and from lessons learned thus far. If possible, there may be code sharing/reuse between these researchers and ESnet. Additional security requirements have been arrived at through discussion with researchers from the Distributed Systems Department of the Lawrence Berkeley National Laboratory.

Scope

This document covers the requirements for the RM and its clients. The requirements for the other major component of OSCARS, which handles the details of setting up the guaranteed bandwidth circuit using MPLS and RSVP, are listed in the OSCARS full proposal.

The RM must interoperate with other autonomous domains, to enable reservations where the end-to-end path may traverse several such domains. Interdomain reservation setup is discussed in the section on the network-to-network interface (NNI).

Specific design decisions are in a companion document, the OSCARS RM design specification.

Usability

Installation and use must be easy as possible. A standard, well-known mechanism to implement operations such as transport and server capability, for example Tomcat or SOAP, is to be preferred.

Modes of operation

The manager must be able to run in conjunction with current ESnet proprietary network management systems, as well as in a completely open source mode that other organizations can incorporate and use without additional licensing.

Reservation manager

The RM must have four subsystems:

  1. An authentication, authorization, and accounting subsystem (AAA),
  2. A bandwidth scheduler subsystem (BSS),
  3. A path setup subsystem (PSS), and
  4. A client interface (both an interactive interface and an API). The API is allowed only where noted.

AAA

The AAA must be used to authenticate and authorize all external requests, whether from the interactive interface, or the API. User account names must be globally unique.

In addition to the authentication and authorization process, which may be handled via library calls or client requests to other entities, the AAA handles a number of requests related to its management. These requests must only be accessible via test methods on the machine where the OSCARS server is running, and via the interactive interface. Parameters to these requests are listed in a section below.

  1. Request an OSCARS account (*).

  2. Login to OSCARS.

  3. The following requests must be handled from interactive clients that have successfully authenticated themselves, but require no additional authorization:

  4. List the details of the client's user profile.

  5. Modify the details of the client's user account profile.

  6. Request an allocation of bandwidth to use in making reservations (?).

  7. List the client's current allocation and usage (?).

  8. Logout from OSCARS.

  9. The following requests require that a user have the proper authorization:

  10. List all user accounts.

  11. Modify any user account.

  12. Add a user account.

  13. Delete a user account.

  14. List all OSCARS resources that may require authorizations to use (*).

  15. List all users' authorizations (*).

Requests related to the reservation of bandwidth are handled by the BSS, and are detailed in the next section.

BSS

The BSS must accept reservations, keep track of reservations, and maintain information necessary for future reservations:

The BSS must maintain policies associated with the scheduling and actual use of the network, detect any out-of-policy usage, and enforce the policies that are not handled by network management tools at the router level. Enforcement at the router level is not in the scope of this document, but information that may be necessary for such enforcement should be communicated to the PSS.

The BSS must handle the following client requests, whether via the API or the interactive interface, after authentication by the AAA:

  1. Schedule bandwidth reservation.

  2. List the client's reservations.

  3. List the details of a reservation the client has made.

  4. Cancel a reservation the client has made.

  5. Modify a reservation the client has made (*).

  6. The following requests require that a user have additional authorization(s):

  7. List all clients' reservations.

  8. List the details of any client's reservation.

  9. Cancel a reservation that any client has made.

  10. Modify a reservation that any client has made (*).

The following notifications must be made to clients, and must include the status of a reservation, the bandwidth allocated, and the QoS value:

PSS

The PSS must set up and tear down the on-demand circuits on the appropriate routers, based on a request by the BSS. To do so, it must change the router configuration on the start and end of the circuit.

Prior to circuit setup, the PSS must validate the route to use, and query routers along the path to check for "illegal" active circuits that could conflict with bandwidth reservation (*).

User interface

The user interface must provide means for making all requests listed in the sections on the AAA and BSS. Client requests generated by either interactive or automated means must use the same transport and message encoding (for example, SOAP) to communicate with the RM.

The API for automated reservations by user applications should utilize well-known mechanisms. A service description must be provided that will allow automated use of the API (AAA portion remains to be done).

The interactive interface must be simple and intuitive. It must prompt a user for a credential (username/password) before allowing any requests. It must in general operate within the trusted domain of the reservations manager.

After login, the interactive interface must provide entry forms to gather the information for requests, which may require an additional step of sending the information gathered as a message to the RM. Several requests may be combined on a single entry form.

For each mandatory and optional argument listed below, an entry form must have corresponding input fields and/or interactive controls. The entry form must not include input fields corresponding to arguments requiring special authorizations, if the client does not have the proper authorization. There must be an area on each entry form for status and error messages, which must be updated after each request.

All parameters must be validated on the client side before sending a request to the RM, to avoid unnecessary waiting time for the client if there is an error.

The following sections list the mandatory and optional arguments for each request, and the results returned, if any.

AAA requests

  1. Request by a client for an OSCARS account (*):

    The arguments are the same as those for the request to modify a user's account profile, listed below, except for the absence of the current password.

  2. Login to OSCARS:

    A login name and a credential are mandatory arguments. For the interactive interface, general OSCARS information should be readily available after login.

  3. List the client's user profile:

    A listing must be returned from this request that includes the user's unique id, first name, last name, organizational membership, personal description, primary and secondary email addresses, and primary and secondary phone numbers. The personal description, and secondary email and phone numbers are permitted to be empty.

  4. Modify the client's user profile:

    The user's current password is a mandatory argument. If the password is to be modified, arguments for the new password, listed twice, are mandatory. The user's first name, last name, organizational membership, primary email address, and primary phone number are mandatory arguments. The user's personal description, secondary email address, and secondary phone number are optional arguments.

  5. Request for an allocation to use in making reservations (?):

    TBD.

  6. List a client's current allocation and usage (?):

    TBD.

  7. Logout from OSCARS:

    In the interactive interface, the returned page must be the initial login page.

  8. The following requests require additional authorization:

  9. List all user accounts:

    The listing returned from the request must include each user's last name, first name, unique identifier, organizational membership, and current login status.

  10. Modify any user account:

    Same as request to modify a user's account profile, except that it can be done for any user's account.

  11. Add a user account:

    The arguments are the same as those for the request to modify a user's account profile, listed above, except for the absence of the current password.

  12. Delete a user account:

    The user's unique login is a mandatory argument.

  13. Edit/list all resources requiring authorizations (*):

    No arguments are necessary for this method.

  14. Edit/list all users' authorizations (*):

    No arguments are necessary for this method.

BSS requests

  1. Schedule bandwidth reservation:

    The reservation's source, destination, and requested bandwidth, and the purpose of the reservation are mandatory arguments. The reservation's start time, duration, source and destination ports, the protocol to use, the DSCP bit(s), the ingress and egress loopbacks, and the start time and duration are optional arguments. Default values must be used for the start time and duration if these arguments are empty.

    There must be an authorization that can be associated with a user, which is required for use of the following arguments: a traceroute listing, and flags for the setup of a persistent circuit and a bidirectional path.

    A disclaimer must be present on the interactive form indicating that if the transit path across ESnet has more than one ingress point, a full traceroute must be provided to ensure that the requested bandwidth along the actual path is available (*).

    Upon successful reservation setup, a listing must be returned with the reservation details.


  2. List the client's reservations:

    A listing of that client's current, finished, and cancelled reservations must be returned as a result of the request. Each item in the list must include the unique tag for the reservation, and the start time, end time, status, origin, and destination.

  3. Provide a search filter for the reservations list:

    A search filter method, or an interactive element, must be provided to narrow the reservations listed, for example by a specific date (*).

  4. List the details of a reservation the client has made:

    A listing of that reservation's details must be returned as a result of the request. This information must include the reservation's tag, the unique user login of the client that made the reservation, and the reservation's description, start time, end time, creation time, bandwidth, burst limit, status, source, destination, source port, destination port, protocol, DSCP bit(s), and class. If the request was from an authorized engineer, the information must also include the reservation's ingress router and loopback, egress router and loopback, and the routers in the path traversing ESnet.

  5. Cancel a reservation the client has made:

    An API method or interactive element must be provided to cancel a reservation identified by its reservation tag.

  6. Modify a reservation the client has made (*):

    An API method or interactive element must be provided to modify a reservation identified by its reservation tag. Modifiable arguments must include the reservation start and end time, and start and destination of the path.

  7. The following requests require additional authorization:

  8. List of all reservations:

    Same as the request for a client's reservation, except that the listing includes all reservations.

  9. List the details of any client's reservation:

    Same as the request for details of a client's reservation, except that the details can be of any client's reservation.

  10. Cancel a reservation that any client has made:

    Same as the request by a client for the cancellation of that client's reservation, except that any reservation from any client may be cancelled.

  11. Modify a reservation that any client has made (*):

    Same as the request by a client for the modification of that client's reservation, except that any reservation from any client may be modified.

NNI

The RM handles mostly intradomain functionality, but the interdomain aspect is crucial. The RM must determine if it is necessary to contact another domain to complete a request. If so, the RM must forward that request to the other domain, and handle the response (partially implemented).

To do so, there must be a standards-based interface for the RM's of different domains to communicate reservation requests. The RM of one domain must be able to interoperate with the RM's of other autonomous domains. High-bandwidth reservations will be needed, for example by LHC users, that traverse multiple domains. This requirement is at a higher level than the OSCARS specification, but it is a requirement of this specification that such an interface, when agreed upon, be implemented (*).

In addition, the AAA must have a mechanism for trusting other domains. It must forward necessary certificates or tokens to the AAA's of other domains to authenticate a client, and assertions to authorize a client to use a domain's RM. The AAA must interoperate with another trusted AAA, even if that system uses a different means of authentication or authorization.

Security

The administration of an end-to-end circuit must conform to security models of all entities along that path. In particular, stages leading towards the rollout of the service must follow the guidelines in the ESnet Security Plan (*).

OSCARS security mechanisms must be as easy to install and use as possible, as long as security is not compromised. A difficult to use system will not be used.

The machine(s) running the AAA, BSS, and PSS must be inside a protected network. The interactive interface must access these components via an identifier (for example a URL) that does not give the location of the server machine(s).

Access to OSCARS must require authentication and authorization. The AAA must authorize and authenticate all OSCARS requests from outside the protected network, and enforce these restrictions.

The AAA must generate usage records for all accesses, for auditing and accounting (?).

OSCARS accounts must be provided for administrators and the appropriate ESnet personnel, and only users with those accounts can have additional OSCARS authorizations. These authorizations, allowing different levels of access, must be maintained and enforced.

Automated messages to OSCARS must be signed and encrypted. Automated access does not necessarily require an OSCARS account, if it does not require the above-mentioned authorizations. A valid server certificate is sufficient if the request is coming from a reservations manager from another, trusted autonomous domain.

A secure means must be provided to store authentication information during login through the interactive client, to avoid that client having to authenticate for each subsequent access to OSCARS.

Request parameters must be validated on the server side, whether the client is the API or the interactive interface.

All components of the service must be monitored to ensure that they are not being abused. Notifications of sensitive operations such as reservation scheduling and LSP setup must be sent to the appropriate ESnet personnel, in addition to the client.