COMMUNICATIONS NETWORK

Abstract: In a communications network which handles packet data, a switched virtual circuit is initiated by a customer terminal and is used as a cut-through for packet traffic to or from the customer terminal.

Description: COMMUNICATIONS NETWORK The present invention relates to a communications network, and in particular to a network using a packet-based protocol such as Internet Protocol (IP). Conventionally, networks using packet-based protocols such as Internet Protocol (IP) have functioned using so-called "best effort" routing. When and whether a particular router passes on a packet depends on factors such as the length of the queues in buffers in the router. As a result, quality of service, as measured by such parameters as packet loss and latency, has varied considerably depending on the loading of network resources such as routers. While such variation is acceptable for some applications, such as Email, it is potentially a barrier to the use of Internet Protocol for more critical applications such as voice telephony or multimedia conferencing. Accordingly, considerable effort has been directed to providing improved Quality of Service (QoS). One approach has been to supplement IP with QoS-related protocols such as Resource reservation Protocol (RSVP). Another approach has been to make use of circuit-switched networks, and particularly ATM networks to carry IP traffic. When a customer terminal ' and a data source are both connected to an ATM network, then a Switched Virtual Circuit (SVC) may be used to "cut-through" from the terminal to the source, bypassing any intermediate routers, and providing a uniform and predictable QoS level. Standards for networks supporting such a capability have been proposed by the ATM (Asynchronous Transfer Mode) Forum and by the IETF (Internet Engineering Task Force). These standards are known as the the Multi-Protocol over ATM (MPOA) and Multi-Protocol Label Switching (MPLS) standards. When these standards are implemented, a device in the network, such as an MPOA server, detects a data flow that is a candidate for an SVC cut-through, establishes the required SVC circuit, and initiates the diversion of the data through the cut-through. According to a first aspect of the present invention, there is provided a method of operating a communications network, comprising: a) establishing a data flow between a customer terminal and another data terminal, the data flowing conforming to a best-effort packet- routing protocol; b) subsequently initiating from the customer terminal the use of the a •switched virtual circuit through the network for the data flow. The present invention provides a method of using virtual circuits to give enhanced quality of service that differs significantly from previously proposed techniques. Whereas previously the use of virtual circuits has been regarded as purely an internal function within the network and has been hidden from the user, the present invention transfers control of the virtual circuit capability out of the network to the customer terminal. The user initially communicates with another data terminal, such as a server hosting a web site, using a best-effort protocol such as Internet Protocol. Only when and if the user subsequently elects to initiate the use of a switched virtual circuit does the network change the routing method for data flowing to or from the customer terminal. Preferably the method includes a step, prior to step (b), of communicating to the customer terminal data indicating potential availability of a switched virtual circuit in the network for the said data flow. This preferred feature of the invention facilitates the use of hybrid networks where only some data terminals may be connected to, e.g., ATM switches that support switched virtual circuits, while other data terminals may be connected only to, e.g., IP routers. Data is communicated to the customer to indicate when the use of a switched virtual circuit is possible. This data may be provided by a domain name server located in the network, or may be provided by the data server itself, for example in an HTML page indicating an ATM address and a bandwidth capability for the data server. In a preferred implementation, the data is in the form of a URL (Uniform Resource Locator) that is specific to resources accessible via a circuit connected network, and the URL contains all the information necessary to set up the switched virtual circuit. The URL may be in the form: < circuit-connected identifier part > :// < service parameter part > * < address part > where * is a predetermined separator character. The use of URL's in this manner is described and claimed in our copending application, also entitled "Communications Network", filed 9 December 1 998, (Case Reference A25679). The invention also encompasses customer terminals and networks adapted for use in the invention. Systems embodying the present invention will now be described in further detail, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a diagram showing a first example of a network embodying the invention; Figures 2 to 5 show different phases in the process of establishing a switched virtual circuit (SVC); Figure 6 is a flow diagram; Figure 7 is a state machine for a web browser used in implementing the invention. As shown in Figure 1 , a customer terminal 1 , in this example a personal computer, is connected to other data terminals 2,3 via a network 4. In this example, the data terminals 3,4 are web servers arranged to return HTTP (hypertext transport protocol) pages to the customer terminal 1 . The network 4 includes a first subdomain 4a that is part of the public Internet and includes a number of Internet Protocol (IP) routers 5. Suitable routers are commercially available devices such as CISCO series 7500 routers. A second subdomain 4b comprises a number of ATM (asynchronous transfer mode) switches 6. Although, for ease of illustration, only two ATM switches are shown, in practice the subdomain 4b is likely to contain a larger number of switches. Suitable switches are commercially available devices such as ALCATEL 1 100 HSS Series 700 switches. These switches support ATM Switched Virtual Circuits (SVCs), in accordance with the ATM Forum V3.1 and V4.0 SVC definitions. In this example, the customer terminal includes an ATM card and is connected via an ATM access router 7 to both of the network subdomains. One of the data terminals 3,4 has only an IP interface and is connected to both of the subdomains 4a, 4b. The other of the data terminals 3,4 has an IP over ATM interface and is connected via that interface to both of the subdomains. In use, the customer terminal 1 initially retrieves web pages from the data terminals 3,4 via the IP network 4a of the first subdomain. The web pages are displayed by a web browser application running on the customer terminal in a conventional fashion. The data flow between the customer terminal 1 and the data terminals 3,4 via the IP network is shown by the dashed broad line in the Figure. The data flow is effected by best-effort routing by the IP routers 5, and accordingly the quality of service varies depending on the loading of the routers. As already indicated, one of the data terminals 3,4 is also accessible via the ATM network of the second subdomain. When the user wishes to retrieve data, such as a video data, that requires a high and guaranteed quality of service, from the said data terminal, then the user initiates a switched virtual circuit (SVC) via the subdomain 4b to the data terminal. The subsequent data flow via this SVC is indicated by the solid broad line in Figure 1 . The operation of the network will now be described in further detail with reference to Figures 2 to 5. In these Figures, the customer terminal 1 is referenced "End User 1 ", data terminal 3 is referenced "Content Provider 1 " and data terminal 4 is referenced "Content Provider 2". Other customer terminals, referenced "End User 2" and "End User 3" are also shown. Also, in these examples, the connection from End User 1 to the IP subdomain 4a is via an Internet Service Provider (ISP) . End user 1 is connected to the ISP via the ATM network 4b. The connection to the ISP gives End User 1 access to the Internet and to other data terminals having Internet connections. Some only of these other data terminals are also connected to the ATM network 4b. In Figure 2, Content Provider 2 and End User 3 are connected to the ATM network 4b and can potentially be reached via an SVC cut-through, whereas Content Provider 1 and End User 2 have only have connections to the Internet End User 1 need to know which customers can be reached via an SVC cut-through. Examples of mechanisms by which the customer can know if it is possible to establish an SVC cut-through are : A) If a DNS (domain name server) translation of the chosen customer's URL to an ATM address exists. For example, End User 1 could request a DNS translation for Content Provider 2, by communicating a URL "http://www.CP2.co.uk/" to the DNS. As Content Provider 2 has direct access to an ATM network, the Content Provider 2 URL would map to an ATM address. Both the IP address of Content Provider 2 and also the corresponding ATM address are returned to the End User 1 . The fact that an ATM address has been returned indicates to End User 1 that an SVC cut-through is possible. Similarly, End User 1 may request a DNS translation for Content Provider 1 . As Content Provider 1 does not have direct ATM network access the Content Provider 1 URL would not map to an ATM address, and this indicates to End User 1 that no SVC is possible in this case B) The originating customer identifies that an SVC cut-through is possible via information which could be downloaded in the form of HTML, that is as a web page displayed by the web browser application. This information would need to include the ATM address, and may also include Bandwidth availability, QoS information and an indication of cost. C) A content provider may have an ATM specific URL in the format "atm:// ATM parameters @Server ATM address. sub-address/full-path-of-file." This mechanism may be combined with (B), that is, the ATM specific URL may be displayed on an HTTP page, either on the server to which the ATM specific URL relates, for example Content Provider 2, or on another server that such as Content Provider 1 , that is not itself on the ATM network but includes links to resources that are on the ATM network. When the customer chooses to initiate an SVC cut-through, for example in order to access VoD (Video-on-Demand) material on Content Provider 2, signalling is used between the customers across the ATM network to set-up the SVC. This phase is illustrated in Figure 3. Standard ATM-F and ITU-T signalling protocols are used in setting up the SVC. As shown, in the Figure, the connection from End User 1 to the ISP remains active, so that, once the SVC is released, there still exists a connection into the IP network subdomain 4a. Figure 4 shows the SVC established in the ATM network. Once this is established, the End User 1 can view the selected application or data on Content Provider 2. When End User 1 has finished viewing material that requires an SVC, then the cut-through is released using signalling between the customers across the ATM network, again using standard ATM-F and ITU-T signalling protocols. This release phase is shown in Figure 5. In a preferred implementation of the invention, mechanism (C), that is the use of ATM-specific URL's, is adopted. In this case, the Web browser application running on the customer terminal is adapted to support Winsock (Windows Sockets) version 2 functionality (Windows is a trademark of Microsoft Corporation) . Figure 6 is a flow diagram illustrating in further detail the behaviour of a system operating using ATM URL's, and Figure 7 is a state machine diagram for the web. browser. The steps shown are as follows: 1 . The user searches web pages for the relevant information, as if using a standard web browser. No ATM SVC has been established. 2. When the user clicks on the desired ATM Hyperlink/URL, or uses a bookmark, the web browser performs the following operations:- 3. First the Web browser has to determine that this is an ATM URL request, if so, it has to parse/decode the ATM information. This information is stored and used to help construct the profile of the signalling message capability, and determines the socket and protocol state machine type. It should be noted that the ATM URL does not contain all the ATM lE's (Information Elements) defined in the signalling protocols. This is for two reasons. Firstly, not all the defined lE's are sent in the ATM signalling SETUP or LEAF SETUP REQUEST messages. Secondly, the ATM information within the URL contains only the information required by the web browser. The web browser or the WinSock2 API is free to add valid additional ATM information before initiating the ATM SVC. An example of this additional ATM information could be the Calling Party Number, Calling Party Sub-address, Transit Network Selector (TNS) Broadband Sending Complete, Broadband Repeat Indicator, Broadband High and Low Layer Information, Narrowband High and Low Layer Compatibility etc. Before data can be sent between the two entities, the web browser has to use the correct protocol state machine implementation for the URL scheme. The ATM protocol state machine has to be also associated with the ATM socket descriptor. As the URL scheme is 'atm://' the web browser knows it should use the ATM protocol state machine and create ATM sockets. The state machine is used by the web browser to define its behaviour when sending and receiving data over a connection. This state machine has been developed for use with ATM connections. The ATM state machine is described in further detail below with reference to Figure 7. . If the web browser client determines after decoding the ATM URL that no ATM parameter value(s) need to be specified manually by the'Web browser, then the ATM GUI is not launched and the Web browser uses the underlying WinSock2 Application Programming Interface (API) functionality to establish an ATM SVC to the desired destination. The characteristics of this ATM SVC will be the same as those values returned from the HTTP server in the ATM URL. This corresponds to state ATM_GET_SETTINGS in Figure 4. 5. If the user is required to define a particular ATM parameter value(s), the web browser launches an ATM GUI (Graphic User Interface) . This ATM GUI is an extension to traditional web browser applications, in that it allows the end users to enter values for the ATM parameters coded as 'User Defined' within the ATM URL. The values entered by the end user via the ATM GUI are also stored to help build the profile or characteristics of the signalling messages, which will be sent to the ATM server(s). This corresponds to state ATM_GET SETTINGS in Figure 4. 6. WinSock2 is responsible for creating ATM sockets for communication between the web browser and ATM server.. This involves the web browser and ATM server invoking a number of WinSock2 function calls. When the ATM sockets have been created but not connected together, then this corresponds to state ATM_BEGIN_CONNECT, as shown in Figure 7. 7. Once the server and client ATM sockets are created, WinSock2 communicates with the underlying signalling protocol stack to establish an ATM SVC and logically connects the two ATM sockets together. The WinSock2 SPI is responsible for taking the ATM URL parameters, together with any information added by the user, and coding them into the correct format to be used with the underlying signalling protocol, which may be, e.g., UNIv3.0, UNIv3.1 , UNIv4.0, UNIv4.1 or Q.2931 . The WinSock2 SPI is also responsible for including mandatory Signalling lE's, not defined in the ATM URL. Examples of these mandatory lE's include, the Protocol Discriminator, Call Reference, Message Length, Message Type and Endpoint Reference (for Point-to-Multipoint connections) plus LU Sequence Number (for LU connections) . If the ATM SVC is successfully established then, charging records for that connection can be generated and state ATM SEND_REQUEST is entered, see Figure 7. If however, the SVC fails to be established, the web browser launches a window to inform the user of the event and enters the ATM_ERROR_FOUND state. 8. Once the ATM SVC is established, data can be sent and received between the web browser and the ATM server. Before the file(s) are downloaded the ATM server returns the total length of the file to be downloaded to the web browser. The number of bytes of data received by the web browser is incremented and compared with the file size obtained at the GET_FILE_SIZE state, of Figure 7. If the two values are equal, then the whole file has been transferred and the ATM_TRANSFER_STOP state is entered, else the transfer continues. When downloading data, control is passed back from the state machine to the calling application, so it won't block user commands. Knowing the size of the file, allows the web browser to display the transfer progress status (indicating the proportion of bytes received compared to the total number yet to be received) and to estimate the remaining time of the transfer. As many different types of data can be downloaded, the web browser has to know how to interpret each type of data. Depending on the associated Multipurpose Internet Mail Extensions (MIME) type, the data is directed to either a plug-in application, a file name on a local or remote disc, or to the web browser display. 9. If errors occur during the download process, the state machine enters the ATM_ERROR_DONE state. This may occur for several reasons, for example when the ATM server did not send the size of the file in the first packet; or when the transfer of a buffer cannot be completed because either there was a network or application failure etc. 10. If the user wishes to terminate the file download, they can, by pressing the 'CANCEL' button on the progress dialogue box or alternatively by pressing the 'STOP' button on the web browser GUI. This causes the state, ATM_ERROR to be entered, as shown in Figure 7 and causes the ATM SVC to be released. In addition, providing there is end-to-end support between the web browser and the ATM server to support ITU-T Rec. Q.2963.1 , or Q.2963.2 and (Q.2725.2 or Q2725.3) signalling, then the end user can modify the traffic characteristics of the ATM SVC. This modification process can be achieved via the use of the ATM GUI and the user entering new information or automatically by the application, which could be transparent to the user. 1 . Once the file(s) have been downloaded to the web browser, the ATM server automatically starts the first step to close the ATM sockets. By closing the sockets causes the ATM server in turn, to release the ATM SVC between itself and the web browser. Any charging mechanisms associated with the SVC should be stopped. The web browser is now in the ATM_TRANSFER_STOP state, as shown in Figure 7. 2. Once the ATM SVC has been released, the server and client can then completely shut down their ATM sockets associated with the SVC and release any resource(s) allocated to them. The web browser is now in the FREE_ATM_RESOURCES state as shown in Figure 7 and control is passed back to the calling process within the web browser.

Claims: CLAIMS 1. A method of operating a communications network, comprising: a) establishing a data flow between a customer terminal and another data terminal, the data flow conforming to a best-effort packet- . routing protocol; b) subsequently initiating from the customer terminal the use of the a switched virtual circuit through the network for the data flow. 2. A method according to claim 1 including a step, prior to step (b), of communicating to the customer terminal data indicating the availability of a switched virtual circuit in the network for the said data flow. 3. A method according to claim 2, in which the said data indicating the availability of a switched virtual circuit compπses a URL having a format specific to resources located on a circuit-connected network. 4. A method according to any one of the preceding claims, in which the packet-routing protocol is Internet Protocol. 5. A method according to any one of the preceding claims, in which the switched virtual circuit is established in an ATM (asynchronous transfer mode) network. 6. A terminal for use in a method according to any one of the preceding claims, the terminal including a packet data interface for connection to a communications network, and means for initiating a switched virtual circuit in the communications network , which switched virtual circuit, in use, provides a circuit-connected path for packet data communicated via the said packet data interface. A communications network including one or more terminals according to claim 6.

Inventors: REECE PAUL WYNDHAM, REECE, PAUL, WYNDHAM
Applicants: BRITISH TELECOMM, REECE PAUL WYNDHAM, BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY, REECE, PAUL, WYNDHAM
Application year: 2000
Main classification: H04L29
IPC codes: H04L12, H04Q11