On Advance Reservation of Heterogeneous Network Paths - CiteSeerX

On Advance Reservation of Heterogeneous Network Paths † Chiara Curti1 , Tiziana Ferrari2 , Leon Gommans3 , Bas van Oudenaarde3 , Elisabetta Ronchieri2 , Francesco Giacomini2 , Cristina Vistoli2 1

CNX, Bologna Istituto Nazionale di Fisica Nucleare, CNAF 3 University of Amsterdam, Dept. of Computer Science 2

Abstract A new resource abstraction called Path is introduced in the framework of resource reservation for the optimization of user applications. A network Path is allocated in an on-demand fashion using a number of different signaling methods and is built using a chain of Path Elements that may belong to different administrative domains. Three different implementation technologies are presented: DiffServ, MPLS and the Light Path. We then discuss approaches to the integration of network Paths into the Grid. New and existing mechanisms, leading to novel ways to abstract a network Path, are explored in the area of resource management, advance reservation, authentication, authorization, accounting and coallocation. Finally we show how the support of policy-based co-allocation of path elements across multiple administrative domains can be implemented. Keywords : Advance reservation, Network resource management, AAA, MPLS, Differentiated Services, Lightpath, Grid Computing, GARA. 1

Introduction The problem of advance reservation of a generic resource affects a number of missioncritical applications. This paper deals with the problem of the reservation of network resources, which is relevant to users that require high network availability and performance predictability. The resource concept is the foundation of any advance reservation architecture. In this work we propose a network resource abstraction that we call Path. The Path is the resource that can be requested and/or used by an application in a number of ways. It can be static or dynamic, per-domain or end-to-end and can be used by a collection of streams or by a single flow. As for computing and storage, the network path we propose is supervised by a manager. The path can be set up dynamically to satisfy a given user request or statically. While in the former case the connection is dedicated, in the latter the †

This work was supported by the DataTAG and DataGrid projects, sponsored by the European Commission under grant IST-2001-32459 and IST-20000-25182 respectively, by the INFN project INFNGRID and the NetherLight project of SURFnet.

1

path is shared by multiple users and the manager can allot fractions of its resources to satisfy individual requests. Information about available network paths is retrieved from an Information Service, in compliance with the general Grid resource scheduling approach, and used during the resource matchmaking phase. In Section 2 we develop the details of our abstraction by providing three examples: the Light Path, the MPLS Path and the DiffServ Path. Users typically belong to a Virtual Organization (VO) [1]. VO members are recognized by resources based on their identity or role within a VO. In Section 3 we present how a network path is able to recognize VO members. The architecture develops the authentication and authorization component by including the use of the Virtual Organization Management Service (VOMS) and of the Generic AAA servers. Our approach can perform authentication and authorization in two alternative ways: either through a Generic AAA server or through the Globus Toolkit GRAM (Grid Resource Acquis ition and Management) [2] (i.e. by interfacing the Gatekeeper). The authentication and authorization approach to be adopted depends on the resource and is indicated by the Information Service. If a co-allocation is requested, i.e. multiple path elements belonging to different administrative domains have to be allotted in a coordinated fashion, the Information Service specifies the authentication and authorization approach of choice for each resource instance. In Section 5 we propose a layered approach to resource management, which is solved by enabling multiple types of resource management in each domain, depending on the variety of network technologies available to the user. We describe the implementation details of three types of manager: the Light Path Manager – which works at the physical layer –, the MPLS Manager – which can provide both Layer 2 and Layer 3 virtual private network (VPN) services –, and the DiffServ Manager at Layer 3 – which supports a customized set of Per-Domain Behaviors in a modular way. The dynamic set-up of a network path that crosses several transit domains is a networkspecific example of co-allocation. In this case, the end-to-end path is a chain of perdomain path elements and its configuration requires an intervention in each transit domain. Two solutions are described in Section 6: the central approach with a single resource manager, and the distributed approach, where each resource manager is only responsible of configuration in its specific domain and inter-domain communication protocol is implemented by the AAA servers. Finally, in Section 7 we describe a prototype that implements the novel concepts introduced in this paper, and we present our preliminary experimental results. Conclusions and future work are presented in Section 8. 2

The Path Advance reservation [4] is the mecha nism that allows the user to request the exclusive access in a future time span to a set of resources that satisfy the user requirements. An advance reservation request obtains the full specification of the resources needed through a set of resource-specific attributes, and it may supply run-time information at a later stage through a binding operation. The advance reservation can be modeled according to the web services approach adopted in the Open Grid Services Architecture [5], where the web services mechanisms are used to integrate heterogeneous Grid services. In this case it is called service

2

agreement, i.e. the service instance that is created as the result of a successful negotiation process between an agreement provider (the entity to which the reservation requests are addressed) and an agreement initiator (the client application). The negotiation terms are domain-specific, while the agreement terms specify the commitment made by the provider. In what follo ws we adopt the agreement initiator and provider terminology when applicable. The user who issues an advance reservation request, has to be authenticated and authorized on the basis of a set of policy rules. An authorized request can be satisfied only if a resource that satisfies the user’s requirements, is available in the specified time frame. The actual resource allocation is performed by a resource manager that hides the complexity of the resource-specific allocation tasks. During the reservation lifecycle the Information Service [6] offers vital information in a number of reservation phases. In particular, during the resource discovery it provides the list of resource instances that satisfy the user’s requirements, and for each instance, the information about its properties and their corresponding authentication/authorization server. In this section we first introduce three path examples: the DiffServ Path, the MPLS Label Switched Path and the Light Path, that lead to the more general Path definition, which is provided in Section 2.4. 2.1

The DiffServ Path

The DiffServ Path (DS Path) offers a homogeneous and seamless end-to-end packet treatment from the source to the destination domain according to the Differentiated Services architecture [7]. It provides unidirectional connectivity from the source to the destination domain, and it is shared by a community of sources located in the path headend domain. It is implemented as a concatenation of path elements, where each element only spans a given network domain. The Per-Domain Behavior [8] and the corresponding code-point (the DSCP) [9] used to identify packets belonging to the same aggregate, are transparent to the user. The forwarding behavior offered by a DiffServ path is described through a set of metrics – the agreement terms, such as the offered bandwidth, the one-way delay, the one-way delay variation etc –, that are negotiated between the user and the Path provider. The DiffServ Path can be set- up in a number of different ways. For example, each path element can be negotiated dynamically in each transit domain so that requests of users are aggregated as their path merges toward the destination and policing is enabled at each domain boundary, as described in [10]. Alternatively, a more static approach can be adopted when the path agreement terms vary infrequently. In this case the path can be manually configured in the transit domains according to the result of a separate service negotiation process conducted by the network providers. The user requests only need to be processed by the source domain agreement provider, which makes sure that at any point in time the amount of allocated resources does not exceed the maximum quantity offered by the static path. This is enforced by dynamically enabling a traffic policer [7] at the path ingress point for each authorized traffic flow. From a configuration point of view, the packets making use of a given DS Path are classified and assigned to a specific queue in each router along the path, where scheduling is needed to protect traffic from transient and/or persistent congestion. The

3

maximum bandwidth available for a static DS Path (when applicable) is reflected by the amount of bandwidth assigned to the corresponding queue. This capacity is agreed on a contractual basis with the transit ISPs along the path, and is defined according to the average estimated use of the pool of users in the source domain. 2.2

The MPLS Label Switched Path

MPLS creates a connection-oriented environment in a connectionless IP infrastructure based on Label Switched Paths (LSPs) [11]. The most important difference of the MPLS architecture over the native IP forwarding is its connection-oriented nature. MPLS can be used as supporting technology for a number of services, such as traffic engineering (TE), traffic tunneling, network Quality of Service and Layer 2 and Layer 3 VPNs. MPLS packet forwarding is based on labels, which are pre-pended in the form of a stack to the Layer 3 PDU. Labels can be pushed, swapped and popped by the Label Switch Routers (LSRs) and a label distribution protocol is used for the LSP set- up. LSPs can be characterized by optional properties such as the amount of bandwidth and the type of MPLS packet treatment, which can be coded in the three bit s of the experimental field of the MPLS shim header. The former parameter is used at set- up time in a traffic engineering-capable network to select LSP routes with an amount of available bandwidth sufficient to satisfy the LSP request. This attribute can also be used for subsequent LSP route optimizations. On the other hand, the Exp-inferred class of service can be used to identify the MPLS packets that belong to the same traffic aggregate and have to be forwarded according to the same behavior. In this way the LSP can be regarded as a DS Path. We think that MPLS is a suitable technology for network advance reservation for a number of reasons. First of all, MPLS provides a standard-based mechanism for automatic path configuration in single and multi-domain scenarios, where the path routing is defined either statically by the LSP head-end router or dynamically according to the layer 3 routing policies. Secondly, if traffic engineering is enabled, the path routing can be optimized in a single-domain scenario and dynamically tuned according to the bandwidth requested by the source application. 2.3

The Light Path

The Light Path is an established term [12] that indicates a Layer 1 technology dealing with physical connectivity provided by fibers. In particular, the Light Path is a Layer 1 connection spanning multiple administrative domains, which satisfies user request for an end-to-end QoS path. It consists of a concatenation of fiber connection and optical crossconnect devices. The Light Path is dedicated to the user. Light Paths are dynamically created and generally have shorter-term lives. The idea is to provide the users with a temporary high-bandwidth channel that is technically implemented as a Light Path. In combination with the AAA concepts these Light Paths could be based on dynamic trust relations for the construction of a dynamic network. Fore more information on the rationale behind the Light Path please see [13]. Each involved domain has its own Light Path manager, which takes care of this optical connectivity. A Light Path request is sent to the Light Path Manager that is responsible of the administrative domain the user belongs. For a given Light Path the manager also takes care of the required interaction with the other Light Path Managers in external 4

domains. Light Path Managers need to cooperate to provision an end-to-end Light Paths. The Light Path Manager acts as an authority responsible for the current and future intended state of the resources it supervises. For each user request of Light Path set- up or teardown, the Light Path Manager needs to check the intended state and/or update the state of its resources. 2.4

The Path resource

The Path is a network resource abstraction that is technology- independent. It defines the general network entity providing unidirectional connectivity between two network nodes. The network node can represent a single device (an end-system, router, switch etc.) or a network domain (for example, an Autonomous System, IP network, LAN etc.) as defined in [14]. A path can cross one or more administrative boundaries and it offers a specific packet treatment service that is described by a set of parameters providing information about its characteristics (for instance: bandwidth, packet loss and one-way delay). The Path defined in this paper extends the path definition from [14], as our path identifies both the sequence of physical links it is comprised of, and a set of attributes that describe not only the packet treatment it offers, but also more general properties such as the users authorized to use the resources it offers, the authentication and authoriza tion server it is associated to, and the network technology that implements the path. In the following we define three different types of Path: the Path Element, the perdomain Path and the end-to-end Path. The Path Element is the atomic unidirectional network entity providing connectivity between two nodes through a homogeneous control plane. A path element is controlled by a single resource manager and is implemented by a single network technology. The per-domain Path spans a single network domain and is a chain of one or more Path Elements; a given couple of network domains can be connected by zero, one or more per-domain paths. An end-to-end Path connects a source to a destination node, where the node can be a host or a leaf domain. In the former case the path is host-to-host and is dedicated to the traffic generated by a single end- node. In the latter case, it is collective and it can be shared by traffic flows generated by a community of hosts belonging to the same source domain. An end-to-end path crossing a single domain is also a per-domain path. In general, a path has to be viewed as a chain when the configuration and/or the path resource reservation require the activation of multiple managers, one for each constituent path element. The herein described path hierarchy is illustrated in Figure 1. Each Path is managed by a specific Network Resource Manager, which depends on the path type, and is associated to the authentication/authorization entity (a Gatekeeper instance or Generic AAA server) for the user access control. The path is described by attributes such as: the Path ID, the type, the corresponding Gatekeeper and/or the AAA server, the source/destination, and the set of path-specific parameters describing its properties, such as the maximum bandwidth. The source/destination can be a node or a domain.

5

Figure 1: relationship between path elements, per-domain paths and end-to-end paths Paths can be allocated statically or dynamically. In the former case, the path is manually configured by a network administrator and users can reserve a portion of its residual bandwidth. On the other hand, in the latter it’s the user who requests its configuration according to specific requirements. Static paths are typically needed to provide QoS support to a community of users, as they contribute to minimize the path set- up overhead. The capacity to be allocated to users and the available bandwidth [14] at a given point in time (i.e. the remaining amount of bandwidth not allotted yet) are examples of path resource attributes. 3

The Generic AAA components The fist operation to be performed when an agreement initiator generates a request, is the authentication and authorization of the issuer. Several fundamental entities are involved in an authorization decision: the user and the service provider, where the latter contains and authorizing entity (called the AAA server) and the service equipment itself [15]. The term service provider originates from RFC 2753 [16], which is the foundation of the work around the Generic AAA Architecture [17], and it introduces the role of a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP). The AAA architecture comp rises of a Rule Based Engine (RBE) and one or more Application Specific Modules (ASMs). The RBE fetches a corresponding driving policy out of a policy repository upon arrival of an AAA request message. This driving policy orchestrates the calling of one or more ASMs. A call to an ASM may be part of a policy condition or policy action [18]. ASMs may interface to devices, databases and applications such as resource managers, membership services or schedulers. Attrib utes sent as arguments to an ASM may only have semantic significance inside an ASM. The policy itself should not act on the attributes that are passed by it. This clearly leaves the logic handling part of a policy to the RBE and the semantic handling part of the policy to the underlying ASMs. This separation is the foundation of the principles of Generic AAA.

6

A VO can designate a specific user to act in a certain role if needed. If this is the case, the role is a fundamental parameter to be considered for policy decision, as in this way advance reservation can manage the distinction between reservation requestors and the users that may actually deploy the resource. The DataTAG advance reservation architecture uses the VOMS (Virtual Organization Membership Service), which issues a pseudo-certificate after a user has authenticated to it. The pseudo-certificate contains a role. After the authenticity of the certificate has been verified, the role is considered in a policy decision to determine if this user is authorized to make an advance reservation. If so, the advance reservation system can allot a certain timeslot and issue a signed credential that may or may not be bound to the identity of the requestor. The fact that the credential is bound may also be a policy decision. If not bound to the requestor, the requestor may decide to forward it to somebody else. Various usage scenarios of these credentials are possible. For example, the requestor may issue the credential to more then one party. If there is contention amongst the requesting parties for a particular network resource, the admission control system may block or queue the requests or may split the capacity amongst the parties or ignore them completely. As policy decisions may depend on the time an advance reservation credential is issued, a Generic AAA RBE engine with an appropriate ASM may drive a resource manager that is considered the source of authority for the network resource. This means that the application must send the Generic AAA RBE an AAA request message containing the VOMS pseudo-certificate and specific service data, such as the desired time frame, the source and destination address and the requested bandwidth. The Generic AAA RBE makes a policy decision based on this information. The Generic AAA RBE will call an ASM from a policy that contacts a resource manager depending on certain conditions, such as the user’s role, the time of the day etc. The resource manager will determine the availability of the resource and issue some reference to the reservation. A subsequent policy decision may decide to bind the reference to a specific or general user identity. Then, the policy may call one or more ASMs to put this into some certificate format, which gets signed. 4

The DataGrid user interface The DataGrid User Interface 1 is the communication means that can be used for agreement negotiation between the provider and the initiator. The User Interface specifies the negotiation terms, which are used by the provider to find the best resource match. Examples of negotiation terms are: Start Time, Duration, End Time, Resource Type, Reservation Type and the Resource-Specific Parameters. Additional terms can be included in order to help the system to find a better resource match. During the resource acquisition process we have two phases. Firstly, the resources compatible with the requirements and preferences specified in the request are discovered; and secondly, the allocation on the best- matched resource is performed. The first phase implies querying, either directly or indirectly, the resources to know their current status and availability. As the two-step allocation procedure is expected to frequently fail, the 1

The DataGrid User Interface described in this paragraph is a Workload Management System component.

7

system should be designed and implemented to be resilient to such failures. At this point, once the reservation has been granted it can be used to perform the job, for example a network reservation can be used to initiate a data transfer. A number of operation scan be performed on previously granted reservations: monitored, modified, bound etc. This framework is implemented using a Reservation Agent (RA), which accepts a generic reservation request from a user and maps it into a reservation on a specific resource. It is also responsible of the match making and it authorizes users to use a granted reservation for his job. In particular, the agent is characterized by the language used to express reservation requests, by the Reservation API needed to interact with it, and the state machine representing the status of a reservation during its lifetime. As it happens for any job, a reservation goes through a number of states during its lifetime: submitted, waiting, ready, running, done and aborted. For more information on the state machine, please refer to [19]. Finally, the User Interface is integrated with the VOMS. If the user has a VOMS proxy, then the User Interface can determine from the proxy the VO the user belongs to. UI node RA generic RA API specific for each resource type: ------------------------create, modify, cancel, status, bind, unbind, and commit

IS

compute/disk/ network_DiffServ /network_lsp/netw ork_light

Resource Manager nodes Figure 2: the DataGrid User Interface architecture 5

Layered resource management After the authentication/authorization phase the resource managers have to be invoked by the authentication and authorization engine. Each resource is handled by a single manager, but a given manger can control one or more resource ins tances. In the networkspecific case, we assume that different managers are running in a given domain, one for each network resource type allowed by the advance reservation system. In the multiple administrative domain scenarios more resource managers are needed to deal with the reservation of the path. The resource type information is fundamental for the selection of the resources that satisfy the user reservation request requirements specified by the user. In the Generic AAA approach the resource manager corresponds to the ASM, as specified in Section 3. 8

In order to cope with the heterogeneous nature of network resources, we have supported new resource-specific managers that perform different network configuration tasks according to the nature of the resource they are associated to. In our system we have identified three types of resource-specific managers according to a layered approach: the DiffServ Manager, the MPLS Manager and the Light Path Manager. 5.1

The Light Path Manager

The Light Path Manager is built using the Generic AAA [17] components, whose main function is the policy-based decision taking that is needed to drive the creation of a Light Path. As such, the decision process could be spread over multiple administrative domains. For each administrative domain a resource manager is needed for its Light Path Elements. Light Path Managers need to cooperate to provision an end-to-end Light Path [20]. The Light Path Manager has to be integrated with the advance reservation mechanisms to allow the provisioning of the Light Path at a future point in time. This can be achieved using an ASM interfacing to a resource manager API that implements the advance reservation function and that handles one ore more Light Path Elements. In this architecture, each resource manager acts as an authority responsible for the current and future intended state of the resource it supervises. For each user request of Light Path set-up or teardown, the Light Path Manager needs to check the intended state and/or update the state of its resources. The driving policy, which is fetched according the user request and executed in the RBE, will first check if the user is allowed to inspect or make changes to the resource. For this purpose, the credentials that are transported as part of the user request, may originate from a VO community server such as the VOMS. A policy may decide to check the credentials validity through a specific ASM. Part of the driving policy will subsequently call an ASM with an API to the resource manager. Through this API the ASM will determine the actual state of a resource or update the state of a resource based on request parame ters. A optical cross-connect ASM will ultimately do the actual provisioning of the optical devices. This approach is some what different in creating a MPLS Path or DiffServ Path, where the provisioning is done by the resource manager itself. 5.2

The Differentiated Services Manager

The DiffServ manager is responsible of the network reservation requests which require a specified packet forwarding behavior, and adopts the Differentiated Services approach to provide Quality of Service. The resource guarantees are provided by enabling DiffServ traffic conditioning functions in the network, such as traffic policing, marking, classification and scheduling. Different manager implementations can be defined depending on how the DiffServ transit domains are engineered and on what Per-Domain Behaviors a manager has to support. The services supported by the DiffServ manager have to depend of the requirements of the user community and on the services actually supported in the network transit domains. For this reason, the DiffServ manager implementation should be modular in order to allow for the simple addition of new services if required. In order to meet both the applications requirements and the actual services offered by the Internet service providers. 9

5.3

The MPLS Manager

The MPLS Manager is invoked when MPLS-based services are requested by the service initiator (see Section 7.4). This implies that it is involved in the creation, configuration, update and deletion of dynamic MPLS Label Switched Paths. The MPLS Manager is invoked only when the service initiator knows that all the requirements for a correct setup are met, such as the support of a specific label distribution protocol (RSVP for instance) and of MPLS itself. We assume that a user requesting the creation of a dynamic LSP can specify a bandwidth parameter that reflects the requirements of the application that will inject traffic on the LSP. This parameter is used in the following way. The availability of the requested amount of resources is checked first. If the request can be satisfied, then, the bandwidth is used to configure traffic policing at the domain ingress router and to set-up a traffic-engineered dynamic LSP. During the initialization phase, the manager creates a resource instance for each static MPLS path that can be retrieved from an internal topology database. When a reservation request is issued, the demanded amount of resource is compared with the residual bandwidth available for a given path over time. A similar approach is followed every time the user requests a modification of his/her reservation profile. 6

Network resource distribution models The allocation of resources belonging to different administrative domains is particularly important for the use, reservation and sharing of the resources owned by the members of a Virtual Organization. Central or distributed models are possible (the admission control task can be performed equivalently either through the GRAM or through AAA approach). The centralized approach assumes that a single advance reservation server is enabled, which supervises the resources of each individual domain. Of course, several backup servers can be configured to improve the fa ilure tolerance of the system. At any time the administrators of the VO are allowed to add or remove resources in the central resource manager, but remove operations of a given resource cannot be performed during a reservation slot. Each VO member needs to submit reservation requests to the central resource manager. If a reservation request succeeds, then a reservation ID – the so-called handle – is returned for future reference to the reserved resources. The advantage of this approach is that a single handle is needed to reference all the reserved resource spread over the different administrative domains. In fact, in this case the handle represents the complete QoS Path accross the multiple administrative domains. However, in this case the bind is complex, and more research is needed to properly engineer this operation with a centralized resource manager. On the other hand, in the distributed approach each administrative domain runs its own advance reservation server, which supervises the local resources. In this case, a different reservation handle has to be managed for each domain. In particular, one domain in the chain (the master domain) has to provide the user with a global reservation ID that groups the individual handles. In this case the binding can be performed by calling the master,

10

which then retrieves the individual hand les of each domain. The binding has to be performed individually in each domain. In the distributed case an extra effort is required in order to get knowledge of the resources in the other domains. Some form of advertisement is needed and a broker could help with the construction of an end-to-end Path. Alternatively, the VO members could scan the advertised resources of each domain and make themselves the reservation in each administrative domain. However, in this case synchronisation problems may arise if more then one reservation request is being processed at the same time. Of course, the combination of the two resource-control models is possible. For example, a subset of the VO domains may choose to share the same resource manager, while the remaining ones may keep their own local resource manager. The approach chosen to the path routing problem – both in a single and multi-domain scenario – is tied to the specific path-enabling technology adopted. For example, the MPLS LSP route can be defined statically, or it can vary dynamically with the network topology when the signaling messages follow the standard IP routing policies. In addition to this, non-shortest path routes can be selected if constraint-based routing and traffic engineering are enabled. 7

Prototype implementation The General-purpose Architecture for Reservation and Allocation (GARA) [21,22] addresses the problem of advance reservation by proposing a common framework that is independent from the resource type requested. The DataTAG advance reservation prototype [23] takes GARA as its fundamental starting point and extends it in a number of ways. New components like the Generic AAA, the DataGrid User Interface and the MPLS and Light Path Managers are integrated with the GARA toolkit, while other existing features, such as the DiffServ Manager, the slot table management and the topology information were improved and in some cases completely re-engineered. The GARA framework has been modified in order to integrate it with the DataGrid Workload Management resource reservation software. In particular, the GARA code was fixed, customized and ported to more recent operating system versions. The GARA software that was distributed by the DataGrid project, was also adopted in DataTAG for the addition of the above- mentioned components. In the following we present the details of some of the novel prototype component. 7.1

The Generic AAA interface

AAA server user interface is WebService-based and uses a request-response model. We use the SOAP/XML messaging paradigm. This implies that the user needs to follow the AAARequest schema when formatting a reuqest. The request type is used by the RBE to fetch a corresponding policy – the so called driving policy – and is described in one of the root element attributes. The AAARequest message could be used for different request types. The AAA server is implemented on the J2EE platform in a multi-tier fashion. Firstly, the web tier is responsible for handling the SOAP messaging. In particular, if a proper formatted SOAP message is received, then the AAA Request message – encapsulated in the SOAP body – is forwarded to next tier, i.e. the RBE. The RBE is implemented as an 11

enterprise session bean that fetches the driving policy. Finally, during this policy evaluation phase, different ASMs could be called to check if the request can be satisfied and an answer is returned back to the user [24]. 7.2

The DataGrid User interface

The language of choice used to specify a resource reservation request is the JDL [25]. A user’s reservation request is of Type “reservation” and admits the following attributes: ReservationResource, ReservationType, ReservationStart, ReservationEnd, ReservationDuration and ReservationParameters (which specifies resource-dependent parameters such as Bandwidth, EndPoint-A, EndPoint-B, SubType, Port-A, Port-B, Protocol etc.). Besides them, the JDL expression should also contain a Requirements and a Rank expressions. Requirements is an expression that defines the conditions to be met by the resource and includes contraints such as other.SupportReservation, which specifies that only the resources that support the reservation operation, have to be considered. Rank instead specifies the preference criteria to be adopted to select one of the resource instances that satisfy the Requirements. The resource selection is based on the resource attributes published in the Information System. For more information about the User Interface implementation, please refer to [26]. 7.3

The DiffServ and MPLS Manager

The DiffServ Manager was developed in order to support the two services made available by GÉANT (the European research backbone), namely: IP Premium and Less Than Best Effort. While LBE packets only need to be marked at the ingress in order to be distinguished from other traffic classes, for IP Premium both marking and policing are required. For more information about configuration and experimental results of the above- mentioned services please refer to [27]. Both the DiffServ and the MPLS Manager are integrated in a single daemon responsible of traffic conditioning configuration/deletion and of the creation, modification and deletion of the dynamic LSPs. In general, the resource manager’s implementation strictly depends on the techno logy of choice and on the type of devices that it configures. For this reason, a reference router platform has been selected. The initial prototype implementation works with Juniper routers The so-called JUNOScript XML API [28] is used to exchange configurations and operational data between the client application – the MPLS Manager – and the JUNOScript server on the router in a tagged format. The clientserver communication is session-based. Data retrieved from the router can be recast in different formats through the Extensible Stylesheet Language Transformations (XSLT). The GARA slot table management has been modified by replacing the existing filebased implementation with a relational database approach [29]. The advantages of this approach are the improved data modularity – thanks to the separation of generic tables from the resource-specific tables – and the data structure persistency in case of process failure. 7.4

The MPLS-based L2 VPN service

The integrated DiffServ-MPLS Manager is used to support the on-demand configuration of point-to-point extended VLANs, which are enabled through the 12

configuration/use of a DS Path with MPLS capabilities. The extended VLAN is an example of L2 VPN of great interest to a number of Grid application scenarios. For instance, it can be requested to bypass firewalls (to avoid performance penalties for dataintensive applications) and to group together geographically dispersed storage and computing resources that belong to the same virtual organization. MPLS LSPs are configured on the LSP head-end router, which is the gateway to the domain the destination host is a member of. In order to identify the device to configure, the manager uses an internal topology database from which routing information can be accessed. Configuration requires the definition of the LSP name (according to some naming conventions), of the associated Exp-inferred class of service and, possibly, of some additional terms such as the LSP bandwidth. The set-up in the intermediate routers is done automatically by the signaling protocols of choice, which of course needs to be supported by all the intermediate domains toward the destination. Finally, some additional configuration is needed in order to enable VLANs and to set-up the symmetric path from the destination to the source domain. If we assume that the DS Path associated to the LSP is manually configured in the transit domains (and in this case its termination points correspond to the LSP head and tail-end routers), then the request of a MPSL-L2 VPN with QoS support can be satisfied by the service provider only if a DS Path between the source and destination domain with a matching service is available. In case of static DS Paths the dynamic configuration needed is relatively simple, as we assume that scheduling, packet classification and shaping (where needed) are manually configured by the network administrators for each output interface that is subject to short or long-term congestion. In general, the configuration tasks needed to let access to a DS Path depend on the packet forwarding treatment requested and are completely transparent to the user. IP Premium and Less Than Best Effort are two possible choices. The former service does not require any traffic policing at ingress, while the latter requires that the amount of traffic injected by the user application complies to the amount of bandwidth agreed with the service provider. In order to do so, policing has to be enabled on the interface that connects the ingress router to the source host. Marking is also enabled at the ingress interface, unless packets are marked at the source. However, in case of LSPs with an associated Exp-inferred class of service, the setting of the Exp field is directly performed by the router and does not require any additional configuration. Information about the available DS Paths is provided by the Information Service, which lists the resources available in the source domain (static paths, computing and storage). The path schema contains attributes such as the source and destination domains connected by the path, the DS packet forwarding offered, the identity of the authentication and authorization server associated to that path instance, and a set of domain-specific terms (the maximum bandwidth offered, the average packet loss, the possibility to support MPLS from the source to the destination domain etc). Such attributes are used during the matchmaking phase when the service provider verifies the existence of one or more path resources that comply with the initiator’s negotiation terms. The advance reservation of MPLS-based L2 VPNs with QoS support was successfully demonstrated between INFN CNAF (Italy) and CERN across the GARR and GÉANT networks. We were able to show not only that end-systems at INFN and CNAF can be

13

dynamically configured to be part of the same VLAN, but also that multiple VLANs can be set- up with different packet forwarding behaviors. In particular, traffic exchanged between hosts of IP Premium VLANs was successfully protected from congestion produced by competing traffic of Less Than Best Effort VLANs. 8

Conclusion The paper introduces a network resource abstraction called Path, which provides connectivity between network nodes (single devices or network domains) and it can be set-up dynamically by the advance reservation system or statically, in which case its resources are partitioned and allotted to a large community of users. We have provided examples of different path types and of the corresponding managers. We assume that information about the static paths and their properties is provided by the Information service, which is accessed during the resource discovery phase. The Path abstraction will be refined and possibly proposed to the wider community, in particular in the framework of the Global Grid Forum and of the GLUE initiative [30], for its integration in a global and interoperable Information Service. A prototype has been implemented, which was successfully tested for the advance reservation of MPLS-based L2 VPNs with QoS support in a WAN production network environment. We have shown how advance reservation can be integrated with the Generic AAA server and VOMS. In the coming months we will concentrate on the improvement and refinement of the MPLS and Light Path Manager, of the extended DiffServ Manager, and of the integration between the AAA Server and the managers. The code will be redesigned according to OGSA and the specifications of the Global Grid Forum Agreement-based Service. We will also work in close collaboration with the DataGrid WP1 for the integration of the User Interface, whose specification will evolve to follow the standardization effort of the GGF. Finally, we will refine the inter-domain resource management model and work on its implementation details. The current Light Path Manager and MPLS Manager prototypes will be extended in order to support this model. 9

Acknowledgements We are extremely grateful to Volker Sander for his technical support about GARA, for his comments on some of the ideas presented in this document and for the valuable input provided to the DataTAG project. We thank Valentina Capaccio for her contribution to the design of the DataTAG advance reservation system and Emanuela Bertelli, who helped with the implementation of the db-based slot table. Finally, we are very grateful to Javier Orellana for his collaboration and ongoing help with the system testing. References 1. Foster, I.; Kesselman, C.; Tuecke, S.; The Anatomy of the Grid: Enabling Scalable Virtual Organizations; Internation J. Supercomputer Applications, 15(3), 2001. 2. Czajkowski, K.; Foster, I.; Karonis, N.; Kesselman, C.; Martin, S.; Smith, W.; Tuecke, S.; A Resource Management Architecture for metacomputing Systems; Proc.

14

IPPS/SPDP ’98 Workshop on Job Scheduling Strategies for Parallel Processing, pp. 62-82, 1998. 3. MacLaren, J.; Advance Reservation: State of the Art; the GGF Grid Resource Allocation Agreement Protocol Working Group, work in progress (https://forge.gridforum.org/projects/graap-wg). 4. Czajkowski, K.; Pickles, S.; Pruyne, J.; Sander, V.; Usage Scenarios for a Grid Resource Allocation Agreement Protocol; the GGF Grid Resource Allocation Agreement Protocol Working Group, work in progress (https://forge.gridforum.org/projects/graap-wg). 5. Czajkowski, K.; Dan, A.; Rofrano, J.; Tuecke, S.; Xu, M.; Agreement-based service Management, draft-ggf- graap-agreement-1, Feb 2004; WS-Agreement Working Group, Global Grid Forum; work in progress. 6. Czajkowski, K.; Fitzgerald, S.; Foster, I.; Kesselman, C.; Grid Information Services for Distributed Resource Sharing; Proc. Of the Tenth IEEE International Symposium on High-Performance Distributed Computing (HPDC-10), IEEE Press, Aug 2001. 7. Blake, S.; Black, D.; Carlson, M.; Davies, E.; Wang, Z.; Weiss, W.; An Architecture for Differentiated Service; RFC 2475, Dec 1998. 8. Nichols, K.; Carpenter, B.; Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification; RFC 3086, Apr 2001. 9. Nichols, K.; Blake, S.; Baker, F.; Black, D.; Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers ; RFC 2474, Dec 1998. 10. Schelén, O.; Pink, S.; Aggregating Resource Reservation over Multiple Routing Domains; Proceedings of IFIP Sixth International Workshop on Quality of Service (IWQoS'98), Napa Valley, California, May 1998. 11. Rosen, E.; Viswanathan, A.; Callon, R.; Multiprotocol Label Switching Architecture; RFC 3031, Jan 2001. 12. End to End Lightpaths Used to Bypass Internet Bottlenecks for High Speed Data Transfer Between CERN and Canada, Via SURFnet and StarLight; CANARIE, Aug 2003 (http://www.icair.org/news/aug03/canarie.html). 13. de Laat, C.; Radius, E.; Wallace, S.; The rationale of the current optical networking initiatives; FGCS special issue IGRID2002 ; Vol. 19 (2003), n. 6 , Aug 2003. 14. Lowekamp, B.; Tierny, B.; Cottrell, L.; Hughes-Jones, R.; Kielmann, T.; Swany, M.; A Hierarchy of Network Performance Characteristics for Grid Applications and Services; GGF Network Measurement Working Group, Jun 2003. 15. Vollbrecht, J.; Farrell, S.; Gommans, L.; Gross, G.; de Bruijn, B.; de Laat, C.; Holdrege, M.; Spence, D.; AAA Authorization Framework, RFC 2904, Aug 2000. 16. Yavatkar, R.; Pendarakis, D.; Guerin, R.; A Framework for Policy-based Admission Control, RFC 2753, Jan 2000. 17. de Laat, C.; Gross, G.; Gommans, L.; Vollbrecht, J.; Spence, D.; Generic AAA Architecture, RFC 2903, Aug 2000. 18. Westerinen, A. et alt.; Terminology for Policy-based Management, RFC 3198, Nov 2001.

15

19. Definition of the Architecture, Technical Plan and Evaluation Criteria for the Resource Co-Allocation Framework and mechanisms for Parallel Job Partitioning ; DataGrid Deliverable DataGrid-01-D1.4, Sep 2002. 20. van Oudenaarde, S., M., C., M.; Hendrikse, Z., W.; Gommans, L., H., M.; de Laat, C., T., A., M.; Meijer, R., J.; Dijkstra, F.; A set of OGSI-based services for the management of end-to-end fiber optic connections in a multi-domain network; submitted for publication on the Future Generation Computer Systems Journal (HighSpeed Networks and Services for Data-Intensive Grids – Special Issue), Dec 2003. 21. Roy, A.; Sander, V.; GARA: A Uniform Quality of Service Architecture; published in Grid Resource Management: State of the Art and Future Trends, Kluwer Academic Publishers, Fall 2003, pp. 377-394. Editors: Nabrzyski, J.; Schopf, J., M.; Weglarz, J. 22. Foster, I.; Roy, A.; Sander, V.; A Quality of Service Architecture that Combines Resource Reservation and Application Adaptation; Proc. 8th International Workshop on Quality of Service 2000. 23. Advance Reservation Architecture Design Based on the Evaluation of the Most Suitable Services of Grid Technology; DataTAG Deliverable DataTAG-D2.4, Dec 2002. 24. Gommans, L.; de Laat, C.; van Oudenaarde, B.; Taal, A.; Authorization of QoS path based on generic AAA; FGCS special issue IGRID2002 ; Vol. 19 (2003), n. 6 , Aug 2003. 25. Pacini, F.; DataGrid JDL Attributes; DataGrid WP1 Technical Report; http://server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0142-0_2.pdf, 2003. 26. WP1 Final Evaluation Report; DataGrid Deliverable DataGrid-01-7, Dec 2003. 27. Network Services: Requirements, Deployment and Use in Testbeds; DataGrid Deliverable DataGrid-07-D7-3, Oct 2002. 28. The JUNOScript API software; http://www.juniper.net/support/junoscript/ 29. Curti, C.; Bertelli, E.; Database Management in GARA, Database Specification (http://server11.infn.it/datatag/wp2/doc/Database_Specification-3-0.pdf). 30. Andreozzi, S.; Sgaravatto, M.; Vistoli, C.; Sharing a conceptual model of Grid resources and services, Proc. of the Computing in High Energy and Nuclear Phys ics Conference (CHEP 2003), Mar 2003.

16