Valentina Capaccio

1
Architectural Design for Performing Advance
Reservation

• Valentina Capaccio
• DataTAG WP2 Meeting
• CERN- 1/10/2002

2
Content

• Need for a policy-based and for a bandwidth
  brokerage architecture to perform Advance
  Reservation
• Relantionship with the Generic AAA
  Architecture and with DataGRID Co-Allocation
  Architecture
• Fundamental blocks of the Advance Reservation
  framework
• Details of the implementation
• Usage scenario in the DataTAG testbed
• Conclusions and Future Works

3
Need for a Policy-Based Network Architecture

• Problem
• to allocate Network Bandwidth to GRID
  applications either in advance or immediately
• Network connection is a more complex resource
  than other resources like CPU or storage. It
  usually spans multiple different domains
• Need of introducing adequate policies such as
  time of day/week, identification of users and
  applications, user traffic requirements,
  security considerations
• Need of introducing a Bandwidth Broker to manage
  the network resources

4
Fundamental Blocks

• The following figure schematizes the fundamental
  blocks of the architecture

5
Details

• Network Resource Manager
• It is possible to say that it is a type of
  Application Specific Module (ASM) as defined in
  RFC2903
• It is responsible to manage the resources and
  configure the service equipment to provide the
  authorized service
• It can interact with a AAA server
• Policy Repository
• It is a database containing all the available
  services and resources about which authorization
  decisions can be made and the policy rules to
  make them
• It contains users authorization credentials

6
Details (cont)

• Reservation Database
• It is a database containing information about
  the reservations already made
• It can contain a table that, for each user,
  stores
• requested bandwidth
• requested service
• start time
• end time
• duration
• other parameters.

7
Details (cont)

• Bandwidth Broker (BB)
• It is responsible to manage the network
  resources
• It receives a resource allocation request and
  configures the routers at the edges of its domain
  with the set of parameters for the PHB to be
  applied and the traffic conditioning mechanisms
  derived from the request
• It can contain
• SLS information
• configuration of routers
• service mappings/DSCP mappings
• network management information
• optionally, a routing table.

8
Relation to DataGRID

• The following figure describes the architecture
  defined in DataGRID for the Resource
  Co-Allocation

9
Relation to DataGRID (cont)

• It is possible to define a Resource Manager for
  each kind of resource to be managed
• In this sense the Resource Manager is equivalent
  to the Application Specific Module (ASM) in
  RFC2903
• In the case of Network, the Resource Manager
  will interact with a Bandwidth Broker
• Local Resource Managers should also publish
  their capability in the Information System
• The Reservation Database could be based on the
  Information System

10
Our task

• We could implement a Network Resource Manager
  (NRM) for each type of technology to be managed
• Three possible NRMs
• A Best-Effort
• A DiffServ
• A MPLS (future work).

11
DiffServ Network Resource Manager

• Assumption the routers along the requested
  path are DiffServ-capable
• It is necessary to introduce a Bandwidth Broker
  (BB) able to manage the network resources and to
  configure QoS on the edge routers via SNMP or
  other protocols
• The Bandwidth Broker periodically interrogates
  the Reservation Database to know the
  configuration requested by the user to set QoS
  parameters on routers

12
DiffServ NRM (cont)

• The user sends a reservation request to an
  entity responsible to perform Authorization and
  Authentication and will receive a username and a
  password
• Upon receiving the reservation request, the NRM
  will translate it into a request specific for the
  network, containing the requested bandwidth,
  start time, end time, duration and other
  parameters (delay, jitter, RTT, etc.)
• The request will be sent to the BB

13
DiffServ NRM (cont)

• The BB will interrogate the Reservation Database
  to check that the requested bandwidth doesnt
  exceed the maximum capacity of the link and that
  the parameters specified in the reservation
  request can be matched
• If it receives a positive answer, it will notify
  the NRM that the request was successful
• The user will be informed about the result of the
  request
• The user will send the data flow when it will be
  the right time

14
DiffServ NRM (cont)

• It is possible to specify in the reservation
  request the type of service the user wants and
  other parameters such as delay, RTT, jitter, etc.
• The type of service can be
• IP Premium (based on EF PHB)
• Assured Rate (based on AF PHB), but only for an
  experimental setup
• Less than Best-Effort.

15
Best-Effort NRM

• Assumption the network doesnt support any
  mechanisms of QoS and provide no guarantees.
• In this case, the only task that the Bandwidth
  Broker must perform is to verify whether the
  requested bandwidth is potentially available at
  that moment
• It realizes this task by checking network
  statistics

16
Use Case

• Consider the DataTAG testbed

STARLIGHT (Chicago)
17
Use Case (cont)

• In particular, the link from CERN to Chicago

18
Use Case (cont)

• - A user wants to transfer a file from
  CERN to Chicago at a rate of 150 Mbit/s from 3 pm
  to 4 pm on 24th September 2002
• The request will be authorized and authenticated
  and the user will be given a credential and a
  password
• After being subjected to a suitable policy, the
  request will reach the NRM that translates it
  into a request specific for the network and sends
  it to the BB
• The BB will interrogate the Reservation Database
  that , if all the checks are successful, updates
  its internal table and returns the answer to the
  BB and then to the NRM
• Finally, the user will be notified about the
  result of the reservation request and, if
  positive, will start the file transfer when it
  will be the right time

19
Conclusions and Future Works

• We have scratched an architectural design to
  perform the task of realizing Advance Reservation
  of network resources trying to comply both with
  the Generic AAA Architecture RFC2903 and with
  the DataGRID architecture,
• Further investigation is needed to understand
  how to implement the different blocks
  (interactions with the other functional blocks of
  the schema, choice of the programming language,
  use of GARA, environment, etc.),

20
Conclusions and Future Works (cont)

• Another possible solution considering the
  DataTAG testbed, is to setup a MPLS tunnel
  statically configured, and use DiffServ in
  addition to provide guarantees on bandwidth,
• We are investigating on this possibility and its
  related aspects and we consider this as a future
  work,
• Better understanding of the mechanisms of
  Authorization and Authentication in DataGRID is
  needed.