; AAA_FGCS_050904_v11
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

AAA_FGCS_050904_v11

VIEWS: 28 PAGES: 17

  • pg 1
									  Dynamic Paths in Multi-Domain Optical Networks for Grids

                   S. van Oudenaarde*, Z. Hendrikse, F. Dijkstra, L. Gommans,
                                     C. de Laat, R. Meijer

           Advanced Internet Research Group, Department of Computer Science,
                       University of Amsterdam, The Netherlands.
              {oudenaar, zegerh, fdijkstr, lgommans, delaat, rmeijer}@science.uva.nl

                                           Abstract

Many Grid applications require high bandwidth end-to-end connections between Grid
resources in different domains. Fiber optic networks, owned by different providers,
have to cooperate in a coordinated manner in order to provide an end-to-end
connection. Currently, multi-domain optical network solutions require paper-based
long-term contracts between administrative domains. This paper describes a solution
for dynamically creating optical connections between different autonomous domains.
This was implemented in the form of a Grid Service following the Open Grid Service
Architecture. In our prototype, each switch belongs to a different network domain.
Our Grid Service uses a toolkit based on the Generic Authorization, Authentication,
and Accounting framework. This toolkit authorizes the use of optical infrastructure
elements based on specific policies that are active within each domain. To complete
our multi-domain authorization architecture, a broker service was also implemented.
Our broker service interacts with the Grid Service instances to provide Grid
application with a simplified way to set up end-to-end connections on demand.

Keywords: AAA, Multi-Domain, Grid Service, Web Service, Bandwidth on Demand, Lightpath
Switching, OGSA, OGSI

1. Introduction

Grid applications may use Grid resources that are distributed around the globe. For
massive data transfers, Grid designers seriously consider using tailor-made TCP
unfriendly protocols in the future: we therefore need a solution for the regular Internet
to be shielded from connections that carry such traffic [1]. A solution can be to use
dedicated optical network connections created on demand for making bulk data
transfers.

In this paper, we propose a mechanism that dynamically creates these connections
across multiple domains in an on-demand fashion based on the Generic Authorization
Authentication Accounting (AAA) framework. Each domain can define its own
business requirements using some form of policy. These policies describe the
authorization rules that allow resource usage. In order to create a connection across
multiple domains, the policy evaluation of each domain needs to be combined and
transformed into a global policy decision that authorizes a chain of network elements
to make up an end-to-end connection. We also describe how the construction of an
end-to-end path using optical switches and lambdas as resources controlled by a
network of AAA servers was implemented in our prototype. Parties with no pre-


Corresponding author
established business and trust relationships among them can offer network resources
that can be part of a globally shared network. These parties may be autonomous, as
they are capable of describing their business rules and trust relationships using a set of
policies. A commonly trusted party (e.g., a monetary entity or a certificate authority)
could guarantee the necessary trust.

Our prototype uses the Globus Toolkit version 3 [2], which implements Open Grid
Services Infrastructure (OGSI) [3]. The Open Grid Services Architecture (OGSA) [4]
extends the standard Web Service approach with features such as lifetime
management, service data and Grid style security. OGSI specifies an Application
Programming Interface (API) for these Web Services, which we call Grid Services
throughout the paper. As its architecture provides a loose coupling between software
components, OGSI offers seamless interoperability between a Grid Service and its
users or client applications. This feature is needed for a Bandwidth on Demand (BoD)
service to let the involved domains cooperate in a flexible manner. The long-term
goal is to create a generic framework that allows complex authorization decisions to
be taken through a flexible network of interconnected AAA servers.

The rest of this paper is organized as follows. Section 2 gives an overview of related
work. In section 3, we construct a model for the multi-domain control of end-to-end
Lightpaths. Section 4 details the software design and key components. Section 5
describes the BoD Service advertisement elements as service data. Section 6 presents
the implementation details. Finally, we conclude with section 7 and present directions
for future work.

2. Related Work

Constructing software components that abstract the network elements is not new. In
our case, these object representations form the building blocks from which a
Lightpath is constructed. A similar approach is used in the Telecommunication
Information Networking Architecture (TINA) [5], where a QoS path is also
constructed for certain applications and users. The TINA architecture recognizes a
number of business roles: a Consumer, a Retailer and third Party Service Providers.
These business roles are driven by a broker business role and interconnected by a
connectivity provider. A network of interconnected AAA servers allows the creation
of TINA style business roles using the TINA architecture. Generic AAA can go
beyond that by allowing the definition of brokers, super-brokers (brokers that drive
brokers) and more stakeholders (e.g., a User Home Organization). TINA defines five
key business areas between which relationships are defined in a specific architecture.
A Generic AAA based approach does not demand a specific structure of business
areas and their relationships.

Another aspect is policy-based admission control. With Generic AAA, we can
manage fine-grained access control to each resource. Each domain handles its
resource access control. With OGSA there is also fine-grained control based on the
grid-access files, but it needs to be managed on a per Virtual Organization (VO)
basis. In other words, changing access levels requires changes in each administrative
domain of a VO. In addition to commercial solutions for single domain provisioning
applications, some research is also underway to explore the concept of optical switch
control. One of the leading software packages is the User Controlled Lightpath
Provisioning (UCLP) [6][7][8]. UCLP currently works in a multi-domain fashion,
where all parties and rules are pre-determined. Truong et al. [9] worked on policy-
based admission control for UCLP and implemented fine-grained access control.
Some interesting work in the optical field is also done in Dense Wavelength Division
Multiplexing- RAM [10] [11], where a Grid-based optical (dynamic) bandwidth
manager is created for a metropolitan area. Our bandwidth manager presented in this
paper differs from it, because it focuses on the control of an optical infrastructure in a
multi-domain environment.

There are also initiatives to work on new standards for a control plane for optical
networks. Within the NSF-funded Optiputer project [12], the AAA toolkit adds
policy-based mechanisms to the Photonic Interdomain Negotiator (PIN) and Photonic
Domain Controller (PDC) software.

3. Multi-Domain Bandwidth Control Model

Various techniques can be used for constructing a predictable end-to-end network
behavior or connection. Such techniques manage bandwidth in different ways:
Differentiated Service (DiffServ) [13] by creating per hop behaviors inside layer-3
routers; Multi Protocol Label Switching (MPLS) [14] and Generalized MPLS [15] by
establishing a path using label switched routers. One approach, typically adopted for
layer-1 switches, uses the concept of Lightpath. A Lightpath is defined as “any uni-
directional point-to-point connection with effective guaranteed bandwidth” [16]. A
Lightpath provides a dedicated and guaranteed amount of bandwidth, suitable for very
high data transfer demands such as those found in scientific Grid applications [17].
Instead of using a router, a Lightpath uses a separate control plane that is used along
the data-forwarding plane. Here we focus on fiber connections and using optical
devices to form an end-to-end Lightpath. We are, therefore, bound to use layer-1
characteristics for control. This end-to-end Lightpath is set up using an OGSI-based
BoD Service for each domain in the path. In this case end-to-end means a connection
between Grid resources, assuming that each Grid resource is equipped with a second
interface that is connected to the optical infrastructure.

For multi-domain control, a mechanism is needed that respects local policies and
manages the network domains to set up the end-to-end Lightpath on demand. We
propose to use a Grid Service to simplify the management of the network transport
services across multiple administrative domains. Viewing networks as Grid Services
allows one to consider the management of connections as a software transaction
problem. To virtualize networks into software components, we formally divide Grid
resources into two types:
    1. Network Elements (NEs), e.g. switches, routers, optical cross connects, fibers
        or lambdas;
    2. other resources, e.g. Storage Elements or Computing Elements.
Type 2 resources are modelled with Grid Services. We extend the metaphor to the
optical Network Elements and provide the network as a software component. The
BoD Grid Service is constructed using these components. The BoD Service abstracts
the domain as a virtual switch device.

Of special interest is the dynamic invocation interface to these different BoD services
and the use of Service Data Elements to publish and discover network resource
characteristics. OGSI defines an interface to a Grid Service by using an extended
version of the Web Services Description Language (WSDL) [18]. This guarantees
interoperability between different BoD services. The BoD service can notify network
state changes to subscribed members. The brokers require interoperable interfaces and
need to track the state changes in the different administrative domains to see if they
can satisfy the user requests. This results in a brokerage-model, where the BoD
services manage the domains.

Our BoD and Broker Grid Service implementation use aspects of Generic AAA as
described in RFC 2903 and RFC 2904. These RFCs propose an architecture and
framework to handle multi-domain authorization decisions. A Generic AAA server
consists of a Rule Based Engine (RBE), a policy repository and Application Specific
Modules (ASMs) that can perform application specific functions. The Grid Security
Infrastructure [19] is used for AAA request message authentication. In addition, OGSI
is used as a means to describe the interface of the BoD Grid Service and present
stateful data elements.

Using generic AAA components, a two-step mechanism is provided for global
authorization decisions. In the first step, local decisions are collected and yield one
global decision. The local decisions are simply “yes” or “no” answers. In step two,
given a positive global decision, the provisioning of the connection is done by the
enforcement part of the service. The Generic AAA components within the BoD Grid
Service enable a policy-based admission control to resources, thereby allowing each
domain to implement its own set of policies. The technical control features are not
distributed but kept local. The broker combines this with a final result respecting the
local policy decisions, and lets the user or application know if it is authorized to use
the resources.

4. Architectural Design

In this section we present the architecture of our prototype. First we present the
Broker Service, then the BoD Service, and finally the integration of these two
services.

4.1 Broker Service

Our broker is responsible for brokering Grid Services (here BoD Grid Services). The
broker itself is also a Grid Service. It creates an end-to-end Lightpath through the
different administrative domains by retrieving service data from the BoD Services of
each domain 1. Note the similarity with the Index Information Service (IIS) [2] of the
Globus Toolkit. An IIS offers the most appropriate service alternative to its requestor
by collecting and matching the service data that it obtains from the various service
providers. The service data elements contain information on the available Network
Elements and possible connections in a certain time frame. The service data can be
obtained in two ways:
1. The broker pulls the service data at run-time to handle a BoD request or fill a
    cache.


1
    Eventually, there should be a common agreement on the ontology of both the messages and services.
2. The broker Grid Service subscribes to each BoD Grid Service to periodically
    receive the latest state information via the notification mechanisms provided by
    OGSI. Here the OGSI notification mechanism pushes the data to the broker.
Pushing information requires that at least part of the receiving Broker Grid Service be
persistent. For example, it is convenient to retain topology data when the processing
of a request is over. Therefore, we distinguish between persistent and transient
services offered by the Broker Grid Service. Working on pushed data may cause a
synchronization problem if more than one BoD request is processed at the same time.

In the transient part, the authentication of the users and the Broker Service is handled
by configuring message level security using the GSI. Each BoD Grid Service takes
care of authorization independently. For our prototype implementation, we use the
authentication mechanism offered by the Globus toolkit. This only ensures the
authenticity of a BoD request. A BoD request can contain one or more authorization
credentials. Credentials may be represented by signed or unsigned attributes. Signed
attributes are typically used when the source of authority is different from the source
of the request message.

4.2 BoD Service

We expect the following use cases for BoD Services to become popular:
  • BoD Services that can be requested on an ad hoc basis are dependent on the
      actual state of the network. Assuming we have enough users, the availability
      of such connections may be expressed as a traditional Erlang blocking
      probability [20], well known in the telecommunications industry. The
      blocking probability increases with the number of domains involved.
  • BoD Services that can be used to reserve network elements in advance. The
      availability of a future timeslot may again be dependent on a blocking
      probability that may increase with the number of domains involved. However,
      once a suitable timeslot is found, the availability is guaranteed.
  • Massive Data Transport Service (MDTS) that can always accept the data at
      request time by using intermediate storage devices in each domain. MDTS
      follows a store-and-forward principle and can be seen as a terabyte mail
      service. Grossman et al. [21] reported on protocol experiments with this type
      of service.

We have investigated all these cases, but only the first case has been implemented so
far in our prototype.

4.3 Integration of the Broker and BoD Services

A requestor of a Lightpath creates a Broker Service Instance (BSI) by sending a
message to the Broker Service Factory. The requestor authenticates to the Broker Grid
Service, whereas the broker may want to use its own credentials to authenticate to the
various BoD Grid Services.

 The implementation of the Generic AAA facilities is optional for each BoD domain,
as shown in the rightmost service domain on Figure 1. The persistent part of the
Broker Service takes care of the routes. The Broker Service Instance consults the
Topology service for a path.
                    Fig. 1: Proposed BoD / Broker architecture
The BoD Grid Services consist of the following components: a Service Data
component, a Provisioning provider, a Notification provider, a AAA manager and a
bandwidth manager (see Figure 2). A provider is a way to implement a Grid Service
by delegation [22]. The actual work (i.e., the provisioning and subsequent
notifications) requested by the providers, is actually performed by the bandwidth
manager. The bandwidth manager maintains the state information of the network and
updates the Service Data. The bandwidth manager abstracts the domain as one big
optical switch with external connectivity fibers connected to internal Grid resources.




                    Fig. 2: Bandwidth on Demand Grid Service
5. Service Data Elements

In order to enable discovery of the network resources offered by the BoD Service,
Service Data Elements need to be defined and published. In our case, the domains are
modeled as virtual optical cross-connects with incoming and outgoing optical
connections. The following Service Data Description enables the BoD Grid Service to
present the Broker Grid Service with enough information to establish a connection
between the Grid resources.




                     Fig.3: Service Data Elements description

In Figure 3, the CrossConnectData type is defined and provides information on the N
incoming and M outgoing lambdas of this domain, allowing each lambda to have a
different bandwidth. Similarly, the ResourceData type presents data on a resource,
such as the contact host name, the interface type and a Grid Service URL. This URL
discloses more information on the services than offered by the resource.

6. Experimental Results

In this section, we describe the experimental setup and present the results of our
prototype demonstrated at SuperComputing 2003 (SC2003) [23]. Our goal was to
verify whether our policy language and AAA mechanism worked when setting up a
Lightpath in a multi-domain environment. Separating the decision making process
from the enforcement process proved very useful. The decision making process was
distributed; the Broker Grid Service AAA component made the final decision and
checked if a request could be satisfied.

At SC2003, two domains where involved: NetherLight [24] and StarLight [25].
NetherLight is the Dutch optical network research facility designed and operated by
SURFnet. StarLight is based in Chicago, funded by the National Science Foundation
(NSF) and jointly designed by the Electronic Visualization Laboratory (EVL) at
University of Illinois at Chicago, the International Center for Advanced Internet
Research (ICAIR) at Northwestern University, and the Mathematics and Computer
Science Division (MCSD) at Argonne National Laboratory. These projects share two
lambda connections and deploy an optical cross connect (OXC) to switch local fiber
onto the shared lambda connections. For this demonstration, the NetherLight domain
was the owner and controller of the shared Lambda connections, (see Figure 4). The
partial control model [26] was used.




                     Fig. 4: A multi-domain control scenario

At the heart of the Broker Grid Service and BoD Grid Service lie the AAA
components. OGSI is used as an interface to access the Broker Grid Service. It
handles the authentication with GSI and provides a uniform Web Service interface.
The BoD Grid Service uses the AAA functions to do policy-based admission control
on the Grid resources. This AAA server is called admission-AAA. The AAA server
used for the Broker Grid Service is called broker-AAA. The admission-AAA server in
the NetherLight domain provisions both the OXC and the lambdas, whereas the
admission-AAA server in the StarLight domain provisions only its OXC. Controlling a
lambda or an OXC also means that the AAA server is responsible for the
administration and state of the underlying network components. Based on the applied
policies in both domains, requests for a Lightpath between NetherLight and StarLight
are granted or denied. The AAA servers handle the decision making and authorization
processes needed for the BoD Grid Service. We used a third AAA server for the
Broker Grid Service (see Figure 5).

6.1 Implementation

A prototype of the BoD and Broker Grid Service (these two services are supported by
a single Grid Service) was implemented using Generic AAA components combined
with service providers, as described in Section 3. Our prototype implementation
incorporates Web Services APIs, the OGSI components of the Globus Toolkit version
3, and the Java2 Enterprise Edition (J2EE) [27] run-time environment. The testbed is
depicted in Figure 5. In each domain, a Generic AAA server supports the BoD or
Broker Service. Broker functionality can be described as a sequence of actions (e.g.,
resolving a path between source and destination hosts or invoking a BoD Service to
provision and check credentials). As authorization is required in each of these actions,
the Broker functionality has been implemented with ASMs. The driving policy
describes the actions and steps. For complicated actions, it invokes ASMs. The same
applies to the BoD functionality. More details on ASMs and policy interaction can be
found at the end of this section and in [26].




                           Fig. 5: Testbed used at SC2003.

6.2 Multi-Domain BoD Scenario

The Broker Service is instantiated by the user via the OGSI BoD interface sending a
BoD request. A BoD request for an end-to-end Lightpath is encapsulated in an AAA
request message. This message consists of two parts. The first contains AAA specific
credentials needed for authorization decisions, the second contains the BoD specific
requirements of the Lightpath. An example of a AAA request, see Figure 6.
              Fig. 6: An XML AAA-Request for the Broker Service.

The broker-AAA server fetches the corresponding driving policy upon receipt of the
AAA request type (BoDRequest policy). In this policy, actions are defined to satisfy
the BoD request. The BoD request is processed according to the logic contained in the
driving policy. The broker-AAA has a predefined trust relation with the BoD Service
of the other admission-AAA servers. The communication between the BoD Grid
Service and the broker is based on the Simple Object Access Protocol (SOAP) [28]
and XML messaging. The broker is built using the same components as the BoD
Grid Services. Because the AAA server is capable of invoking instances of itself, the
broker can be seen as a recursive BoD Grid Service. When the broker-AAA server
discovers that part of the request is addressing a local resource (located in the
NetherLight domain as shown in Figure 5), a request is sent to its own local
admission-AAA server, which in turn drives the Calient photonic switch. The same
applies to the other domains involved. The admission-AAA server at StarLight is
contacted by the Broker Service and drives the Calient switch.
The policies are fetched from the policy repository. Each admission-AAA server has
its policy repository. The broker’s Rule Based Engine (RBE) extends its policy
decision over the involved RBE components of the local BoD Services. Each BoD
Service RBE makes its own local policy decision. In our case, local policy decisions
are needed to determine if a certain request is allowed for a combination of ports. As a
result, the involved BoD Grid Service domains do not always base their decisions on
the same aspects as the brokers.
In this way, cooperation is established between multiple administrative domains. The
underlying local BoD RBE replies ”yes” or “no” to requests from the Broker RBE.
The combination of these logical answers to requests from the Broker RBE solves the
problem of making complex authorization decisions. Furthermore the local domain is
not required to reveal any insight in its decision making process. Coordinating
without revealing any local policies is an essential requirement in a multi-domain
scenario.

6.3 Broker Grid Service Structure

The broker checks whether the request complies with the conditions specified by the
BoD driving policy. During the evaluation of this policy, several ASMs are consulted.
The AAARequest ASM forwards a AAA request to the BoD Grid Services involved
to determine whether the user is allowed to make a cross-connection as part of the
Lightpath. In Figure 7, we can see an excerpt of the BoD driving policy that is used
by the broker-AAA to invoke the AAARequest ASM.




                     Fig. 7: BoD Driving Policy of Broker-AAA

The AAARequest ASM generates a SOAP call to the involved OXC domain (in our
case, StarLight or NetherLight). The answer (“yes” or “no”) is used in subsequent
steps of the policy evaluation.

A Resource Manager ASM fetches state information on the lambdas and resolves a
Lightpath between a source and a destination. This path can be a lambda or represent
a complete network cloud as a virtual lambda (see [26] for a recursive approach). For
each lambda, three states are defined: idle, transient or busy. In the transient state, the
lambda goes from busy to idle or vice versa.

6.4 BoD Grid Service Structure

To interface to the Calient switch, we implemented an OXC ASM. This ASM uses
TL1 [29], an ASCII-based control language originating from the telecommunication
world, to control the switch. A resource manager ASM checks in the device driving
policy whether there is a lambda idle and whether the requestor is authorized to use
this lambda based on the credentials. The OXC ASM is called with instructions to
cross a port. This module generates the required TL1 messages needed to fulfill this
action and returns the result. The ports on the (virtual) switch are resolved within the
admission policy with another call to a local resource manager (in our case, a database
containing the mapping of lambdas to ports on the OXCs).
6.5 Migration to WSRF

The Global Grid Forum (GGF) recently began migrating from OGSI to the Web
Services Resource Framework (WSRF) [30]. In [31] the migration impact on OGSI
based services is discussed. OGSI and WSRF model stateful resources differently.
Grid Services and WS-resources provide equivalent base functionality and we can
semantically construct our Broker / BoD model with both. The WSRF has a better
alignment with the Web Services standards. Our prototype code needs refactoring in
the addressing and notification mechanisms to become WSRF compliant. The OGSI-
defined Grid Service Reference and Grid Service Handle need to be replaced by
different functions and mechanisms (WS-addressing) provided by WSRF. The
notification concept of OGSI is also improved in WSRF; three separate specifications
(WS-BaseNotification, WS-BrokeredNotification and WS-Topics) improve the
notification concept.

7. Conclusion

In this paper, we have introduced the concepts needed to provision end-to-end optical
connections in a multi-domain network using policy-based decisions that are executed
by components of a Generic AAA server. These concepts were successfully
demonstrated at SC2003. We have shown a working example of our AAA mechanism
where multiple policies, each in a different domain, were consulted to make a
distributed decision. The AAA Toolkit functions are flexible enough to combine the
outcome of local policy decisions and make a global decision to authorize and
provision a multi-domain Lightpath between NetherLight and StarLight. A number
of Generic AAA servers can form arbitrarily complex networks that can be used to
create multi-domain environments using different key business roles.
The Generic AAA approach using SOAP and XML provides a flexible way to
combine a set of Grid Services if there are multiple stakeholders involved. The broker
approach shown in this paper is only one of many ways to chain individual object
representations of network elements into an end-to-end optical connection. Further
research is needed to compare different models for orchestrating various forms of
these Grid Services. Because of the GGF’s announced transition from OGSI to
WSRF, we need to investigate in detail the impact of this migration on our prototype
for the BoD and Broker Grid Service. Last, the performance of Java-based Web
Services implementations is a general concern. The current level of performance
prevents provisioning end-to-end connections in the millisecond timeframe, because
of the overhead incurred by OGSI/ J2EE and the OXC interaction. It is important to
study how this performance can be improved.

Acknowledgments

The Electronic Visualization Laboratory (EVL) of the University of Illinois at
Chicago provided the Calient DiamondWave equipment. The research work by L.
Gommans, S. van Oudenaarde and F. Dijkstra was partially funded by the IST
Program of the European Union (grant IST-2001-32459, DataTAG project). The
Dutch National Research Network (SURFnet) provided additional funding and
experimentation infrastructure. Z. Hendrikse’s contribution was funded by an
ICES/KIS grant from the Dutch Ministry of Education and Science (OC&W) and the
Ministry of Economic Affairs (EZ). The authors wish to thank Alan Verlo, Lance
Long, Tom DiMaggio, Eric He, Oliver Yu and Tom DiFanti from the University of
Illinois at Chicago and Hui Li from NIKHEF for their support and efforts in providing
the testbed before and during SC2003. National Computer Facilities funded the
demonstration space at SC2003.

References

[1] A. Falk, T. Faber, J. Bannister, A. Chien, R. Grossman, J. Leigh, Transport
Protocols for High Performance, Communications of the ACM, Vol. 46, Number 11,
November 2003, pp 43-49.

[2] Globus Toolkit version 3, http://www.globus.org/toolkit

[3] S. Tueke, K. Czajkowski, I. Foster, Open Grid Services Infrastructure (OGSI),
Version 1, Global Grid Forum, June 2003.

[4] I. Foster, C. Kesselman, J. Nick, S. Tuecke, The physiology of the Grid: An Open
Grid Services Architecture for distributed systems integration, Open Grid Services
Infrastructure WG, Global Grid Forum, June 2002 (extended version of Grid Services
for Distributed System Integration).

[5] F. Steegmans, C. Abarca, J. Forslow, et. al., TINA-C, Network Resource
Architecture V3.0, http://www.tinac.com/specifications, Feb 1997.

[6] W. Hong, CA*net4 Directed Research Program Software Architecture, Technical
report, University of Carleton, May 2003,
http://lightpath.physics.carleton.ca/Canarie1Tech.pdf

[7] J. Wu, S. Campbell, J. M. Savoie, H. Zhang, G. v. Bochmann
and B. St.Arnaud, User-managed end-to-end lightpath provisioning over
CA*net 4, in Proceedings of the National Fiber Optic Engineers Conference
(NFOEC), Orlando, FL, USA, Sept 2003, pp. 275-282.

[8] R. Boutaba, Y. Iraqi, A. Ghlamallah, et. al., User Controlled Lightpaths
Architecture Design, May 2003, Presentation, http://bbcr.uwaterloo.ca/~canarie/

[9] D.L. Truong, O. Cherkaoui, H. ElBiaze, N. Rico, M. Aboulhamid, A Policy-based
approach for User Controlled Lightpath Provisioning, in Proceedings of the 2004
IEEE/IFIP Network Operations and Management Symposium (NOMS 2004), April
2004, pp. 859-872.

[10] S. Figueira, S. Naiksatam, H. Cohen, et.al., DWDM-RAM: Enabling Grid
Services with Dynamic Optical Networks, in Proceedings of the SuperComputing
Conference (SC2003), Phoenix, Arizona, November 2003.

[11] S. Figueira, S. Naiksatan, H. Cohen, et al., OMNInet: A Metropolitan 10Gb/s
DWDM Photonic Switched Network Trial, in Proceedings of Optical Fiber
Communication Conference and Exhibition (OFC 2004), Los Angeles, Feb 2004.
[12] The OptIPuter project, named for its use of Optical networking, Internet
Protocol, computer storage, processing and visualization technologies.
http://www.optiputer.net

 [13] S. Blake, D.Black, M. Carlson, E. Davies, Z. Wang, W. Weis, An Architecture
for Differentiated Services, RFC 2475, December 1998.

[14] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching
Architecture, RFC 3031, January 2001.

[15] E. Mannie, P. Ashwood-Smith, O. Awduche, et. al., Generalized Multi-Protocol
Label Switching Architecture, http://www.ietf.org/html.charters/ccamp-charter.html

[16] The term Lightpath was introduced in the CA*net4 of Canarie,
http://www.canarie.ca/canet4/index.html

[17] C. de Laat, E. Radius, S. Wallace, The rationale of current optical networking
initiatives, Future Generation Computer Systems, Vol. 19, Number 6, August 2003,
pp. 999-1008.

[18] Web Service Description Language (WSDL) version 1.1, W3C Note, March
2001.

[19] V. Welch, F. Siebenlist, I. Foster, et. al., Security for Grid Services, in
Proceedings of the 12th IEEE International Symposium on High Performance
Distributed Computing, Seattle, Washington, June 2003, pp. 48-57.

[20] J.R. Boncher, Traffic System Design Handbook, Wiley, 1992.

[21] R.L. Grossman, Y. Gu, X. Hong, A. Antony, J. Blom, F. Dijkstra and C. de Laat,
Teraflows over Gigabit WANs with UDT, Future Generation Computer Systems,
December 2004.

[22] B. Sotomayor, The Globus Toolkit version 3 Programmer's Tutorial, July 2003,
  http://www.casa-sotomayer.net/gt3-tutorial

[23] SuperComputing 2003, http://sc-conference.org/sc2003/

[24] NetherLight, http://www.surfnet.nl/innovatie/netherlight

[25] StarLight, http://www.startap.net/starlight

[26] L. Gommans, C. de Laat, B. van Oudenaarde, A. Taal, Authorization of a QoS
path based on generic AAA, Future Generation Computer Systems, Vol. 19 Number
6, August 2003, pp. 1009-1016.

[27] I. Singh, B. Stearns, M. Johnson, Designing Enterprise Application with J2EE
Platform, Addison Wesley, 2002.

[28] Simple Object Access Protocol (SOAP) version 1.2, W3C Note, June 2003.
[29] Telcordia GR-831-CORE, Operations Application Messages - Language For
Operations Application Messages, Telcordia Technologies, Nov 1996.

[30] K. Zajkowski, D. Surgustion, I. Foster et. al., The Web Services Resource
Framework, version 1, March 2004, http://www.globus.org/wsrf/

[31] K. Czajkowski, D. Ferguson, I. Foster, et. al., From Open Grid Services
Infrastructure to WS-Resource Framework: Refactoring & Evolution, Version 1.1,
Global Grid Forum, May 2004.


Biographies
Cees de Laat is an Associate Professor at University of Amsterdam, The
Netherlands. He received a Ph.D. degree in Physics from the University of Delft. His
research interests include optical networking, lambda switching and provisioning,
policy-based networking and the Authorization, Authentication and Accounting
architecture. He is responsible for the research on the Lambda switching facility
(NetherLight). He implements research projects in the GigaPort Networks area in
collaboration with SURFnet.




Prof. dr. R.J. Meijer received in 1989 a Ph.D. degree in experimental nuclear
physics from the University of Utrecht. After a postdoc at the Gesellschaft Fuer
Schwerionenforschung (GSI) in Darmstadt he was employed by the research institute
of the Royal PTT in the Netherlands. This institute is currently known as TNO
Telecom where Meijer is Senior Strategist. Meijer holds also the chair of “Applied
Telematics” at the University of Amsterdam. His current research activities include
subjects in which Internet technologies, sensor networks and software technologies
are developed and applied as well as regional development through ICT.




Leon Gommans received his B.Sc. degree in electrical engineering at Chr. HTS
Hilversum in 1981. Since then, he has been active in networking. After working at the
CTO office of a large network equipment vendor he joined University of Amsterdam,
where he currently works on the applicability of Generic AAA, which he helped
define within the IETF and IRTF.




Sebastien van Oudenaarde received a M.Sc. degree in applied mathematics from
University of Delft in 1998. He is a research programmer at University of
Amsterdam. He currently participates in the Generic Authorization, Authentication
and Accounting architecture research project.




Zeger W. Hendrikse received his degree Ph.D. degree in solid state physics from
University of Leiden in 1997. After working for two years at the IT
Departments of Philips and the CBS, he joined the Computer Architecture and
Parallel Systems group of the Informatics Institute of University of Amsterdam. His
research then was on Grid Computing. Recently he returned to industry (Amis
Services), where he specializes in Java, Web Services and J2EE.




Freek Dijkstra received a M.Sc. degree in applied physics from
University of Utrecht, The Netherlands, in 2002. He is a researcher and a Ph.D.
student at University of Amsterdam. Freek's research interests focus on Optical
Networking, especially on multi-domain aspects.

								
To top