Wade Hong
Carleton University
May 26, 2003

• a service is a service is a service
• comprised of interactions between three distinct actors
– provider (service)
– registry (broker)
– requestor (client)
• actor role interactions
– publishing information about a service
– locating which services are available
– binding to services

• considered the owner of the service
• network accessible software asset
• by definition
– service has a description
– concrete implementation encapsulating its behaviour
• description of the service and how to access it is published to a registry
• e.g.: software agent controlling a network element

– descriptions of the services
– details regarding how to bind to or access the services

• consumer of a service
• discovers and invokes services from one or more providers
• obtains service descriptions from a registry through a specialized set of APIs
• binding
– uses the service description to send a message to the provider directly or indirectly
• e.g.: bulk transfer grid application requesting endto-end lightpath

(from Cabri et al. 2000)

• communication occurs via a tuple space
• tuples and antituples are generated and submitted to the tuple space
• originates from Linda, a high level coordination paradigm for parallel computing (Gelernter 1985)

• views an application as a set of processes coordinated through the flow of objects into and out of one or more Spaces
• Space
– shared, network accessible repository of objects used by distributed processes for object storage and exchange
– distributed persistent (transient) shared memory
– blackboard or working memory model

• processes (requestors and providers)
– perform simple write, read and take operations utilizing value-matching lookup
– interact indirectly and asynchronously through a Space
– are loosely coupled spatially and temporally
• applications tend to be more flexible, scalable and reliable
• easier to build
• Javaspaces is a Jini service which implements a space-based communications model

• use Jini technology to build a scalable service oriented multi-agent framework
• construct a Jini community of services around one or more CA*net 4 Lightpath cross-connect device
• modular approach
– develop and construct one Jini community
– replicate for additional devices
• Jini communities interact using Javaspaces as the communications substrate

• trend in computing is towards more ubiquitous, interconnected computer systems
– agent software paradigm is a strong candidate for exploiting the potential of such systems
• multiple interacting autonomous intelligent processes
• key behaviours
– autonomy
– inter-agent communication
• collective behaviour is emergent
– “the whole is greater than the sum of the parts”

“An agent is a computer system that is situated in some environment , and that is capable of autonomous action in this environment in order to meet its design objective”
(Wooldridge and Jennings 1995)

“……. agents as a replacement for hard-to-provision protocols is one of the most practical uses. With the widespread use of Java and the newer Jini technology, mobile agents should become the major way of deploying new services in the years ahead. This change will mark the beginning of the end of the Internet as a world of protocols and the beginning of the era of the agent-based Internet.”
(Bill Joy 2000)

Core Agents
1) Optical Network Element agent
2) LightSpan agent
3) Cross Connect agent
4) Event agents
5) Network Element agent
6) Lightpath agent
7) Routing agent
8) Switching agent
9) Lightpath Service agent

• CA*net 4 Lightpath device is key element for which services are to be exposed
• physical device is not yet Jini capable
• situated autonomous software agent as a Jini surrogate

• upon instantiation, the ONE agent discovers one or more Jini lookup services to register a set of services
– proxies for the services are published to the lookup service
– services are then part of the respective Jini community
– registration is a lease and must be renewed continually
(self healing)

• initial ONE services
– partitioning service
• an authorized client can partition the switching fabric of the
CA*net 4 Lightpath cross-connect device
• persistent state information regarding ownership of ports and
STS channels at a port is maintained by the ONE agent
– cross connect service
• creates or deletes a cross connection between ports and STS channels
• service interfaces to the ONS15454 via the craft interface using
TL1 or UNI-C (UVA)

• initial ONE services
– status service
• provides state information about the CA*net 4 Lightpath device
• information includes performance and alarm information, ownership of ports and STS channels at a port

• a Jini community may include several ONE agents
– each with ONE agent will have its own instances of the partitioning, cross connect and status service

• agent responsible for handling the advertisement of available lightspans
• definition
– a span is the optical segment which connects any two
ONEs
– a lightspan is a sub channel of the span
– if a lightspan is not cross connected across the ONE, the resource is considered available
– the resource is typically available only to the ascribed owner

• upon instantiation, determines the free lightspans for all the ONEs within a Jini community
– uses the status services for the respective ONEs
• policies needed to determine which and when lightspans are advertised
– initially all free lightspans will be advertised
– periodic monitoring of ONEs
– notification of lightpath teardown Space events
– evolutionary process

• a Space is used for publishing lightspan availability
• a lightspan object representing a span is written into the CA*Net 4 Lightpath Space
– a Jini Entry object
– matchable fields are public
– with a specified lease period

public class LightSpan implements Entry
{ public String OriginatingAS; public String OriginatingONE; public String OriginatingSlot; public String OriginatingPort; public String OriginatingSTSChannel; public String DestinationAS; public String DestinationONE; public String DestinationSlot; public String DestinationPort; public String DestinationSTSChannel; public String Bandwidth; // e.g. STS-24 public String Owner; public String Group;
} public String Status; // public String Direction; // e.g. 2-way public Integer SubLeasePeriod; // e.g. 10080
(min) public String Subdivisable; // e.g. Yes
……………

• performs the task of creating and deleting cross connects on member ONEs
– between a port and a port, a port and an STS channel on a port, or an STS channel on a port and an STS channel on a port
• interacts directly with the CA*net 4 Lightpath Space
– template matches for create and delete cross connect objects intended for the member ONEs
• locates the ONE cross connect service and through its proxy initiates the cross connect action

public class CreateCrossConnect implements Entry
{
} public String AS; public String ONE; public String OriginatingSlot; public String OriginatingPort; public String OriginatingSTSChannel; public String DestinationSlot; public String DestinationPort; public String DestinationSTSChannel; public String Bandwidth; // e.g. STS-24 public String Owner; public String Group; public String Status; // public String Direction; // e.g. 2-way public Integer SubLeasePeriod; // e.g. 10080 (min)
………..
public class DeleteCrossConnect implements Entry
{
} public String AS; public String ONE; public String OriginatingSlot; public String OriginatingPort; public String OriginatingSTSChannel; public String DestinationSlot; public String DestinationPort; public String DestinationSTSChannel; public String Bandwidth; // e.g. STS-24 public String Owner; public String Group; public String Status; // public String Direction; // e.g. 2-way public Integer SubLeasePeriod; // e.g. 10080 (min)
………..

• transactionable methods
– groups a number of cross connect actions as a transaction
– two phase commit
– creating and removing an end-to-end lightpath as a single transaction is important
• ensures reliability and consistency
– capability will be evolved as the agent is developed

• interacts with active network devices such as routers or switches
– typically, edge devices at the ingress and egress of the requested lightpath
• upon instantiation, the NE agent discovers one or more Jini lookup services to register a set of services

• initial NE services
– ASPATH service
• for a router NE between the end host and the CA*net 4
Lightpath cross connect device, this service returns the current
BGP ASPATH between a given source and destination AS
• provides network path topology
– Re-routing service
• permits an authorized client to modify the routing of traffic across the router or layer 3 device
• typically, this will involve injection of a static route
• the new route is the end-to-end lightpath bypass

• initial NE services
– VLAN service
• for a L2 switch NE between the end host and the CA*net 4
Lightpath cross connect device
• Reconfigures the L2 switch to place the respective ports on the same 802.1p/q VLAN
– status service
• provides state information about the edge network element devices
• information includes port configuration, performance and alarm information

• use ssh or telnet over the LAN interface to connect to the NE
• end users connected to established lightpaths in two ways
– directly
• host to host
• single hop end-to-end lightpath
• NE not required and ORANs are transparent
– indirectly
• through edge Linux routers (Zebra)
• ORANs in this scenario are also transparent

• transient agent created by the Lightpath Services agent
– lightpath creation or deletion request conveyed through a Lightpath
Provisioning or Deprovisioning Request entry in the CA*net 4
Lightpath Space
• instance of a lightpath agent is created to act on behalf of each grid-based application
• interacts with the CA*net 4 Lightpath Space to locate and construct an end-to-end lightpath
• similar in behaviour to the end-to-end co-reservation agent in
GARA (Globus Architecture for Reservation and Allocation)

• searches the CA*net 4 Lightpath Space with template matching to locate lightspan objects which can be concatenated together to construct an end-to-end lightpath
– matches may have varying granularity satisfying given constraints such as bandwidth, period of availability, etc
• creates a set of cross connect objects and groups them into one atomic transaction
– if the transactions succeed, the respective cross connect objects and lightspan objects removed from the Space
• the end-to-end lightpath is now provisioned!

• however, to utilize the end-to-end lightpath, traffic must be rerouted across it
– creates routing or switch request entries and injects them into the
CA*net 4 Lightpath Space
– two requests, one for each terminus form a transaction
• when the application completes, the resources can be released
• deprovisioning entails writing a set of delete cross connect objects into the CA*net 4 Lightpath Space and grouping as a single atomic transaction
– routing or switch entries to delete the injected route or teardown the created VLAN are injected into the CA*net 4 Lightpath Space

• may also monitor events on behalf of the gridbased application and forwards them to the application
– listens for specific remote events in the CA*net 4
Lightpath Space

• performs the task of adding, modifying or deleting routes on respective NEs
• retrieves the routing request entry from the
CA*net 4 Lightpath Space
– locates the the re-routing service for the NE
– performs the re-routing
– may be performed as part of a transaction

• performs the task of creating or deleting VLANs on respective NEs
• retrieves the switch request entry from the CA*net 4
Lightpath Space
– locates the the VLAN service for the NE
– performs the switching
– may be performed as part of a transaction

• source of events or alarms of interest
– CA*net 4 Lightpath cross connect devices and connected edge devices
• a set of agents is envisaged to interact with the status service of the ONEs and the NEs
– more can be added as required
• inserts remote event entries into the CA*net 4
Lightpath Space

• other agents will be notified of the event if it had registered interest
– a lightpath agent for example, will want to be notified if an end-to-end lightpath is down
• events of interest will be identified as the realization of this architecture evolves
– in parallel the status service for the ONE and the NEs will evolve

• a grid service instance created by the Lightpath Grid
Service factory
• recursively behaves as a factory to create a corresponding
Lightpath agent
• intermediary between the external Grid Services façade and the internal Jini/Javaspace implementation
• similar to the Double Agent in Cisco’s Scalable
Infrastructure (SI)
– speaks protocol (grid services) and speaks Space

• conveys a lightpath provisioning request by writing a
Lightpath Provisioning Request entry into the CA*net 4
Lightpath Space
– similarly, a Lightpath Deprovisioning Request to teardown the lightpath
• transient service created with a specified lifetime
– assume that the grid service minimum acceptable lifetime upon creation is greater than the requested lease duration

• a factory which creates instances of Lightpath Service
Agents upon invocation from Grid appplications
• simple factory hosted on a J2EE or SunOne environment
• assume that the grid service location is well known

1)
2)
3)
4)
5)
The Grid app sends a request to create a Lightpath Service Agent
Lightpath Service Agent is created by Lightpath Grid Service
Grid app communicates with the
Lightpath Service Agent via returned GSR
Lightpath Agent instance is created by the Lightpath Service
Agent
Lightpath Service Agent and
Lightpath Agent communicate through CA*net 4 Lightpath
Space

• example of a request
<element name=''lightpathProvisioningRequest''>
<complexType>
<sequence>
<element ref=''requestorID''/>
<element ref=''sourceAddress''/>
<element ref=''destinationAddress''/>
<element ref=''bandwidthRequest''/>
<element ref=''leaseDurationRequest''/>
</sequence>
</complexType>
</element>

• consider the scenario of an end-to-end lightpath across multiple national R&E networks
– a requested lightpath terminates with endpoints in both domains
– the originating Lightpath agent does not have visibility into the adjacent Lightpath Space
– assuming agreements and policies are in place, it may be feasible to advertise lightspan entries from one
Space to another

• InterSpace Agent
– intermediary between Lightpath Spaces
– re-advertise lightspan objects from one Space to another
– copies entries intended for the adjacent Space from the current Space, eg cross connect objects
– similar to the Betweener Agent in Cisco’s SI
• Peering Lightpath Agent
– recast requests which may not be recognized due to ownership attributes as originating from a surrogate

– Java Swing application designed to interact with the partitioning service and the status service of an ONE agent
– permits an authorized user to partition an ONE by ports and STS channels at a port
– Recursive delegation
• national, regional, institutional, departmental

• adopting an agile development process based on some core principles of XP
• small team
• paired programming in parallel
– 2 teams (Carleton U, U of Alberta)
• code simply and elegantly, test often, release frequently, and add functionality and complexity incrementally
• incremental design

Core Development Team
Wade Hong (Carleton U, Technical Lead)
Jim Carleton (Carleton U)
Bryan Caron (UofA)
William Burris (UofA)
Technical Consultant
Shikharesh Majumdar (Carleton U)

• Collaborating with MonALISA (Monitoring Agents in a
Large Integrated Services Architecture), an agent-based realtime network monitoring system using JINI/Javaspaces for emerging Grids - Harvey Newman, Caltech
• Peering Agents for OIXes such as StarLight - Oliver Yu,
UIC
• Developing a UNI-C client interface to the ONS15454 -
Malathi Veeraraghavan, UofVirginia

xiong@physics.carleton.ca