Before discussing the invention in more detail, it is useful to consider some background. PNNI is a hierarchical, dynamic link-state routing protocol defined by the ATM Forum for use in ATM networks. The PNNI protocol provides, inter alia, a system for creation and distribution of topology information which determines how individual network nodes “see” the network and thus how nodes communicate. A key feature of the protocol is the ability to cluster groups of switches into “peer groups”. The details of each peer group are abstracted into a single logical node (a “logical group node” or LGN) which is all that can be seen outside of that peer group. One node in each peer group serves as the “peer group leader” and represents that peer group as the logical group node in the next level up of the hierarchy. This system is applied recursively so that PNNI can hierarchically aggregate network topology information. The PNNI topology information available to switches is such that each switch sees the details of its own peer group plus the details of any peer group that represents it at a higher level of the PNNI hierarchy. It is this hierarchical topology abstraction that reduces the resources required to support large-scale ATM networks.
The topology data communicated over PNNI networks is defined by PNNI Topology State Elements (PTSEs). PTSEs include data relating to nodes, links and addresses which can be accessed by network devices, and are created and distributed by nodes so that each node can maintain a topology database which defines its view of the network. PTSEs are flooded among nodes in a peer group so that each peer group node has the same topology database and thus the same view of the network. In the next level up of the hierarchy, however, the peer group topology is abstracted into a single logical node as described above. The logical group node generates PTSEs advertising addresses accessible within its child peer group and distributes these to its neighbors in the next level of the hierarchy, but the details of nodes and links within the peer group are lost. PTSEs generated by a logical group node in this way are also flooded back down the hierarchy, together with PTSEs received by the LGN from its neighbors, to enable the lower-level nodes to identify their “ancestors” (i.e. their representative nodes at higher levels of the PNNI hierarchy) and maintain their views of the PNNI topology.
In general, a PTSE which has been flooded through the network can only be modified by its originating node (i.e. the node which originated, or generated, that PTSE), though PNNI does define a “time-out” system for PTSEs whereby each PTSE is given a lifetime for which it is valid, normally one hour. A PTSE's originating node should “refresh” the PTSE periodically by redistributing the PTSE to its neighbors, so that the PTSE is again flooded through the network. However, if a PTSE's lifetime expires without the PTSE being refreshed, the PTSE is no longer considered valid topology information and is removed, or “flushed” from the network. So if a node becomes inaccessible due to a link failure for example, then PTSEs relating to that node will eventually be flushed from the network. In addition, our copending European Patent Application No. 99115580.5, filed 6 Aug. 1999, discloses mechanisms whereby a peer group leader can check the accessibility of addresses in its own peer group and notify neighboring nodes of changes in address accessibility within that peer group.
PNNI provides full support for mobility at the ATM layer (“PNNI Addendum for Mobility Extensions v1.0”, ATM Forum af-ra-0123.000, April 1999). For example, the PNNI mobility extensions allow a logical group node abstracting a mobile ATM network to roam in the PNNI hierarchy of a terrestrial backbone network Routing information detailing the current location of the mobile network is advertised through regular PNNI, thus enabling the establishment of calls from a terrestrial end-system to an end-system of the mobile network, and vice versa. In addition, ATM networks can be used to carry higher layer protocol information such as IP (Internet Protocol) information. This can conveniently be done by employing an extension to the PNNI protocol known as PAR (PNNI Augmented Routing). PAR is described, for example in “PNNI Augmented Routing (PAR)”, af-ra-0104.000, ATM Forum, January 1999. Briefly, PAR allows IP information, which is not related to operation of the ATM network in itself, to be distributed over the network. PAR makes use of the PTSEs discussed above to distribute IP-related information in addition to the ATM topology information. PAR-enabled devices in the network encapsulate UP information in PTSEs which are then distributed in the usual PNNI way. The IP information in these so-called “PAR PTSEs” is opaque to PNNI nodes that are not PAR-enabled, but other PAR-enabled nodes are aware of the format of the IP information in PAR PTSEs. Thus, a PAR-enabled device in the network can communicate IP information over the network by means of PAR PTSEs, and another PAR-enabled device can extract the IP information.
A further extension of the PNNI protocol known as “Proxy-PAR” allows higher layer protocol devices, in particular IP devices such as routers, to communicate IP information over the network without themselves participating in PNNI. Proxy-PAR is also described in “PNNI Augmented Routing (PAR)”, af-ra-0104.000, ATM Forum, January 1999. Briefly, Proxy-PAR is a simple exchange protocol which allows the integration of IP devices into ATM networks without the need for the IP devices to run PNNI at all. An IP device can be connected to the network via a PAR-enabled device which is configured as a Proxy-PAR server The IP device itself is configured as a Proxy-PAR client. In accordance with Proxy-PAR, the Proxy-PAR client can register details of the IP services it supports with the Proxy-PAR server. This information is then encapsulated in PAR PTSEs as previously described and flooded in the network in the usual PNNI way. The Proxy-PAR client can also request the Proxy-PAR server for information on other IP devices connected in the network for which PAR PTSEs have been received by the PAR-enabled device as previously described. In this way, IP information is communicated between IP devices without the devices participating in PNNI.
Through use of PAR and Proxy-PAR as described above, protocol devices, in particular IP devices, can learn about each other via this communication of protocol information over the PNNI network, avoiding the need for manual input in each device of the protocol information needed for configuration of the higher layer protocol topology. For example, IP routers at the edge of an ATM cloud can learn about each other, and manual configuration of the IP adjacencies can be avoided. Further, our copending European Patent Application No. 99115544.1, filed 6 Aug. 1999, discloses mechanisms for dynamic configuration of OSPF (Open Shortest Path First) interfaces in IP routers. Routers in mobile networks, for example, can dynamically configure OSPF interfaces with the OSPF area of other (fixed or mobile) network routers as the mobile network roams and makes new connections Whether or not OSPF interfaces are configured dynamically, PAR and Proxy-PAR allow routers to register their protocol information (e.g. IP address, ATM address, OSPF area) with their serving ATM switches which then flood the data throughout the network. Other routers can retrieve this IP information by querying their serving ATM switches. Routers can then exchange routing information to form neighbor relationships, or “peer”, in the usual way with other routers they learn about from the information received.
Thus, in general, when PAR is used for communication of protocol information between protocol devices over a PNNI network as described above, configuration of the higher layer protocol topology over the physical ATM network is based on the protocol information supplied by PAR-enabled switches to their client devices via Proxy-PAR. At present, a PAR-enabled switch responds to a Proxy-PAR request from its client device by supplying all protocol information of the type requested which has been received in PAR PTSEs from the network. The present invention is predicated on the realization that this is unnecessary and can compromise efficient configuration of the network topology for the protocol in question.