home > Components > BSS

Bandwidth Scheduling Subcomponent

Overview


The bandwidth scheduling component is the component that schedules a reservation. It parses the createReservation request, checks with the authorization component that the user has permission to make the reservation and then hands the requested path to the pathfinder component to determine the actual path through the network that will be used. It then checks to see if the required resources are available during the requested time interval. If so, it holds those resources and creates a Global Reservation Identifier (GRI) which will be used to identify the reservation across domains. If the end point of the path is not in the local domain, the BSS forwards the createReservation request to the next domain. The final domain in the path will create a token, derived from the GRI that can be used to signal the start of the reservation. If the reservation is able to sucessfully hold all the resources it needs across all the downstream domains, the local resources are scheduled and the reservation is entered into the BSS's reservation table.

Configuration


When the OSCARS server software is installed, the bss database tables must be created and populated. There are two sets of tables use by the scheduling component: those used to define reservations and those used to define topology. The topology tables must be populated with topology information before the OSCARS service can function. See TSS Component Notes for details on the topology tables.

Details


The createReservation message contains the path that is to be reserved, the amount of bandwidth to be reserved, the start time for the reservation, the duration, the burst limit, the purpose of the reservation and if coming from another domain, the global reservation identifier. See the OSCARS wsdl files for the precise type of each of these parameters. The input path definition is very flexible. It can simply be the source and destination host IP addresses, or can include ingress and egress points for each domain, or even the hops within domains. It is referred to as a unconfirmed loose hop path (ULP). At the end of the reservation process a confirmed loose hop (CLP) is returned to the user where it has been verified that an acutal path with the requested bandwidth can be made through these hops.  The way the hops are expressed depends on the layer (2 or 3) that is being specified and how the domains specify their topologies. See the NMWG topology schema for how we identify hops.

Once the reservation has been added to the reservations table in each of the transited domains, the circuit can be instantiated either by a scheduler procces that is triggered by the start time of the reservation or by a signal message from the user that the data flow is ready to start. The circuit setup (and subsequent  teardown) is handled  by the path realization component.

BSS Tables


There are two classes of tables used by the BSS: ones that describe the static topology of the local domain and some aspect of adjacent domains; and ones that describe reservations. The topology tables are described in TSS Component Notes. The reseverations table are describe  below.

Reservation specific tables

When a reservation is made an entry is created for it in the reservations table containing the following information:
	Integer id                 /** identifier field */
	Long startTime             /** persistant field, secs since 12am, Jan 1, 1970 UTC. */
	Long endTime               /** persistant field, secs since 12am, Jan 1, 1970 UTC */
	Long createdTime           /** persistant field, secs since 12am, Jan 1, 1970 UTC */
	Long bandwidth             /** persistant field */
	String login               /** persistant field: login name of the owner of the reservation */
	String payLoadSender       /** persistant field: login name of the originator of the request */
	String status              /** persistant field */
	String localStatus         /** persistant field */
	String description         /** nullable persistent field */
	String statusMessage       /** nullable persistent field */
	String globalReservationId /** nullable persistent field */
	Token token                /** nullable persistent field, may be used to authorize actions on reservation */<
	Map<String,Path> pathMap   /** persistant field: multiple paths for the reservation */
The paths table contains
	Integer id                 /** identifier field */
	String pathSetupMode       /** nullable persistent field: by timer or message signal */
	String pathType            /** REQUESTED, LOCAL, INTERDOMAIN */
	Integer priority           /** nullable persistent field */
	Domain nextDomain          /** nullable persistent field */
	String direction           /** nullable persistent field: FORWARD, REVERSE, BIDIRECTIONAL */
	String grouping            /** nullable persistent field */
	List<PathElems> pathElemId /** persistant field: index to first path element */
	Set<Layer2Data> layer2DataSet  /** nullable persistent field: index to layer2Data table */
	Set<Layer2Data> layer3DataIdSet /** nullable persistent field: index to layer3Data table */
	Set<MPLSData> mplsDataSet  /** nullable persistent field: index to mpls table  */
Explicit is true if the complete path was input; pathSetupMode specifies if the path will be instantiated automatically by the scheduler or by a signal from the user; if nextDomain is not null it is the next domain on the path, otherwise this is the terminal domain; PathElems is the list of all the hop on the path; either layer2Data or layer3Data is set and is the set of all the layer2 or layer2 elements for this path; if mpls is not null it is the set of mpls data elements for this path.

The pathElems table contains the following information for each hop on the path:

        Integer id          /** identifier field */
        Integer seqNum      /** persistant field ; sequence number of hop in path*/
        String urn          /** nullable persistent field: topologyId of element*/
        String userName     /** nullable persistent field */
        Link link           /** persistant field */
        Set<PathElemParam> pathElemParams /** all the PathElemParams for this element */
The layer2Data table contains the endpoints for a layer 2 reservation.
	Integer id             /** identifier field */
	String srcEndpoint     /** persistant field: URN topology id */
	String destEndpoint    /** persistant field: URN topology id */
and layer3Data table contains the endpoints for a layer 3 reservation.
	Integer id             /** identifier field */
	String srcHost         /** persistant field: dotted ip address */
	String destHost        /** persistant field: dotted ip address */
	Integer srcIpPort      /** nullable persistent field */
	Integer destIpPort     /** nullable persistent field */
	String protocol        /** nullable persistent field */ 
	String dscp            /** nullable persistent field */ 
MplsData table contains the burstLimit and lspClass associated with a Path.
 	Integer id            /** identifier field */
 	Long burstLimit       /** persistent field */
 	String lspClass       /** persistent field */ 
The tokens table contains an opaque identifier associated with each reservation that may be used to authorize actions on the reservation.
	Integer id            	/** identifier field */  
Integer reservationId /** persistant field */
String value /** persistant field */
idSequence table  a sequence of integers
	Integer id            	/** identifier field */ 
Used to assign the numeric part of the next GRI. Ensures that reservation ids will never be reused.