AU779785B2 - Communications network - Google Patents

Communications network Download PDF

Info

Publication number
AU779785B2
AU779785B2 AU29311/00A AU2931100A AU779785B2 AU 779785 B2 AU779785 B2 AU 779785B2 AU 29311/00 A AU29311/00 A AU 29311/00A AU 2931100 A AU2931100 A AU 2931100A AU 779785 B2 AU779785 B2 AU 779785B2
Authority
AU
Australia
Prior art keywords
atm
network
data
virtual circuit
switched virtual
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
AU29311/00A
Other versions
AU2931100A (en
Inventor
Paul Wyndham Reece
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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
Priority claimed from GBGB9906045.1A external-priority patent/GB9906045D0/en
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of AU2931100A publication Critical patent/AU2931100A/en
Application granted granted Critical
Publication of AU779785B2 publication Critical patent/AU779785B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/4608LAN interconnection over ATM networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q11/00Selecting arrangements for multiplex systems
    • H04Q11/04Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478Provisions for broadband connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5629Admission control
    • H04L2012/563Signalling, e.g. protocols, reference model

Landscapes

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

Description

16/12/04 11:07 SHELSTON IP 00262837999#394 ND.349 004 1 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).
Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.
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 15 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 I proposed by the ATM (Asynchronous Transfer Mode) Forum and by the IETF (Internet Engineering Task Force). These standards are known as the Multi-Protocol over ATM 25 (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 and terminals connected thereto, comprising: COMS ID No: SBMI-01042476 Received by IP Australia: Time 11:59 Date 2004-12-16 16/12/04 11:07 SHELSTON IP 4 00262837999394 N. 349 005 2 a) establishing a data flow between a customer terminal and another data terminal, the data flow conforming to a best-effort packet-routing protocol; and b) subsequently Initiating from the customer terminal the use of a switched virtual circuit through the network for the data flow; wherein 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.
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 Intemet 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 of communicating to the customer terminal data indicating potential availability of a switched virtual circuit in the 20 network for the said data flow.
0* This preferred feature of the invention facilitates the use of hybrid networks where only some data terminals may be connected to, e. ATM switches that support switched virtual circuits, while other data terminals may be connected only to, e. IP routers. Data is communicated to the customer to indicate when the use of a switched 25 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 S" 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) S• 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 :1 service parameter part address part where is a predetermined separator character. The use of URL's in this COMS ID No: SBMI-01042476 Received by IP Australia: Time 11:59 Date 2004-12-16 16/12/04 11:07 SHELSTON IP 4 00262837999#394 NO. 349 Q06 3 manner is described and claimed in our copending application, also entitled "Communications Network", filed 9 December 1998, WO00/35238.
The invention also encompasses customer terminals and networks adapted for use in the invention.
According to a second aspect the present invention provides a communications network for use in a method according to the first aspect, the communications network having a customer terminal connected thereto including a packet data interface for connection to the 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, wherein the network is arranged such that only when and if the user 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.
Unless the context clearly requires otherwise, throughout the description and the claims, the words 'comprise', 'comprising', and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".
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: 20 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; 25 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 retum 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 Suitable routers are commercially available devices such as CISCO series 7500 routers. A second subdomain 4b comprises a number of ATM (asynchronous transfer COMS ID No: SBMI-01042476 Received by IP Australia: Time 11:59 Date 2004-12-16 16/12/134 16'12/B4 11:07 SHELSTON IP 4 00262837999#t394 fl34 Q0 NO.349 3a mode) switches B. 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 1100 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 3A4 has an IP over ATM interface and is connected via that interface to both of the subdomains.
COMS ID No: SBMI-1042476 Received by IP Australia: Time 11:59 Date 2004-12-16 WO 00/56031 PCT/GBOO/00846 4 In use, the customer terminal 1 initially retrieves web pages from the data terminals 3,4 via the IP network 4a of the first subdomai'n. 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 data terminal 3 is referenced "Content Provider 1" and data terminal 4 is referenced "Content Provider 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:/lwww.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 WO 00/56031 PCT/GB00/00846 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 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 WO 00/56031 PCT/GB00/00846 6 In a preferred implementation of the invention, mechanism that is the use of ATM-specific URL's, is adopted. In this case, the wVeb 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 IE's (Information Elements) defined in the signalling protocols. This is for two reasons. Firstly, not all the defined IE'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 flee 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 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.
WO 00/56031 PCT/GB00/00846 7 4. 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.
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, UNIv3.0, UNIv3.1, UNIv4.1 or Q.2931. The WinSock2 SPI is also responsible for including mandatory Signalling IE's, not defined in the ATM URL. Examples of these mandatory IE's include, the Protocol Discriminator, Call Reference, Message Length, Message Type and Endpoint Reference (for Point-to-Multipoint connections) plus LIJ Sequence Number (for LIJ connections). If the ATM SVC is successfully established then, charging records for that connection can be generated and state ATM SENDREQUEST is entered, see Figure 7. If however, WO 00/56031 PCT/GB00/00846 8 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_FILESIZE state, of Figure 7.
If the two values are equal, then the whole file has been transferred and the ATMTRANSFERSTOP 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 ofthe 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 ATMERROR_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.
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.
WO 00/56031 PCT/GBOO/0846 9 11.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 TRANSFERSTOP state, as shown in Figure 7.
12.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 (7)

1. A method of operating a communications network and terminals connected thereto, comprising: a) establishing a data flow between a customer terminal and another data terminal, the date flow conforming to a best-effort packet-routing protocol; and b) subsequently initiating from the customer terminal the use of a switched virtual circuit through the network for the data flow; wherein 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.
2. A method according to claim I including a step, prior to step 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 comprises a URIL having a format specific to resources located on a circuit-connected network. A method according to any one of the preceding claims, in which the packet mouting protocol is Internet Protocol. 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 communications network for use In a method according to any one of the preceding claims, the communications network having a customer terminal connected thereto Including a packet data interface for connection to the communications network, and means for initiating a switched virtual circuit in the communications network, which 25 switched virtual circuit, in use, pirovides a circuit-connected path for packet data communicated via the said packet data interface, wherein the network Is arranged such that only when and if the user 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. COMS ID No: SBMI-01042476 Received by IP Australia: ime 11:59 Date 2004-12-16 16/ 12/084 11:07 SHELSTON I P 4 00262837999#394 NOf. 349 M0
7. A method of operating a communications network and terminals connected thereto substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings.
8. A communications network substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings. DATED this W6J Day of December, 2004 Shelston IP Attorneys for~ BRITISH TELECOMMUNICATIONS public; limited company 9 S S S S S 'St. S S S S. 0I 9 9~ 5, S 'ha. b5 S *9 a S
9. 9 S.. COMS ID No: SBMI-01042476 Received by IP Australia: Time 11:59 Date 2004-12-16
AU29311/00A 1999-03-16 2000-03-08 Communications network Ceased AU779785B2 (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB9906045 1999-03-16
GBGB9906045.1A GB9906045D0 (en) 1999-03-16 1999-03-16 Communications network
EP99305277 1999-07-02
EP99305277 1999-07-02
PCT/GB2000/000846 WO2000056031A1 (en) 1999-03-16 2000-03-08 Communications network

Publications (2)

Publication Number Publication Date
AU2931100A AU2931100A (en) 2000-10-04
AU779785B2 true AU779785B2 (en) 2005-02-10

Family

ID=26153520

Family Applications (1)

Application Number Title Priority Date Filing Date
AU29311/00A Ceased AU779785B2 (en) 1999-03-16 2000-03-08 Communications network

Country Status (5)

Country Link
EP (1) EP1159808A1 (en)
JP (1) JP2002539717A (en)
AU (1) AU779785B2 (en)
CA (1) CA2367399A1 (en)
WO (1) WO2000056031A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2307381A (en) * 1995-11-16 1997-05-21 Siemens Ag Data terminal connected to two networks
US5732078A (en) * 1996-01-16 1998-03-24 Bell Communications Research, Inc. On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network
EP0836306A1 (en) * 1996-10-10 1998-04-15 Hewlett-Packard Company System providing for multiple virtual circuits between two network entities

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2307381A (en) * 1995-11-16 1997-05-21 Siemens Ag Data terminal connected to two networks
US5732078A (en) * 1996-01-16 1998-03-24 Bell Communications Research, Inc. On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network
EP0836306A1 (en) * 1996-10-10 1998-04-15 Hewlett-Packard Company System providing for multiple virtual circuits between two network entities

Also Published As

Publication number Publication date
EP1159808A1 (en) 2001-12-05
AU2931100A (en) 2000-10-04
CA2367399A1 (en) 2000-09-21
WO2000056031A1 (en) 2000-09-21
JP2002539717A (en) 2002-11-19

Similar Documents

Publication Publication Date Title
US6751218B1 (en) Method and system for ATM-coupled multicast service over IP networks
US20020116501A1 (en) Service tunnel over a connectionless network
Landfeldt et al. SLM, a framework for session layer mobility management
JPH10173696A (en) Sound gateway based on wide area network
WO2001084790A1 (en) Method and apparatus for negotiating bearer control parameters using property sets
EP1247420A2 (en) Method and apparatus for providing efficient application-level switching for multiplexed internet protocol media streams
JP2006203876A (en) Method of providing multi-media communications over dsl access network
US6937598B1 (en) Method and apparatus for transporting ATM cell traffic over IP networks
US7643489B2 (en) Methods and systems for providing bandwidth on demand in communication systems
US7477638B1 (en) Interworking of IP voice with ATM voice using server-based control
US7805508B1 (en) Communications network
AU779785B2 (en) Communications network
EP1303955A1 (en) A method of and a system for data exchange over a data network such as the public internet
US20100034209A1 (en) Communication system and home gateway
Reynolds et al. Internet Official Protocol Standards
Cisco Multiservice Access Technologies
Cisco Call Agent Provisioning
US20040004965A1 (en) Dynamic provisioning of DSL services
KR100236959B1 (en) Method of broad-band internet service in broad-band network
Zahariadis et al. Internet Access over residential ATM networks
T'Joens et al. Layer Two Tunnelling Protocol (L2TP): ATM access network extensions
JP4191195B2 (en) Establishing characteristics during transition between AAL2 signaling and further signaling
Nikolaou et al. A QoS middleware for network adaptive applications
KR19990060665A (en) Protocol Architecture of Asymmetric Digital Subscriber Line System Using Asynchronous Transmission Mode
Charzinski IP based networks and applications