System for triggering the control plane in an asynchronous connection-oriented transmission network

Abstract

A system and method are disclosed for verifying connection characteristics of a connection-oriented transmission pathway. A receiver of a network device is configured to receive a data stream from a source network device over the pathway. The data stream including a header portion and a data portion. In response to detecting the header portion, a processor of the network device counts a number of units of data received in the data portion and measures a time span over which the data portion is received. Then a transmitter of the network device sends a response data stream, including the count of the number of units received and the measured time span, to the source network device. The source network device determines an actual bandwidth of the connection-oriented transmission pathway using these values.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of commonly assigned copending U.S. patent application Ser. No. 09/334,415, which was filed on Jun. 16, 1999, by Claude Basso et al. for a System for Triggering the Control Plane in an Asynchronous Connection-Oriented Transmission Network, and that is hereby incorporated by reference. Further, application Ser. No. 09/334,415 itself claims priority to European Patent No. 98480063.1 filed on Sep. 16, 1998.

TECHNICAL FIELD

The present invention relates to systems enabling testing for the availability of connections in an asynchronous connection-oriented transmission network such as an Asynchronous Transfer Mode (ATM) network or a Frame Relay network and particularly to a method for triggering the control plane in such a network.

BACKGROUND

Different techniques have been developed for transporting information over a network, such as packet switching techniques whereby digitized data is arranged into so-called bit packets, and circuit switching techniques. In packet switching, the bit packets may either be of fixed length like in the Asynchronous Transfer Mode (ATM) where the packets, also called cells, are all of a conventional fixed length, or be of variable length.

ATM has been recognized as the common base on which different types of services and networks can operate. The ATM technology can efficiently combine the transmission of speech, video, audio (what is commonly called the multimedia traffic) and computer data into the wired network. Furthermore, ATM has proven to scale well from very high speed network infrastructure (the information highways) to customer premises networks. One of the great advantages of the ATM technology is the fact that it can guarantee some level of service when an ATM connection is set up. Such guarantees can correspond to transmission rate, transmission latency and information loss. They can be achieved mainly because the ATM architecture assumes that the transmission media are almost error free.

At the beginning of the ATM technology, there were only Permanent Virtual Connections (PVC). Switched Virtual Connection (SVC) were soon developed. SVCs supported the growth of ATM by providing bandwidth on demand, in real time, to any user destination, with custom-tailored performance to meet the needs of almost any application. From the beginning, SVCs have been integrated to ATM specifications and most ATM customer equipment supports SVCs.

To establish a SVC connection, a routing procedure takes place during which the control point of the source node determines the best route to the destination node. Afterwards, the source control point sends a call setup message, a copy of which is delivered to the control point of every switching node on the route. The call setup message includes all the critical information needed to define and support a connection, and is based upon information contained in the request initiated by an end user or an application. When routing the connection, the network ensures that the selected path has sufficient resources to support the traffic descriptor, bearer capability and Quality of Service (QoS) parameters specified in the call setup message. This is done by the Connection Admission Control (CAC). Then, when the call setup message is received at the destination node, a confirmation message is sent back to the source node which can initiate the exchange of information between the source node and the destination node.

All these procedures for establishing a connection are controlled by the control plane managed by a control point in each node of the network.

ATM networks are getting more and more complex and are being used to handle critical data. Therefore, the control plane is more and more complex and becomes a critical element of such networks. Unfortunately, there is currently no tool to test and verify that the control plane of a network (formed of the control planes of network nodes used in the connection) works properly in a real environment (e.g. a production network).

A solution known as Internet Protocol (IP) “Ping”, was been originally designed to check the availability of a path in the IP world and whether a destination device could be reached by sending out an echo ICMP (Internet Control Message Protocol) to the specified destination device and just waiting for an acknowledgment sent back by the destination device. This procedure is mainly used for networks of routers. Even if a “Ping” works, this cannot ensure that a data stream will actually flow because of the connectionless nature of IP. There is no control plane insofar as the path is determined at the time when the data is sent in the network. Furthermore, there are no Quality of Service parameters.

One advantage of the ATM is its ability to integrate the IP protocol. For that, the first step is to define Higher Layer Protocols (HLP) to emulate the LAN protocols above ATM. Thus, LAN emulation and classical IP are widely used. The advantage is that the applications developed on top of an IP stack are still working transparently. Of course, the “Ping” function is still implemented when IP is used on top of these HLPs since, due to the connection-oriented nature of ATM, the connection must be established prior to the data transmission.

The problem with the HLPs is that they require an extra process to actually establish a connection between two users. In fact, an additional server is necessary to translate the addresses of HLPs (e.g. IP addresses) into ATM and vice-versa. That is why each user must first register to the server before doing anything else and in particular trying to do a “Ping”. This is not very satisfying for testing the connectivity because the “Ping” procedure may not work for reasons which are unrelated to the control plane such as when the server has failed. Therefore, the HLPs do not integrate the full QoS capabilities of ATM.

Another solution for checking if an ATM connection is working properly is to use Operation Administration Management (OAM) cells. OAM cells were designed to test an ATM network through the user plane. Unfortunately, OAM cells do not trigger the control plane and in particular the Connection Admission Control (CAC). Besides, a connection must be established prior to the use of OAM cells. In fact, OAM cells simply check the physical path but do not test the establishment of a connection characterized by specific traffic parameters.

SUMMARY OF THE INVENTION

Accordingly, the main object of the invention is to provide a method enabling to test at any time, the connectivity from a source node to a destination node in an asynchronous connection-oriented network such as ATM network.

Another object of the invention is to provide a method for testing the availability of a network connection characterized by its traffic parameters.

Another object of the invention is to provide a method for triggering the control plane in an asynchronous connection-oriented network in order to test any connection between two nodes by using traffic parameters requested by the user.

The invention relates to an asynchronous connection-oriented transmission network comprising a plurality of switching nodes interconnected by connection lines, each switching node being associated with a control point which is in charge of when a connection has to be established therebetween by identifying which of the connection lines are eligible based upon the requirement of a quality of service. Each switching node comprises a Control ATM Test Application (CATMTA) and a Deamon ATM Test Application (DATMTA) so that, at any time, a user interfacing a source node can test the connectivity of a network connection from the source node to a destination node by initiating a connection procedure wherein a call setup message is sent by the CATMTA of the source node to the destination node and the DATMTA of the destination node sends back an acknowledgment message to the source node.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects, characteristics and advantages of the invention will become clear from the following description given in reference to the accompanying drawings wherein:

FIG. 1 represents a block-diagram of an ATM network wherein a Control ATM Test Application (CATMTA) of a source node initiates a connection by sending a call setup message to a Deamon ATM Test application (DATMTA) of a destination node.

FIG. 2 represents the same block-diagram of an ATM network wherein the DATMTA of the destination node sends back an acknowledge message to the CATMTA of the source node.

FIG. 3 represents the same block-diagram of an ATM network showing the data stream exchanges between the CATMTA of the source node and the DATMTA of the destination node for verifying the characteristics of the connection.

DETAILED DESCRIPTION OF THE INVENTION

As shown schematically in FIGS. 1, 2 and 3, an ATM network 10 includes a plurality of switching nodes 12, 14, 16 and 18. In the present illustration, switching node 12 will be the source node and switching node 18 will be the destination node.

Each node of the network includes a control point which are illustrated only for source node 12 and destination node 18. The control point 20 of source node 12 comprises a Control ATM Test Application (CATMTA) 22, a control plane 24, an adaptation ATM layer (AAL) 26 and an ATM layer 28. CATMTA 22 is connected to control plane 24 but is also connected to AAL 26 and to ATM layer 28.

In the same way, the control point 30 of destination node 18 comprises a Deamon ATM Test Application (DATMTA) 32, a control plane 34, an adaptation ATM layer (AAL) 36 and an ATM layer 38. DATMTA 32 is connected to control plane 34 but is also connected to AAL 36 and ATM layer 38.

Although only a CATMTA has been represented for source node 12 and only a DATMTA has been represented for destination node 18, each of these two nodes, and in a general way, each node of the network includes both CATMTA and DATMTA. Indeed, each node could be used as a source node or a destination node in the procedure implementing the invention. Note that both CATMTA and DATMTA of the same node can be used at the same time.

It must also be noted, that the control point associated with the source node or with the destination node could be outside the node, such as an independent station or any Data Terminal Equipment (DTE).

The procedure described hereafter in reference to the Figures illustrates how are used the CATMTA and DATMTA are used according to the invention.

First, CATMTA 22 associated with source node 22 receives a request from an end user or from a higher level application (not shown) to establish a connection with several parameters. There are three sets of parameters: general parameters such as the number of connection establishment retries in the case of failures or the lifetime of the connection; call setup parameters which will determine the characteristics of the connection. Among them, the most important are the destination ATM address (which is the address of the destination node), the bandwidth parameters, the Quality of Service (QoS) parameters, the type of the connection; i.e., point to point or point to multipoint, virtual circuit or virtual path; and

the data stream parameters such as the data stream format, its size, its frequency and any kind of measures to perform.

CATMTA 22 requests the establishment of the connection with destination node 18 by triggering (signaling and routing) control plane 24. A call setup message is sent from source node 12 to destination node 18 through the switching nodes of the network 10 such as switching node 14 as illustrated in FIG. 1. As usual the control plane of each switching node of the connection is triggered by the call setup message. Note that, if the network fails to deliver the call setup message to the destination node, CATMTA 22 of source node 12 is aware of this failure and it notifies to the requesting end user or application.

When the call setup message is successfully delivered to destination node 18, it is actually received by DATMTA 32. DATMTA accepts the incoming message and sends back an acknowledge message (connect message) toward source node 12 as illustrated in FIG. 2.

The acknowledge message being received by CATMTA 22, the connection is effectively established between source node 12 and destination node 18. The work of the control plane is completed. CATMTA notifies the requesting end user or application that the connection has been successfully established.

According to another aspect of the invention, the new means which are CATMTA and DATMTA can be used for verifying the characteristics of the connection which has just been established between source node 12 and destination node 18 by exchanging data streams as illustrated in FIG. 3. It must be noted that such a verification would not be possible if a classical connection in the ATM network was normally established without using CATMTA and DATMTA.

CATMTA 22 of source node 12 sends a data stream over the connection. If the connection is actually established, the data stream is received by DATMTA 32 of destination node 18. DATMTA 32 will decode this data stream and it will respond back with another data stream. CATMTA 22 receives the response. Everything works so far. CATMTA 22 notifies the end user or the application. In addition, CATMTA 22 may perform several retries, statistics, etc. . . .

If the connection is not actually established, either the data stream sent by CATMTA 22 will not be received by DATMTA 32, or the response sent back by DATMTA 32 will not be received by CATMTA 22. In both cases, CATMTA 22 will never get any response, and it notifies the end user or the application of this failure.

This data stream can be used to check the actual connection's characteristics which has been established by the control plane. As there are a lot of possible combinations of these characteristics, it is impossible to make an exhaustive list of all tests.

For each individual test, a specific initial data stream is sent by the CATMTA. The DATMTA recognizes the nature data stream and can act differently.

Here is a simple example to check the end to end transit delay of the connection. The end to end transit delay is the maximum acceptable time for an ATM cell to flow from the source node the destination node. This value is specified in the call setup message at the creation time of the connection. If the control plane works properly, the actual value of the end to end transit delay must be lower than the one given in the call setup message.

With the following data stream format, it is possible to measure the actual end to end transit delay of the connection:

The data stream sent by the CATMTA includes the time T1 at which the data stream is sent. The data stream is received by the DATMTA at time T2. The DATMTA sends back the answer at time T3. The overhead of the DATMTA is T3−T2. This value is put in the response data stream. The response data stream is received by the CATMTA at time T4. So, the end to end transit delay is given by the formula: T=(T4−(T3−T2)−T1)/2. This value can be compared with the one requested by the user or the application.

To check whether the bandwidth BW requested by the user or the above application has been actually allocated for a constant bit rate connection, a specific data stream has to be sent at the rate BW by the CATAMTA during an amount of time T. The DATMTA which receives the data steam recognizes the header and starts to count the received data (the bytes for example) and the time during which the data are received. When it doesn't receive any more data, it sends back a response data stream in which it puts the amount of received data and the measured time. The CATMTA can then compare the values and it may detect that some data have been lost (cell discarded in the network) for example.

While the above description has been made by considering an ATM network, it is clear that the invention could be implemented in any other asynchronous transmission network of the ATM network type such as a Frame Relay network wherein the packets has a variable length.

Claims

1. A network device for verifying connection characteristics of a connection-oriented transmission pathway, the network device comprising:

a receiver configured to receive a data stream from a source network device, the data stream transmitted along the connection-oriented transmission pathway, the data stream including a header portion and a data portion;

a processor configured to, in response to detection of the header portion of the data stream, count a number of units of data received in the data portion and further configured to measure a time span over which the data portion is received; and

a transmitter configured to send a response data stream to the source network device, the response data stream including the count of the number of units received and the measured time span, to permit the source network device to determine an actual bandwidth of the connection-oriented transmission pathway.

2. The network device of claim 1, wherein the data stream is an Asynchronous Transfer Mode (ATM) data stream.

3. The network device of claim 2, wherein the processor implements a Deamon Asynchronous Transfer Mode (ATM) Test Application that controls the receiver and transmitter.

4. The network device of claim 1, wherein the data stream and the response data stream have substantially identical data portions.

5. The network device of claim 1, wherein the receiver is further configured to receive a call setup message and the processor is further configured to, in response to the call setup message, send an acknowledgement message to the source network device to establish the a connection-oriented transmission pathway.

6. The network device of claim 5, wherein the call setup message includes a desired bandwidth parameter, a quality of service parameter, and a type of connection parameter that specify desired characteristics for the connection-oriented transmission pathway.

7. The network device of claim 1, wherein the source network device is configured to compare the actual bandwidth of the connection-oriented transmission pathway with a desired bandwidth for the connection-oriented transmission pathway.

8. The network device of claim 1, wherein the processor is configured to detect a first time that the data stream is received at the network device and to detect a second time when the reply data stream is to be transmitted by the network device, and the processor is further configured to calculate the difference between the first time and the second time, and to include the difference in the response data stream.

9. The network device of claim 8, wherein the the difference is adapted to be used by the source network device, along with a transmit time of the data stream and a receipt time of the response data stream, to calculate an end to end transit delay.

10. A method for verifying connection characteristics of a connection-oriented transmission pathway, the method comprising the steps of:

receiving a data stream from a source network device, the data stream transmitted along the connection-oriented transmission pathway, the data stream including a header portion and a data portion;

detecting the header portion of the data stream and in response counting a number of units of data received in the data portion of the data stream;

measuring a time span over which the data portion is received; and

sending a response data stream to the source network device, the response data stream including the count of the number of units received and the measured time span, to permit the source network device to determine an actual bandwidth of the connection-oriented transmission pathway.

11. The method of claim 10 wherein the data stream is an Asynchronous Transfer Mode (ATM) data stream.

12. The method of claim 11 wherein the steps of detecting and measuring are performed by a processor executing a Deamon Asynchronous Transfer Mode (ATM) Test Application.

13. The method of claim 10, wherein the data stream and the response data stream have substantially identical data portions.

14. The method of claim 10, further comprising the steps of:

receiving a call setup message; and

in response to the call setup message, sending an acknowledgement message to the source network device to establish the connection-oriented transmission pathway.

15. The method of claim 14, wherein the call setup message includes a bandwidth parameter, a quality of service parameter, and a type of connection parameter that specify desired characteristics of the network conneciton.

16. The method of claim 10, further comprising the step of:

comparing the actual bandwidth of the connection-oriented transmission pathway with a desired bandwidth for the connection-oriented transmission pathway.

17. The method of claim 10, further comprising the steps of:

detecting a first time when the data stream is received;

detecting a second time when the reply data stream is to be transmitted; and

calculating the difference between the first time and the second time; and

including the difference in the response data stream.

18. The method of claim 17, further comprising the step of:

calculating an end to end transit delay from the difference, a transmit time of the data stream, and a receipt time of the response data stream.

19. A network device for verifying connection characteristics of a connection-oriented transmission pathway, the network device comprising:

means for receiving a data stream from a source network device, the data stream transmitted along the connection-oriented transmission pathway, the data stream including a header portion and a data portion;

means for detecting the header portion of the data stream and in response counting a number of units of data received in the data portion of the data stream;

means for measuring a time span over which the data portion is received; and

means for sending a response data stream to the source network device, the response data stream including the count of the number of units received and the measured time span to permit the source network device to determine a bandwidth of the connection-oriented transmission pathway.

20. A computer readable medium containing executable program instructions for verifying connection characteristics of a connection-oriented transmission pathway, the executable program instructions comprising program instructions configure to:

receive a data stream from a source network device, the data stream transmitted along the connection-oriented transmission pathway, the data stream including a header portion and a data portion;

detect the header portion of the data stream and in response counting a number of units of data received in the data portion of the data stream;

measure a time span over which the data portion is received; and

send a response data stream to the source network device, the response data stream including the count of the number of units received and the measured time span, to permit the source network device to determine a bandwidth of the connection-oriented transmission pathway.