WO2001010088A1 - Architecture de commande de reseaux pour commande utilisateur de ressources de reseaux - Google Patents

Architecture de commande de reseaux pour commande utilisateur de ressources de reseaux Download PDF

Info

Publication number
WO2001010088A1
WO2001010088A1 PCT/US2000/020648 US0020648W WO0110088A1 WO 2001010088 A1 WO2001010088 A1 WO 2001010088A1 US 0020648 W US0020648 W US 0020648W WO 0110088 A1 WO0110088 A1 WO 0110088A1
Authority
WO
WIPO (PCT)
Prior art keywords
host
switch
connection
controller
network
Prior art date
Application number
PCT/US2000/020648
Other languages
English (en)
Inventor
Aurel A. Lazar
Eunsoo Shim
Original Assignee
Xbind, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Xbind, Inc. filed Critical Xbind, Inc.
Priority to AU63895/00A priority Critical patent/AU6389500A/en
Publication of WO2001010088A1 publication Critical patent/WO2001010088A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/18—Delegation of network management function, e.g. customer network management [CNM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0095—Specification, development or application of network management software, e.g. software re-use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
    • H04L2012/562—Routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5625—Operations, administration and maintenance [OAM]
    • H04L2012/5626—Network management, e.g. Intelligent nets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5625—Operations, administration and maintenance [OAM]
    • H04L2012/5627—Fault tolerance and recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/563—Signalling, e.g. protocols, reference model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/5631—Resource management and allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/5631—Resource management and allocation
    • H04L2012/5632—Bandwidth allocation

Definitions

  • 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.
  • 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.
  • SPC stored program control
  • SS7 Signaling system number 7
  • STPs signaling transfer points
  • 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.
  • 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).
  • SCPs service control points
  • 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.
  • 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.
  • the 800-service set of capabilities cannot be used for other services (e.g., 900 service).
  • 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.
  • 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.
  • the SCP service logic and the service management system are service-independent.
  • CPE Customer Premises Equipment
  • 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
  • circuit-switching networks 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
  • each packet should contain an information flow identifier that determines where it should be forw arded
  • 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
  • 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
  • a VC is identified as a set of a VCI and a VPI w
  • 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.
  • an OC3 link is capable of transmitting information up to 155Mbps.
  • 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.
  • 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.
  • QOS quality of service
  • 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.
  • 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.
  • a system 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.
  • 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.
  • connection controllers 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.
  • 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.
  • 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.
  • Figure 1 shows a traditional "black box” network configuration
  • Figure 2 shows a network interface giving limited user control:
  • FIG. 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.
  • FIGS 17a-17j show the steps performed to remove the garbage connections of Figure 16
  • connection-oriented net ork ⁇ e g . circuit-switching networks
  • connection-oriented net ork ⁇ e g . circuit-switching networks
  • 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
  • « has plural PCs that are connected through plural ATM switches with arbitrary topology.
  • IP Internet Protocol
  • IP has many advantages such as wide availability, well-known programming environment, robustness, and relatively simple management requirements.
  • IP connectivity 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.
  • 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.
  • 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 d er 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.
  • 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.
  • Each switch sen'ers and host servers compose a resource pool.
  • Each node sen d er 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.
  • 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 d er is identified with the object identifier rather than with the
  • 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 switch sen d er interacts with the switch to control and monitor it.
  • 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
  • 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.
  • 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.
  • 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).
  • IDL Interface Definition Language
  • 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.
  • 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.
  • 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.
  • connection senice can be realized on top the infrastructure described above.
  • 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.
  • connection establishment procedure of the invention comprises the following steps:
  • the application requests a VC from the VC Controller residing on the local host.
  • 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
  • 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.
  • 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.
  • 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.
  • an ATM switch 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.
  • the switch uses the information stored in the switching table to change 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
  • 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.
  • 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.
  • 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:
  • 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
  • VN virtual network
  • ATM Switch interface and ATM Node interface include functionality to control VC and VP connections at the single node level.
  • a network is modeled as a pool of switches and hosts connected in a certain topology.
  • 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.
  • 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.
  • the information in the RouteRepository provides a hint for the proper path, if any, and includes important information needed for establishing connections.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • a distributed object system has a service providing the following mapping:
  • mapping from object names to object references are specific to each distributed object 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.
  • 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,
  • CMS Controller Mapping Service
  • 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:
  • 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.
  • 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.
  • 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.
  • 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 controllers 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.
  • 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
  • VN virtual neUvork
  • 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 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.
  • 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.
  • 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.
  • a VC Controller gets a connection request to set up a VC from node 100 to node 200.
  • 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 ' ?”
  • the CMS server returns the object name to the VC Controller.
  • 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
  • a VCL ⁇ TI pair should be acquired at the input port and another VCI/VPI pair should be acquired at the output port.
  • 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:
  • 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
  • the origin VC Controller 60 contacts the CMS object 26 and gets the object reference of the target VC Controller 64.
  • the origin VC Controller 60 contacts the target VC Controller 64 and checks whether the target application 74 is available.
  • 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.
  • 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.
  • the origin VC Controller 60 contacts the Host object 66 of the origin host and sets up a VC termination.
  • the origin VC Controller 60 contacts the first intermediate Switch 68 object and sets up a VC at the corresponding switch.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • peer-to-peer application model we mean an architecture where each party can perform a part of control tasks.
  • 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.
  • VC release 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:
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the receiver application may wait for data for a period of hours until the human user comes back. tying up network resources.
  • 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.
  • 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
  • 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
  • the Host 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
  • 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
  • VC Controller 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
  • 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 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 ⁇ ubbed algo ⁇ thm where there is no central coordinator
  • the software component embodying the SYNC protocol is called the Connection Synchronizer
  • 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)
  • the neighbor Connection Synchronizer replies to the requester with a response message
  • Uvo types of requests as follows
  • 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 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.
  • 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.
  • 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.
  • 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 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.
  • 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:
  • 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 can be ATM VC.
  • FIG. 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
  • 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
  • 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.
  • FIG. 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.
  • 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..
  • 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.
  • Figure 17j shows the clean network, with all garbage connections removed. The only connection remaining is the upper branch of connection G.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des ressources de réseaux modélisées et mises en place sous forme d'objets de logiciels. De préférence, la topologie des réseaux et les listes d'itinéraires entre les noeuds sont également mises en mémoire. Les objets sont accessibles aux contrôleurs de connexion dans le domaine utilisateur. Les contrôleurs de connexion obtiennent les références objet correspondant aux ressources de réseaux par le service de mise en correspondance du contrôleur et par le service CORBA ou par un service équivalent. Les contrôleurs de connexion du domaine utilisateur coordonnent les ressources de réseaux et mettent en place des services de réseaux personnalisés. Pour réutiliser les ressources qui n'ont pas été correctement délivrées par les contrôleurs utilisateurs, un mécanisme de récupération de l'espace mémoire fonctionne dans l'ensemble du réseau.
PCT/US2000/020648 1999-07-30 2000-07-28 Architecture de commande de reseaux pour commande utilisateur de ressources de reseaux WO2001010088A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU63895/00A AU6389500A (en) 1999-07-30 2000-07-28 Network control architecture for user control of network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14649299P 1999-07-30 1999-07-30
US60/146,492 1999-07-30

Publications (1)

Publication Number Publication Date
WO2001010088A1 true WO2001010088A1 (fr) 2001-02-08

Family

ID=22517621

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/020648 WO2001010088A1 (fr) 1999-07-30 2000-07-28 Architecture de commande de reseaux pour commande utilisateur de ressources de reseaux

Country Status (2)

Country Link
AU (1) AU6389500A (fr)
WO (1) WO2001010088A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1758299A1 (fr) * 2004-06-18 2007-02-28 Huawei Technologies Co., Ltd. Procede assurant la fiabilite d'un service dans un cadre de qualite de service de bout en bout
US9602343B1 (en) 2013-12-30 2017-03-21 Google Inc. System and method for establishing connection with network controller

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998047165A2 (fr) * 1997-04-17 1998-10-22 The Trustees Of Columbia University In The City Of New York Procede et systeme de reservation pour communications en mode de transfert asynchrone

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998047165A2 (fr) * 1997-04-17 1998-10-22 The Trustees Of Columbia University In The City Of New York Procede et systeme de reservation pour communications en mode de transfert asynchrone

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IVAN TAM MING-CHIT ET AL: "A comparative study of connection setup on a concurrent connection management platform", IEEE OPEN ARCHITECTURES AND NETWORK PROGRAMMING, SAN FRANCISCO, CA, USA, 3-4 APRIL 1998, 1998, New York, NY, USA, IEEE, USA, pages 14 - 24, XP002151668, ISBN: 0-7803-4783-8 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1758299A1 (fr) * 2004-06-18 2007-02-28 Huawei Technologies Co., Ltd. Procede assurant la fiabilite d'un service dans un cadre de qualite de service de bout en bout
EP1758299A4 (fr) * 2004-06-18 2007-06-27 Huawei Tech Co Ltd Procede assurant la fiabilite d'un service dans un cadre de qualite de service de bout en bout
US7706388B2 (en) 2004-06-18 2010-04-27 Huawei Technologies Co., Ltd. Method and node equipment for guaranteeing service reliability in an end-to-end quality of service framework
US9602343B1 (en) 2013-12-30 2017-03-21 Google Inc. System and method for establishing connection with network controller
US10075335B1 (en) 2013-12-30 2018-09-11 Google Llc System and method for establishing connection with network controller

Also Published As

Publication number Publication date
AU6389500A (en) 2001-02-19

Similar Documents

Publication Publication Date Title
US6434612B1 (en) Connection control interface for asynchronous transfer mode switches
US5509010A (en) Communications signaling protocols
CA2124379C (fr) Architecture de traitement repartie pour le controle de reseaux de communication a large bande et a bande etroite
US7293080B1 (en) Automatically discovering management information about services in a communication network
JP3633356B2 (ja) サーバ装置、サービス制御ゲートウェイ装置、サービス制御装置及び通信制御方法
US20020048360A1 (en) System and methods for distributed telecommunication applications for the public switched telephone network and the public land mobile network
JPH0685907A (ja) 呼ルーティング方法および装置
USRE40398E1 (en) ATM telecommunications systems and method for routing narrow band traffic
US7706290B2 (en) Object-based operation and maintenance (OAM) systems and related methods and computer program products
JP3083540B2 (ja) マルチプロセッサを用いた交換制御方式
US8547849B2 (en) ATM telecommunications systems and method for routing narrow band traffic
JP4245809B2 (ja) フレキシブルな呼ルーティングシステム
WO2001010088A1 (fr) Architecture de commande de reseaux pour commande utilisateur de ressources de reseaux
US6480492B1 (en) Establishing internal control paths in ATM node
EP1432187B1 (fr) Allocation de ressources dans une passerelle de media
KR100270664B1 (ko) 사설망 노드 인터페이스 라우팅 기능을 분산시키는 방버버
Veeraraghavan et al. Object‐oriented analysis of signalling and control in broadband networks
Bird et al. Advances in APPN architecture
WO2005039106A1 (fr) Procede et appareil de realisation d'operations d'acheminement dans un reseau de communication
WO1998053578A1 (fr) Procede et systeme pour fournir des services multimedia dans un reseau de communications atm
KR100265075B1 (ko) 논리적 백본 링크 구성 방법
FI105747B (fi) Useamman kytkentäkeskuksen dataverkko
JP2896775B1 (ja) 網間アドレス解決方式
KR100198957B1 (ko) 분산형 액세스 노드 시스템에서의 응용객체를 이용한 호처리방법
JP3008096B1 (ja) マルチリンク接続におけるコネクション設定方式

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP