WO2001010088A1 - Network control architecture for user control of network - Google Patents

Abstract

Network resources are modeled and implemented as software objects. Preferably, the network topology and lists of routes between network nodes are also stored. Those objects are accessible to the connection controllers in the user domain. The connection controllers get the object references corresponding to network resources through the Controller Mapping Service and the CORBA naming service or an equivalent service. Then the connection controllers in the user domain coordinate the network resources and realize customized networks services. To reuse the resources that were not properly released by user controllers, a garbage collection mechanism runs networkwide.

Description

Network Control Architecture for User Control of Network

Resources

This application claims benefit and priority of U.S. Provisional Application No. 60/146.492. filed July 30, 1999. This related application is incorporated herein by reference.

Field of the Invention

The present invention is directed toward a network control architecture that allows users to control the network resources and thus enables network service customization by the users directly independent of network providers or network equipment vendors.

Background of the Invention

Telecommunication networks have evolved substantially over the last decades. Prior to mid 1960s, the service logic was hard-wired into the switching systems. The network operator had to request from the switch vendor new service features. The vendor developed these and provided them on new switches with new hard-wired functionality. This process was very time consuming and cumbersome, particularly for heterogeneous networks that included switches from multiple vendors.

In the mid-1960s, stored program control (SPC) switching systems were introduced. SPC was a major step forward because service logic became programmable and. as a result, it was easier to create and deploy new services.

However, as the number of services started to grow, the introduction of new services became increasingly more difficult because of the dependency between the service and the service-specific logic. The service logic concept was not modular - service logic that was used for one service could not be used for another service. The architecture of telecommunication networks took a major leap forward in the mid-1970s with the introduction of the common channel signaling network (CCSN), or SS7 network for short. Signaling system number 7 (SS7) is the protocol that runs over the CCSN. The SS7 network consists of packet data links and packet data switching systems called signaling transfer points (STPs). The SS7 network is dedicated to support the call setup or signaling information. Examples of signaling information include the permission for the call setup, whether the called party was busy. etc. The signaling traffic in this network is physically separated from the common trunks and switches that transport the voice information.

During the mid-1980s, service providers began requesting features that met the following objectives:

• rapid deployment of services in the network,

• vendor independence and standard interfaces,

• opportunities for service providers to offer services for increased network usage.

The concept of Intelligent Network 1 (IN/1) was developed to meet this challenge. The introduction of the IN/1 marked the first time that service logic was external to switching systems and located in databases called service control points (SCPs). Two services evolved that required IN/1 service logic — the 800 (or Freephone) service and the calling card verification (or Alternate Billing Service, ABS) service. Because of the service-specific nature of the technology, these services required two separate SCPs. In order to communicate with the associated service logic, software was deployed in switching systems. The switching system software enabled the switching system to recognize when it was necessary to communicate with a SCP via the SS7 network. The software-defined "hooks" or triggers are service specific. For example, an 800 service has an 800-type trigger at the switching system, an 800-service database at the SCP. and an 800-service management system to support the 800 SCP. In this service-specific environment, the 800-service set of capabilities cannot be used for other services (e.g., 900 service). Although the service logic is external to the switching system, it is still service-specific. The Advanced Intelligent Network (AIN) was the next step towards providing service-independence in the IN architecture. Following the IN/1 800 service-specific example, the AIN service-independent software has a three-digit trigger capability that can be used to provide a range of three-digit services (800, 900, XXX, etc.) as opposed to 800 service-specific logic. Likewise, the SCP service logic and the service management system are service-independent. The basic tenet behind these architectures is the implicit assumption that the Customer Premises Equipment (CPE) has no computational capability and only limited modes of interaction. This assumption eventually translated into a design somewhat akin to a mainframe cluster model where a small number of computationally powerful processors called the Service Control Points are distributed throughout the network and take on the responsibility of the service provisioning for all connected CPEs. As in the mainframe cluster model, the CPEs themselves act solely as the user interface channeling simple user requests and responses into the system. Within the network, dedicated processors sharing specialized monolithic software optimized for efficiency process, coordinate and translate these requests and responses into the necessary data and connections that constitute the service.

The primary deficiency of these architectures is their monolithic view of the sendee creation process. The network operator assumes almost complete control over the decisions pertaining to the design, introduction, and management of the service since it owns the SCPs. By contrast, the users do not have access to network resources and thus the network is essentially a black box to them, as illustrated in Figure 1. The potential diversity and flexibility requirements of user level services and applications in ATM networks far exceed that of typical AIN services demanding a more open environment for design, installation, and operation. The simple user network interface (UNI) depicted in Figure 2 is difficult to extend and was never designed for these requirements. As a result, third party involvement in service programming is limited to customizing only a small set of operational parameters.

The capabilities of modern computer systems have advanced beyond the stifling limitations imposed by these early architectures. Computer engineering has advanced to the point where, intelligent and cheap CPEs are available (for example, PCs and PDAs). Industry standards exist for implementing platform independent distributed component-based software (e.g., CORBA). These provide an excellent infrastructure for dealing with problems of programmability, portability, maintainability and reusability in the user domain. Fundamental resources required for the transport service to be realized include addresses (name space), bandwidth, and buffer space. Addresses

The desunaπon or the receiver of the information flow should be identified Unless there is only one possible destination (when there is no need for identifier), the destination should ha\ e a unique identifier For example, there are a large number of telephones in the w orld. each of which is identified by its number Similarly, the IP address identifies the port of the network nodes in the Internet

In the case of circuit-switching networks, a dedicated circuit is allocated to an information flow , hich appears to be a single link connecting the sender and the receπ er Thus, the information flow is identified by the circuit from hich it is received and then it is forwarded along the circuit. Since the association between the miormation flow and the circuit is set b\ physical means such as time slot or frequency slot, there is no need to put any identifier in the information itself The circuit identifier plays the role of the information flow identifier

For a packet-switching net ork, information is transported m a packet and there is no dedicated circuit for an information flow Therefore, each packet should contain an information flow identifier that determines where it should be forw arded For the IP protocol, the IP packet contains the IP address of the destination node and the router finds the neλt node where the packet is to be forw arded from the routing table The routing tables tells which is the next node for a gι\ en destination address In the ATM protocol, each cell contains also its information flow identifier, but the information flow identifier is not the ATM address of the destination node The ATM switching table tells where the cell is forwarded for a given information flow identifier Such a table is shown in Figure 3 The ATM protocol defines t o kinds of information flow s YC (urrual channel) and VP (\ irtual path) YCI stands for

contain multiple VC flow s Thus, a VC is identified as a set of a VCI and a VPI w hile a \T is identified as a VPI

Identifying the destination is the first step of transport service and the address and the information flow identifier is the key information associated w ith it The addresses and the information flow identifiers are called "names" hereafter Name space is a limited resource of the network Bandwidth and Buffer Space

Bandwidth is the information transport capacity of the link. For example, an OC3 link is capable of transmitting information up to 155Mbps. Typically, plural information flows share a single link, a process that is called multiplexing. The portion of the link^'s bandwidth that is assigned to an information flow limits the maximum transport rate of the information flow on the link. In packet-switching networks, the packets are stored in the buffer and transmitted when each output link is available. How much buffer is available for an information flow affects the transport quality of the information flow such as packet loss rate. There are many ways of allocating bandwidth and buffer space, which determine the quality of the transport serv ice for each information flow. If there is no partitioning of those resources, so that all resources are shared based on the packet arrival order, the network offers a "best-effort^" service, and quality of service (QOS) cannot be guaranteed.

The present invention includes the recognition that address space, bandwidth. and buffer space are key classes of network resources. Manipulation of these resources is the foundation of service creation in the network.

Summary of the Invention

The present invention comprises an architecture for manipulating key network resources of a connection-oriented network, that is. naming, bandwidth and buffer space, under user control. Users have direct control over network resources so that network services can be created on a local level, instead of solely on the network provider level.

The invention allows the user controllers to access the netw ork resources and manipulate them to realize network services. In this way. the user does not solely depend on the provider for service customization, but can develop and deploy her own service to meet her specific needs.

To allow a user controller-level access to network resources, a system according to the invention models network resources as software objects with predefined interfaces through which the controllers in the user domain can manipulate the network resources. Figure 4 depicts the diagram of an object where a handle 10 is attached to an oval shape 12. The handle represents the interface of the object.

≤ This architecture allows creation of a network of software objects representing the transport resources of the network as well as information about network resource objects such as mapping between transport nodes and the associated software objects and network-wide information such as topology and choice of routes. This information helps the user controllers find proper software objects representing transport resources. The network of software objects representing transport resources and the software components providing network-wide information comprise the basic network infrastructure for user control of the network resources.

The transport network nodes are represented through software components that do not necessarily reside at the associated network node. Typically, the software components have different identification schemes from transport network addresses. The software components requiring network resources should get the object reference of the software object representing the resource. Therefore, a function that takes the transport address and object type and returns the object reference is preferably provided. The object reference is created at run-time and its implementation is specific to the object system framework, the programming language, the platform, and so on. For programming purposes, it is generally preferred to have a static name that identifies an object, which is called an object name. A service providing mapping between an object's object name and its associated transport address may then be created. Load balancing can be realized by manipulating this Controller Mapping Service.

The software components providing connection control functionality are called connection controllers. Connection control is an important element of network service creation. The invention places connection control functionality at user hosts. in contrast to the ATM forum architecture where it is embedded inside the switch boxes. In other words, the connection control software can be developed and deployed by the customers independently of the network providers or the switch vendors. The connection controllers residing at hosts establish or terminate connections as required by the user applications, by talking to the software objects representing network resources and other components of the network infrastructure. This architecture is in contrast to the traditional architecture, where the connection controllers reside in the provider domain and are managed only by the provider. In the latter model only the provider can develop and customize services, while the users can only request their services or change at most certain parameters defined by the network provider.

To provide the QOS requested by applications, a portion of network resources may be exclusively allocated to each connection. At least the VCLVPI values and the switching table space must be allocated to each connection for ATM networks. Since the network resources are open to user control in the architecture of the present invention, and the equipment and software in the user domain are considered highly vulnerable to various faults, it becomes desirable to maintain integrity of resource allocation over the network and minimize resource waste due to unused connections. A garbage collection mechanism is thus preferably designed and used to collect resources wasted for unused connections. In one embodiment of the invention, the SYNC protocol is used to synchronize the connection states on connection-oriented networks. The garbage collection service compares the names allocated for connections and the switching tables, if any, between neighbor transport nodes, finding mismatches, and removing the mismatching switching table entries and allocated names. The protocol is preferably based on a distributed algorithm where there is no central coordinator.

This brief summary has been provided so that the nature of the invention may be quickly understood. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiment thereof in connection with the attached drawings.

Brief Description of the Drawing

The invention is described with reference to the several figures of the drawing. in which.

Figure 1 shows a traditional "black box" network configuration:

Figure 2 shows a network interface giving limited user control:

Figure 3 shows an example of an ATM switching table:

Figure 4 shows a schematic of a software object according to the invention; Figure 7 shows the relationship between node servers, node controllers, and transport nodes within two parallel signaling systems: Figure 6 show s a schematic of a simple network with multiple paths bet een hosts.

Figure 5 shows two types of transport nodes and associated objects.

Figure 14 sho s a CMS mapping table for load balancing, Figure 8 show s the registration of controllers and node sen ers at the controller mapping service.

Figure 10 shows communication links among software objects to set up a communication path.

Figure 11 shows communication links among software objects to release a communication path in response to a request by the originating application.

Figure 12 shows communication links among software objects to release a communication path m response to a request by the target application.

Figure 13 shows a network configuration in which garbage connections exist

Figure 9 show s the registration of local applications with node controllers Figure 15 shows message exchange between connection synchronizers

Figure 16 sho s a network containing garbage connections that need to be released.

Figures 17a-17j show the steps performed to remove the garbage connections of Figure 16

Detailed Description

The present invention can be applied to any connection-oriented net ork {e g . circuit-switching networks) but for the sake of brevity, the following descπpπon assumes that an ATM network is used ATM networks are considered to meet the requirements of broadband networks that flexibly support the QOS requirements of muramedia applications

The invention is applicable to many configurations of ATM networks w ith \ aπeties of equipment and multiple administrative domains, etc In this discussion, we confine our illustration to an ATM network consisting of two bnds of equipment PCs as hosts or terminals and ATM switches Those stalled in the art will readih understand how this discussion may be extended to other types of networks and to networks having other types of nodes The ATM network in the following illustration

« has plural PCs that are connected through plural ATM switches with arbitrary topology.

The transport senice for signaling messages is distinguished from that for the user application traffic. Various kinds of transport technology can be used for the signaling messages. In one preferred embodiment of the invention. IP (Internet Protocol) is used. IP has many advantages such as wide availability, well-known programming environment, robustness, and relatively simple management requirements. There are many ways of supporting IP connectivity. For example, there may be a separate physical network where a PC has at least two network adapter cards: one is an ATM card and another is an Ethernet card. Then the IP can work without depending on the ATM networks. (Such a configuration that uses different wires in the same cables to carry different signals is described in copending and commonly owned U.S. Patent Application No. 09^/347.241. filed July 2. 1999. which is incorporated herein by reference). Another way is using the classic IP over ATM or similar technology that uses the ATM network as the IP^'s underlying protocol. While any configuration that allows concurrent signaling and user application traffic may be used, it is assumed in the following illustration that the machines used for signaling have IP connectivity.

The control system of the network is realized as a distributed software object system. Controlling the transport network requires message exchanges between these objects. Although IP provides a raw transport sen'ice that may be successfully used to implement the system of the invention, it is preferred to take advantage of advanced distributed object system technology (e.g.. CORBA. DCOM. or Java RMI). While any of these technologies can be used to implement the present invention. CORBA is chosen for the preferred embodiment illustrated here. CORBA is widely supported and available on various platforms including Windows NT. Windows 95/98. Solaris 5.x. etc.

Architecture Overview

ATM transport equipment includes two basic types: ATM hosts and ATM switches. An ATM host may be, for example, a PC with at least one ATM adapter card through which user traffic is transmitted or received. The host plays a role of traffic source or sink. An ATM switch has plural ATM interface ports and forwards ATM cells received from one port to another port that is directed toward the destination of the cells.

The ATM host and the ATM switch have transport resources such as buffer and bandwidth and the name spaces (e.g., the VCI tables, the VPI tables, and the switching tables). Establishing a connection is a process of acquiring these resources along the path on the ATM network. The resources and control capability on those resources are modeled as software objects and the ATM switch server and the ATM host sen^der are the software processes containing those objects, respectively, for the ATM switch and the ATM host. Each ATM switch and each ATM host has an associated ATM switch server or ATM host server, respectively, in a one to one mapping relation mode. Figure 5 shows the ATM network and associated servers w ith the mapping relation among them. We use the terms "ATM switch" and "switch" interchangeably hereinafter for the sake of brevity. The same convention applies to other terms with similar patterns.

Each switch and host is assigned at least one ATM address. However, the switch or the host does not have to handle the ATM address during its transport operation. This ATM address is used to represent the node in topology or route information. It is also used for connection control to identify the source or destination node.

These switch sen'ers and host servers compose a resource pool. Each node sen^der, that is. each switch or host server, provides a view of the resources status and access to the resources of its own associated node only. While the node servers provide local views for each node, service creation also generally requires global views on the network. One desirable view is the topology of the transport network and the routes between nodes. In the embodiment described herein, this information is provided by the Topology object and the RouteRepository object.

Other important global information includes the mapping between the transport address of the node and the object identifier of the node object, that is, the switch object and the host object. The mapping is used during connection control, because the topology or the route information is based on the transport addresses while the node sen^der is identified with the object identifier rather than with the

|o associated transport address. In the preferred embodiment described, the CMS (Controller Mapping Service) object provides the mapping information.

The infrastructure for the network control supporting the user control of the neuvork resources is depicted in Figure 6. The infrastructure comprises the following elements:

• The actual network equipment such as switches 14 and hosts 16

• The software objects representing the network equipment such as switch sen ers 18 and the host servers 20

• The software objects providing global view of the network such as Topology objects 22 and RouteRepository objects 24

• The software objects providing the relation information between the other software objects and the actual network equipment 26

There are many ways the switch sen^der interacts with the switch to control and monitor it. In our preferred embodiment, the switch sen'er resides outside of the switch and communicates with the switch through ATM. Even in this scheme. various protocols may be used between the switch sen'er and the switch. The qGSMP (QOS General Switch Management Protocol) is used in this preferred embodiment. The qGSMP provides status information for the switch and allows connection establishment with certain QOS requirements and release. Any protocol used preferably provides at least information about the resource states of the sw itch and methods of connection control. The present invention is not restricted to any specific details of the protocol design.

The software objects constitute a distributed object based system. There are various distributed object system frameworks such as CORBA, DCOM and Java RMI. While the current invention can be used with any distributed object system framework. CORBA is used for the preferred embodiment of the current invention. CORBA is an industry standard supported by many companies and available for many platforms. CORBA provides uniform inter-object communication among objects implemented in different programming languages and residing on different platforms. In the CORBA framework, each object comprises a certain set of interfaces that are specified using the IDL (Interface Definition Language) from the OMG (Object i i Management Group). The objects see each other as local objects even though some of them are remotely located in the CORBA framework. The communication between objects is initiated by calling the functions defined in the interfaces. Each function call is translated into a request message and sent to the destination object. The message formats and the translation rules are all defined in the OMG CORBA specification. The CORBA messages are exchanged using the TCP/IP protocol suites in the prefeπed embodiment.

Each object has a unique object identifier in CORBA. If an object A wants to talk to an object B. the object A should get the object reference of the object B using the mechanism specific to each CORBA implementation. For example, the omniORB from AT&T uses the name senice of the CORBA implemented in its own way since the CORBA sen ce specification provides the framework but leaves implementation details to the choice of the implementer. As another example, the Orbix from IONA Technologies. Inc. uses a proprietary mechanism called the bindQ function with proprietary identifiers consisting of. so called, the marker sen'er name and the host name.

The connection senice can be realized on top the infrastructure described above. There can be various types of connection controllers providing different kinds of connection services. The details of how each connection controller is designed and implemented are not critical to the present invention. A VC Controller is illustrated for the sake of brevity as an example of a connection controller working in the architecture designed in the present invention, which provides unicast VC connections.

One VC Controller resides at each user's PC in the user domain. The connection establishment procedure of the invention comprises the following steps:

(1) The application requests a VC from the VC Controller residing on the local host.

(2) The VC Controller refers to the RouteRepository to get the pre- calculated route between the origin node and the target node (3) The VC Controller refers to the CMS to get the object identifier of the node server corresponding to the first node on the route (4) The VC Controller gets the object reference of the node server and requests the resources for the requested connection

(5) The VC Controller repeats steps (3) and (4) for each node until reaching the last node (the target node) (6) The VC Controller returns the result including the connection identifier consisting of the port number, the VCI and the VPI at both of the origin node and the target node to the application

This procedure represents a typical scenario when the connection establishment is successful and shows the interaction among the objects in the invented architecture.

Components

Transport Equipment

A packet-switching technology is used in the ATM switching platforms, where the packet consists of a 53 byte "cell." The ATM switching platforms form a connection-oriented network in which a connection is created prior to the transport of cells. At connection setup time, required network resources are acquired to provide the QOS specified by the application program as well as connectivity.

The ATM protocol defines two types of connections: VCs and VPs. Each cell has a VCI and a VTI. When an ATM switch receives a cell from a port, it reads the VCI and the VTI of the cell, recognizes the input port number and checks the switching table. Figure 3 depicts an example of the switching table. The switching table contains the output port number 30. the output VCI 32 and the output VPI 34 given the input port number 36. the input VCI 38 and the input VPI 40 per connection. If the connection is a VP, then the VCI fields are ignored and the switching is done only based on the VPI fields. Using the information stored in the switching table, the switch changes the values of the VCI and the VPI field of the cell into the output VCI and the output VPI and transfers the cell into the queue of the output port. Each connection may have a different service contract for QOS (quality of service), and the switching table may contain information related to QOS requirements 42. Each queue is associated with a QOS specification because the

/ 3 buffer size and the scheduling policy for the multiplexer result in different QOS at the switch.

The ATM protocol specifies the size of the VCI and the VPI fields in a cell, but the actual ranges of the VCI and the VTI values allowed on a port of an ATM switch depend on the switch implementation. Typically, the actually allowed ranges are much smaller than the maximum ranges specified in the standard protocol. One physical port of a switch may support both incoming and outgoing flows (duplex) or just one of the two directions (simplex). Since incoming cells are differentiated from outgoing cells, each direction is associated with one VCI and VPI range. Therefore. there are two VCI and VPI tables for two-way ports, one set for each direction.

The host has at least one ATM adapter card (or other means of communicating with the network). Each card and its device driver compose an ATM port. The basic functionality of the ATM port of the ATM host is the same as that of the ATM switch. The main difference between the ATM host and the ATM switch is that the ATM host does not have switching capability and thus has no switching table.

Resource Servers

To allow the controllers in the user domain to access the resources inside the transport equipment, all resources are modeled as software objects with pre-defined interfaces representing attributes and allowed operations. Therefore, at least one software object 18. 20 is associated with a network node 14, 16 to represent the resources of the node, as shown in Figure 7. The object contains the VCI and the VTI table, the switching table, the buffer space and the bandwidth. By accessing these resources separately, a connection senice can be achieved. However, it is more convenient to define an object that provides aggregated functionality. We define also an interface representing the host or the switch as a whole, which are the ATM Node interface and the ATM Switch interface, respectively.

The ATM Host object has the ATM Node interface containing a set of functions, which may include:

• Setup an outgoing VC termination at a port • Release an outgoing VC termination at a port

• Setup an incoming VC termination at a port η Release an incoming VC termination at a port

Setup a duplex VC termination at a port

Release a duplex VC termination at a port

Change the service specification of an existing VC termination

Setup an outgoing VT termination at a port Release an outgoing V termination at a port Setup an incoming VT termination at a port Release an incoming VT termination at a port Setup a duplex VP termination at a port • Release a duplex VT termination at a port

Change the sen ice specification of an existing VP termination

Get all the allocated YCI/VPIs in the outgoing direction at a port Get all the allocated VCLVTIs in the incoming direction at a port

The ATM Switch object has the ATM Switch interface that preferably mheπts the functions of the ATM Node interface The ATM Switch interface also has additional functions, which mav include

Setup a simplex VC segment between two ports

Setup a duplex VC segment between tw o ports

Release a V C segment between two ports

Release a multicast VC tree segment as a hole

Change the sen ice specification of an existing duplex \ C segment

Setup a simplex VT segment between t o ports

Setup a duplex VP segment between two ports

Release a VT segment between two ports

Release a multicast VT tree segment as a whole

Change the service specification of an existing duplex VT segment

Setup a virtual network (VN) • Release a VN

• Change the service specification of an existing VN

We can see that ATM Switch interface and ATM Node interface include functionality to control VC and VP connections at the single node level.

Topology Object and RouteRepository

A network is modeled as a pool of switches and hosts connected in a certain topology. When a connection is requested, the connection controller needs to know whether the destination is connected to the network, whether it is alive, and whether there is a proper path to the destination in the network. In particular, the connection controller needs to know the resource status at each network node along the possible paths satisfying certain QOS requirements. Otherwise, connection establishment may require many unsuccessful tries before acquiring available resources. This can burden the connection senice and result in poor performance.

The Topology object is a repository that contains the topology of the network and other state information about each link, such as quantities of available capacity. The Topology object interface includes functions for getting a whole topology, links of a node and its neighbor nodes' transport addresses, etc. While each node sen er provides maintains detailed information on each node, the Topology object provides a global view of the network resources. The RouteRepository maintains a list of possible routes between a pair of nodes and categorizes routes based on certain conditions. An important classification is based on the affordable QOS by checking the available resources along the routes. For example, several routes can be categorized as one group that satisfies the requirement for peak rate of 5 Mbps. However, it is rarely possible to maintain accurate information for all the nodes in real time for large networks. Therefore, the information in the RouteRepository provides a hint for the proper path, if any, and includes important information needed for establishing connections. Although it is possible to construct a new RouteRepository or find a proper path directly from the Topology object, it is convenient and time saving to have the RouteRepository prepared in advance.

IC The Topology object and the RouteRepository maintain their information using the transport addresses of the nodes, rather than identifiers of the node sen-ers. Therefore, a route obtained from a route query to the RouteRepository contains a series of network addresses for the nodes along the route.

Controller Mapping Service

The information in the Topology object and RouteRepository is associated with the transport addresses of the transport network nodes. The transport network nodes are represented through software components that do not necessarily reside at the associated neuvork node. Typically, the software components have different identification schemes from transport neuvork addresses. The software components requiπng neuvork resource should get the object reference of the software object representing the resource. Therefore, a function is needed that takes the transport address and object type and returns the object reference. Such a function can be expressed as the following mapping relation:

F : (transport address, object type, ...) => (object reference) (1)

The object reference is created at run-time and its implementation is specific to the object system framework, the programming language, the platform, etc. It is determined at least in part by factors that are decided at run-time such as the TCP port number used by the software object. It is hard to manage such dynamic information and associate it with any semantics meaningful to users. Therefore, it is desirable to have a static name that identifies an object, which is called an object name hereafter. Typically, a distributed object system has a service providing the following mapping:

G : (object name) => (object reference) (2)

The details of mapping from object names to object references are specific to each distributed object system. To provide an overview for the CORBA system, an object name consists of a sequence of elements, each of which is again composed of two components: kind and value. The CORBA naming service returns the object reference corresponding to the given object name. Depending on the ORB implementation, there can be equivalent functions or services. For example, the Orbix from Iona Technologies. Inc. uses a proprietary object identification scheme that consists of the marker name, the server name, and the host name. Their bind function then returns the corresponding object reference. That is,

Orbix bind : (marker name, server name, host name) => (object reference ) (3)

In the present invention, the mapping from the (transport address, object type,

...) to the object name is provided by the Controller Mapping Service (CMS). That is.

CMS : (transport address, object type, object name type, ...) => (object name) (4)

Additional parameters can be used in the CMS. including the object name type. Since in some embodiments there can be plural types of object names, the CMS preferably supports plural types of object names. In such systems, the object name type is specified in the request for the object name. Consecutively executing the CMS and mapping "G^" above yields mapping 'F' above.

The CMS object maintains the mapping database and contains the following functions in its interface:

• Get object name

• Set object name

• Remove object name

Multiple software components can be associated with the same transport address. If an application program wants to set up a connection from node 100 to node 200 in a neuvork with plural connection controllers, it must determine which connection controller to communicate with. This kind of information can be found using the CMS. The CMS can thus play the role of coordinator between objects and software components using the objects in a dynamic fashion. As an extension of the CMS functionality, load balancing among multiple sen'ers can be achieved by having the CMS return the object name of each sen'er in a predetermined or dynamically calculated proportion. The CMS interprets a predetermined mapping rule representation in order to perform load balancing. An

I S example of such a mapping table that supports multiple object names per a set of (transport address, object type, name type) and categorization of users who are authorized to use the objects is shown in Figure 8. In the mapping table, (transport address =100. object type = Switch, name type = xbind) has Uvo corresponding object names: S 100_1 and S 100_2. The exact values in the table are for purposes of example and are not to be construed as limiting. Two object names are available at transport address 100 for general users, that is, any user requesting the information. Each of the object names will be returned for half of the total requests to the CMS, as shown in the column "Load Percentage." The mapping table can take any of many forms, such as a relational database, a directory, a file, etc.

Connection Controller

The main role of the connection controllers is establishing and tearing down connections as requested by application programs or the like. The resources are distributed in an isolated fashion until the connection controllers coordinate them to provide end-to-end connections with certain QOS. The connection controllers thus sen'e as a kind of coordinator. In addition, they can be considered as the agents of the neuvork users who want to use the network resources. There may be various connection service types such as VC (unicast virtual channel). MC (multicast virtual channel), VT (unicast virtual path), and VN (virtual neUvork).

VC Controller

A VC Controller 60. 64 resides at each user host 66. 72 in this preferred embodiment. Its major functionality is to establish and tear down point-to-point VC connections. Each VC Controller mainly serves the users at the local machine. Therefore, there are plural VC Controllers in the network that provide the same functionality. This architecture improves the reliability of the neuvork as compared to a single centralized VC Controller.

The VC Controller in the preferred embodiment contains the following functions in its interface:

• Setup a simplex VC • Setup a duplex VC • Terminate a VC

• Change attribute values of a VC

Integrating the Architecture in its Run-Time Environment Getting an Object Reference The CORBA Naming senice is used in the preferred embodiment to get the object reference based on the object name. The CMS is used to get the object name of the object representing a specific resource as described earlier. Those senices respond to the query based on the mapping table that each maintains.

The mapping table is filled automatically in the preferred embodiment. Each object is assigned an object name by the user or the network administrator. Each object gets the contact information to the name server and the CMS object from the configuration information. Then it registers its object name and the object reference information to the name sen'er. and also registers its object name with the transport address, resource type and other additional information as needed. In the preferred embodiment, each node sen'er and the VC controller registers itself at the CMS as soon as it boots up. Figure 9 shows the node servers 66, 68. 70, 72 and the VC controllers 60. 64 registering at the CMS object. The CORBA naming senice is used in this embodiment to get the object references. Therefore, all the CORBA objects to be called through any CORBA function call should also register themselves at the naming server.

In an example scenario showing how an object reference is resolved, a VC Controller gets a connection request to set up a VC from node 100 to node 200. w here 100 and 200 are transport neuvork addresses. The VC Controller gets from the RouteRepository a route from node 100 to node 200. The VC Controller sends a query to the CMS for the object name of the node object for the address 100. The query asks, "what is the object reference of the object whose type is 'Node^' and the associated address is ' 100^'?" Then the CMS server returns the object name to the VC Controller. Finally, the VC Controller requests an object reference to the naming sen'er. saying "This is the object name. Please let me get the object reference of the object". The naming sen'er then returns the object reference. This short example assumes everything goes well and no errors occur during the process. λ Establishing a VC

To establish a simplex VC. for example, going through a switch, a VCLΛTI pair should be acquired at the input port and another VCI/VPI pair should be acquired at the output port. When a certain QOS is requested, the system should check whether the output port has enough buffer space and bandwidth to meet the required QOS and then an appropriate amount of buffer space and bandwidth may be resen ed for the connection. An entn' is then setup in the switching table for the new VC. This whole process should be repeated along the path to the last switch connected to the target host. The VC setup procedure is shown in Figure 10. The steps of the procedure are as follows:

( 1) The origin application 62 requests a VC service from the local VC Controller 60 with parameters that may include:

• Target host address • Target application identifier

• Origin application identifier

• Direction of the VC (for a simplex VC)

• Senice specification

(2) The origin VC Controller 60 contacts the CMS object 26 and gets the object reference of the target VC Controller 64.

(3) The origin VC Controller 60 contacts the target VC Controller 64 and checks whether the target application 74 is available.

(4) The origin VC Controller 60 contacts the RR object 24 and gets a path from the origin host to the target host. The origin VC Controller 60 keeps a copy of the path for future use.

(5) The origin VC Controller 60 contacts the CMS object 26 and gets the object references of the Host objects 66, 72 and the Switch objects 68. 70 of the nodes in the path.

(6) The origin VC Controller 60 contacts the Host object 66 of the origin host and sets up a VC termination.

SL\ (7) The origin VC Controller 60 contacts the first intermediate Switch 68 object and sets up a VC at the corresponding switch.

(8) The origin VC Controller 60 repeats step (7) for each switch in the path. (9) The origin VC Controller 60 contacts the Host object 72 of the target host and sets up a VC termination.

(10) The origin VC Controller 60 contacts the target VC Controller 64 and notifies it of the VC termination at the target host with the information including target application identifier, the port number and VPI/VCI pair. (1 1) The Host object 72 of the target host sends an event message to the registered objects including the target VC Controller 64. The event message says that a VC termination is set up successfully and includes the port number and its VPI/VCI pair.

( 12) The target VC Controller 64 sends an event message to the target application 74 notifying it of the new VC termination with its port number and its VPI/VCI pair.

This scenario of VC setup procedure accommodates a peer-to-peer application model as well as a centralized application model. By "centralized application model," we mean an architecture where a single intelligent sen'er takes care of all controls while dummy clients can just send requests to the intelligent server. By "peer-to-peer application model," we mean an architecture where each party can perform a part of control tasks.

Terminating a VC

Network resources are reserved for VC connections in switches and hosts. It is important therefore to release the connections properly whenever they are no longer needed. We show two cases of VC release: one initiated by the origin application and the other initiated by the target application.

Figure 11 shows the procedure of VC release initiated by the origin application 62. The steps of the procedure are as follows:

2 • The origin application 62 requests that its local VC Controller 60 release the VC, specifying the origin application identifier, the VC's port number and VPI/VCI pair of the local termination.

• The origin VC Controller 60 consults its VC connection repository and finds related information, including the path of the VC and target application identifier, assigned VPI/VCI pair at each link of the nodes along the path, etc. The origin VC Controller 60 finds the reference to the target VC Controller 64 in its cache of object references for VC Controllers. • The origin VC Controller 60 notifies the target VC Controller 64 that it will release the connection, specifying at least the port number and the VTIΛ^'CI pair of the VC termination at the target host.

• The target VC Controller 64 notifies the target application 74 that the VC w ill be terminated. • The origin V Controller 60 requests that the local Host object 66 release the local VC termination.

• The origin VC Controller 60 requests that the next Switch object 68 of the path release the VC.

• The origin VC Controller 60 repeats the previous step for each switch in the path.

• The origin VC Controller 60 requests that the target Host object 72 release the VC termination.

• The target Host object 72 notifies the target VC Controller 64 that it has released the VC termination.

Figure 12 shows the procedure of VC release initiated by the target application 74. The steps of the procedure are as follows:

• The target application 74 requests its local VC Controller 64 to release the VC specifying the target application identifier, the VC's port number and VPI/VCI pair of the local termination.

Λ3 • The target VC Controller 64 looks up its VC connection repository and finds related information. The information includes the origin host address, the port number and the VPI/VCI pair of the VC termination at the target host. The target VC Controller 64 refers the CMS object 26 to find the reference to the origin VC Controller 60.

• The target VC Controller 64 requests the origin VC Controller 60 to release the connection specifying the port number, the VPI/VCI pair of the VC termination at the target host. The target VC Controller 64 does not simply initiate termination because it does not have the record of the path, allocated VPI/VCI pairs, etc., which are needed to release the VC.

• The origin VC Controller 60 notifies the origin application 62 that the VC will be released.

• The origin VC Controller 60 refers the CMS object 26 to find the references of the node controllers along the path.

• The origin VC Controller 60 requests the local Host object 66 to release the local VC termination.

• The origin VC Controller 60 requests the next Switch object 68 of the path to release the VC. • The origin VC Controller 60 repeats the previous for each switch of the path.

• The origin VC Controller 60 requests the target Host object 72 to release the VC termination.

• The target Host object 72 notifies the target VC Controller 64 of releasing the VC termination

The origin VC Controller 60 may give the information enough for releasing the VC to the target VC Controller 64 and request that the target VC Controller take care of release. The target VC Controller 64 then executes a set of steps analogous to those above to release the connection. This simple negotiation between the origin VC Controller and the target VC Controller can be helpful in a client sener application where the server is the origin application and is heavily loaded. By shifting the VC

M release burden to the target VC Controller (i.e.. the VC Controller of the client host) the burden on the sen'er host can be reduced.

Garbage Collection Procedures

Since any software or device can fail, there arise various situations when the VC connections are not released properly. To alleviate this problem, the neUvork may have garbage connections that are holding unused network resources. Figure 13 shows a situation where a garbage connection exists in an ATM neUvork, where a dotted line represents a garbage connection. In the case of telephone neuvorks. the subscriber line is monitored by the entry switch using physical signals and the entry switch detects access link failure or the terminal device failure.

The TCP protocol of the IP protocol suite provides virtual connections to computer applications. However, at this time it resen'es only local resources at each host and thus it does not cause any garbage collection problem in the neuvorking devices such as switches, even though the host user may suffer from garbage sockets. To solve the garbage socket problem, the TCP protocol has timers measuring time since the last packet sent by the remote peer and releases the time outdated connections. This approach requires configuration of the timers depending on the characteristics of the application. It may not work in some cases, such as applications where data transmission is irregular and may have long pauses. The RSVP protocol of the Internet attaches timers with each flow at the routers and requires refresh messages for each flow where a flow corresponds to a VC in the ATM neuvork. While this system can be effective, it creates a very substantial overhead for the neuvork.

Garbage collection is an important feature of neuvork control and management. There can be failures in any component in the architecture. We consider several possible situations that may generate garbage connections and our measures to clean them up in the material that follows. This listing is not intended to be exhaustive, and analogous measures for similar situations will occur to those skilled in the art. 5 Application Failure

Let us assume that the originating application 62 crashes and the target 74 waits for data. Some receiver applications may decide to stop waiting for data and exit after requesting the VC release, or the application architecture may have some application-level message exchange mechanism that can notify the target application of the originating application^'s failure. However, considering arbitrary applications, it is preferable not to rely on applications to release network connections, because the behaviors of the applications are not predictable. For example, the receiver application may wait for data for a period of hours until the human user comes back. tying up network resources.

When one of application processes crashes or hangs, the application may not initiate the VC release procedure and thus may leave garbage connections in the neuvork. In this situation, there is a need to detect the application failure and initiate the VC release procedure. Our solution is as follows. Each application is registered with the local VC Controller. Figure 14 depicts the application processes 62, 74 registering at their local VC Controllers 60, 64. The VC Controller monitors the state of the registered application. One method of monitoring is to use a kernel service residing on the host. Each application process typically has an identification number that is given to the VC Controller at registration time. The VC Controller checks the process state periodically, for example by using a kernel service. When the VC Controller finds the process is dead or does not exist any more, it initiates the release procedure of the VCs set up for the application process.

.Another solution is polling the applications directly by the VC Controller. The VC Controller sends an event message requesting that registration be refreshed, and then the application process calls the refresh function of the VC Controller interface. In this solution, the VC Controller has a timer for each registered application. The receiver application is notified by the VC Controller when its VCs are released. Then the receiver application exits.

<?ς VC Controller Failure

If the oπgm VC Controller 60 crashes, no process will know the paths of the VCs set up by the oπgm VC Controller One way to mitigate the effects of such a crash is to let the oπgm VC Controller make logs of the connections set up by itself on a permanent storage When the oπgm VC Controller is rebooted, it reads the logs, restores its information about connections and releases the connections properh Howe er, often the logs may be incomplete For example. UNIX operating s stems use disk caches, so the VC connection log file may be lost before it is saved on the hard disk The oπgin VC Controller may also crash while it is setting up a connection and thus may ha\ e no opportunity to wπte a record to the log file The log file may be deleted or rendered unreadable by mistake

Our solution to this problem is the following As mentioned above, each VC Controller 60. 64 is registered m its local Host object 66. 72 Now the Host object 66. 72 monitors the V C Controller 60, 64 using again the process identification number and the EventChannel interface of the VC Controller object That is, the VC

Controller gives its process identification number to the Host object and the Host object checks the process state using a kernel sen ice Alternatn ely, the Host object sends a message requesting that registration be refreshed, and the VC Controller refreshes the registration at the Host object The Host object has a timer for the VC Controller

If the Host object finds that the registered VC Controller is not working propeπv or hangs, it initiates between itself and neighbor Host or Sw itch objects the syncnromzation procedure descπbed below

Host oι

itch Object Crash A Host object or Switch object crash is detected by the routing protocols or similar protocols being used for topology discover}' Upon detection, the neighbor Host or Switch objects start timers When the timers expire, the objects initiate the synchronization procedure descπbed in the following section to the neighbors for the VC termination entπes on the ports connected to the node of the Host or Switch object that crashed

-? 7 Hardware Crash

When a physical line is disconnected or a hardware sw itch crashes, the e\ ent is detected and handled m the same way as the Host or Switch object failure event

To summaπze our solutions for the garbage collection problems, we use momtoπng, timers and the SYNC protocol descπbed in the following section

Application processes. VC Controller objects, Host objects and Switch objects may all be monitored Timers are used to reduce the number of "false alarms," by allowing crashed processes to recover and by limiting unnecessary connection removal The SYNC protocol is used to synchronize the information among the hosts and the switches and to remo\ e garbage connections at the same time

The SYNC Protocol

The SYNC protocol is the protocol used to synchronize the connection states on cormection-oπented neuvorks The protocol functions

compaπng the names allocated for connections and the switching tables, if any, beuveen neighbor transport nodes, finding mismatches, and removing the mismatching switching table entπes and allocated names The protocol is based on a distπbuted algoπthm where there is no central coordinator

Message Descriptions

The software component embodying the SYNC protocol is called the Connection Synchronizer Preferably, there is a Connection Synchronizer for each transport node The protocol has uvo types of messages request and response A Connection tor a transport node sends a request message to the Connection

for a neighbor transport node (a neighbor Connection Synchronizer) Then the neighbor Connection Synchronizer replies to the requester with a response message There are Uvo types of requests as follows

• CHECK REQUEST

• REMOVE REQUEST

CHECK REQUEST is used to request check of consistency of connections to the neighbor Connection Synchronizers For example, as shown m Figure 15. a

46- Connection Synchronizer is attached with a transport node with address 100 and it wants to synchronize the connections through port 1 of the node. The neighbor transport node connected to the port has address 200 and its port number is 2. The Connection Synchronizer for node 100 gets the list of connections through the port from the node sen'er of node 100, finds the neighbor Connection Synchronizer on the port from the Topology, and sends to the neighbor Connection Synchronizer for node 200 the connection list for consistency check. The Connection Synchronizer for node 200 checks the list of connections through port 2 at node 200. The Connection Synchronizer for node 200 replies to the Connection Synchronizer for node 100 categorizing the connections in the CHECK REQUEST message into three groups according to the response types:

• SYNC CONFIRMED

• OUT OF SYNC CONFIRMED

• CHECK FORWARDED

SYNC CONFIRMED means that it is confirmed that the group of connections are in a consistent state.

OUT OF SYNC CONFIRMED means that it is confirmed that the group of connections are in an inconsistent state. That is, there are no matching name allocations or switching table entries for the group of connections in the neighbor node. The expected action is that the Connection Synchronizer that received this response will initiate the procedure to remove those connections.

CHECK FORWARDED means that the neighbor node has matching name allocations and switching table entries for the connections and that CHECK REQUEST messages have been generated and forwarded to the neighbor node^'s neighbor nodes along the paths of the connections. In the example, if the node 200 is a switch and the group of connections go through the node 200 and extend to node 200' s neighbor nodes, the consistency of the connections cannot be declared at node 200. The consistency check should be extended to node 200's neighbor nodes along the paths of the connections. A more concrete example is shown in the following section. The Connection Synchronizer for node 100 should store the information of connections under CHECK FORWARD and wait for information. a^<\ REMOVE REQUEST is used to request that the listed connections in the message be removed. Using the same example for CHECK REQUEST, the Connection Synchronizer for node 200 replies to the Connection Synchronizer for node 100 categorizing the connections in the REMOVE REQUEST message into Uvo groups according to Uvo response types:

• REMOVE CONFIRMED

• REMOVE REJECTED

REMOVE CONFIRMED means that the contained list of connections were removed and if needed, new REMOVE REQUEST messages are generated and. if needed, sent to node 200's neighbors along the path of the removed connections.

REMOVE REJECTED means that the list of connections is not removed and the REMOVE REQUEST was rejected.

A task is defined as a single type of request or a single type of response for a group of connections. For example, the Connection Synchronizer for node 100 sends a task composed of (request type = CHECK REQUEST, connections = cl, c2. c3). The response from the neighbor Connection Synchronizer can contain three tasks such as (response type=SYNC CONFIRMED, connections=c3), (response typeOUT OF SYNC CONFIRMED, connections=c2), and (response type=CHECK FORWARDED, connections=cl). A task with a request is called a request task and a task with a response a response task.

Each request task has a task ID number that is assigned by the Connection Synchronizer sending the request. The number has significance only in the sending Connection Synchronizer. Each response task should contain the task ID of the request task to which it corresponds. Using the task ID, the protocol does not depend on the message ordering in matching the request tasks with response tasks. The final form of task contains the following elements:

• Task ID

• Request/Response Type

• Sub Parameter (optional) • List of Connection Descriptors

3θ The sub parameter is not necessary to the proper functioning of the invention, but adds functionality. One example of its usage is providing more detailed information about the request or response, such as the reason for a REMOVE REJECT. The connection descriptor provides information to identify the connection. It can have different information depending on the underlying transport technology. For example, it can be (VCI. VTI) for ATM switching platforms and (source IP address, source port number, destination IP address destination port number) for RSVT and (flow ID) for IPv6. Therefore, the connection descriptors has the following substructure:

• Connection Type

• Connection Info

The connection type can be ATM VC. ATM VT. IPv6 FLOW. etc.

To show the algorithm more clearly, an example of network with garbage connections and how the SYNC protocol works in the case is shown in the following section.

An Example of the Synchronization Procedure by the SYNC Protocol Figure 16 shows the network with four connections labeled as R, Y, G and O. R. Y. and O are all garbage connections in this example. G is a multicast connection where one branch is a garbage connection. Figure 17a shows the first step of the synchronization procedure, where the

Connection Synchronizer for the first node 100 initiates the procedure by sending CHECK REQUEST task to its neighbor 110. The transport addresses, port numbers, and task IDs are omitted in the diagram for the sake of brevity.

Figure 17b shows the Connection Synchronizer for the second node 110 initiating another synchronization procedure to remove the connection O. The Connection Synchronizer found that the connection O was a garbage connection when it checked the connections in order to respond to the CHECK REQUEST task sent by node 100 in Figure 17a, so it sends a REMOVΕ REQUEST for connection O to node 120. Node 110 also sends a CHECK FORWARDED to node 100 for

2 \ connections R. Y. and G. and sends a CHECK REQUEST to node 120 for these connections.

Figure 17c shows the CHECK REQUEST for connections Y and G being fonvarded from node 120 to nodes 130, 150 on the multicast tree branches. OUT OF SYNC CONFIRMED is sent back to node 110 for the connection R. along with

CHECK FORWARDED messages for connections Y and G. Finally, node 120 sends REMOVE CONFIRMED for connection O back to node 110, and continues the process of removing connection O by sending REMOVE REQUEST to node 150.

Figure 17d shows the Connection Synchronizer at node 110 initiating removal of the connection R. Although the whole procedure is initiated by the Connection

Synchronizer for the first node 100. the decision to remove the checked connections is distributed. In addition, the CHECK REQUESTS for Y and G are fonvarded along the branches to nodes 140. 160. while node 150 confirms that it has removed connection O. now completely removed from the network.. In Figure 17e. node 100 confirms the removal request of node 110 for connection R to finish removing that connection. Node 140 sends a SYNC CONFIRMED message for connection G to node 130, indicating that that branch of connection G is still alive. It also sends an OUT-OF-SYNC CONFIRMED message for connection Y. Node 160 sends an OUT-OF-SYNC CONFIRMED to node 150 for connection G, indicating that this branch of connection G is a garbage branch. Figures 17f-17i show the rest of the procedure for removing garbage connections step by step, as the REMOVE REQUEST messages travel back towards node 100 and are confirmed at each step. Note that the removal of garbage connection G from the lower branch stops at node 120, since the upper branch of this connection is alive.

Finally, Figure 17j shows the clean network, with all garbage connections removed. The only connection remaining is the upper branch of connection G.

Other embodiments of the invention will be apparent to those skilled in the art from a consideration of the specification or practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

39 What is claimed is:

Claims

.An object-oriented system for user control of resources on a communications network, the neUvork including at least two hosts and at least one switch, the system comprising: at least two host objects corresponding to the at least two hosts, each host object comprising an interface having a function selected from the group consisting of creating a connection path segment at its corresponding host, destroying a connection path segment at its corresponding host, and reserving resources at its corresponding host: at least one switch object corresponding to the at least one switch, the switch object comprising an interface having a function selected from the group consisting of creating a connection path segment at the switch. destroying a connection path segment at the switch, and reserving resources at the switch; a topology object that stores a description of the topology of the communications network; a controller mapping service that provides mappings between host transport addresses and host objects and between the switch transport address and the switch object; and a controller object that communicates with an application running at one of the hosts; the host objects; the switch object: the topology object; and the controller mapping service to set up a connection path between the hosts, by obtaining connection path information including a set of desired connection path segments; directing an origin host object at one end of the path, intermediate switch objects on the path, and a terminal host object at the other end of the path to set up connection path segments of the path; and

3*\ providing communications information about the path to the application.

2. The object-oriented system of claim 1. wherein each host comprises a controller object that sets up connection paths in response to requests from applications running at the host.

3. The object-oriented system of claim 2, wherein the host object periodically checks the controller object to detect whether it has crashed.

4. The object-oriented system of claim 2, wherein the controller object periodically checks the requesting application program to determine whether it has crashed.

5. The object oriented system of claim 4. wherein the controller object checks the requesting application program using a kernel sen ce.

6. The object-oriented system of claim 1. further comprising a route repository object that maintains a list of possible routes between hosts.

^■ The object-oriented system of claim 6. wherein the route repository object includes information about available resources along the possible routes.

8. The object-oriented system of claim 6, wherein the controller object queries the route repository object to obtain the connection path information.

9. The object-oriented system of claim 1. wherein the neuvork is an ATM network.

10. The object-oriented system of claim 1. wherein the objects communicate over a second neUvork.

11. The object-oriented system of claim 1, wherein the objects communicate via TCP/IP.

12. The object-oriented system of claim 1, further comprising a connection synchronizer that finds and removes garbage connections from the system.

3 ≤

13. The object-oriented system of claim 12, wherein the connection synchronizer resides at a host or switch, and periodically polls neighboring hosts and switches to determine consistency of active connections.

14. The object oriented system of claim 13, wherein a second connection synchronizer resides at a neighboring host or switch, and wherein in response to a poll by the first connection synchronizer, the second synchronizer checks for connection consistency, and if necessary forwards the check to another synchronizer residing at a neighboring host or switch to continue the consistency check.

15. A method of setting up a path on a communications network, the neUvork including at least Uvo hosts and at least one switch, and further including software elements including a host object at each of the uvo hosts, each host object comprising an interface having a function selected from the group consisting of creating a connection path segment at its coπesponding host. destroying a connection path segment at its corresponding host, and reserving resources at its corresponding host, a switch object corresponding to the at least one switch, the switch object comprising an interface having a function selected from the group consisting of creating a connection path segment at the switch, destroying a connection path segment at the switch, and reserving resources at the switch, a topology object that stores a description of the topology of the communications network, and a controller mapping sendee that provides mappings beuveen host transport addresses and host objects and between the switch transport address and the switch object, the method comprising: obtaining connection path information including a set of desired connection path segments; directing an origin host object at one end of the path, intermediate switch objects on the path, and a terminal host object at the other end of the path to set up connection path segments of the path: and

3(.

information about the path to an application running at at least one of the oπgin host object and the terminal host object

16 The method of claim 15. wherein each host composes a controller object that executes the steps of obtaining the connection path information, directing the oπgm host object, the intermediate switch objects, and the terminal host objects to set up the connection path segments, and providing communications information to the application

17 The method of claim 16. further compπsmg peπodically checking the controller object to determine whether it has crashed

I S The method of claim 15. further compπsing peπodically checking the application to determine whether it has crashed

19 The method of claim 18. wherein checking the application compπses que ing a kernel sen'ice 0 The method of claim 15. wherein obtaining connection path information compπses querying a route repository object that maintains a list of possible routes betw een hosts 1 The method of claim 20. w herein the route repository object further mamtains information about

ailable resources along the possible routes 2 The method of claim 15. wherein the network is an ATM ork 3 The method of claim 15, wherein the objects communicat

r a nero ork separate from the neuvork containing the connection path segments 4 The method of claim 15. wherein the objects communicate via TCP IP 5 The method of claim 15, further compπsing finding and removing garbage connections on the network

26. The method of claim 25, wherein finding garbage connections comprises comparing active connections at adjacent hosts or switches to determine consistency of active connections.

27. The method of claim 26, wherein finding garbage connections further comprises forwarding a consistency check request to another host or switch.

3$