sign in sign up
<<
Home , Internet, Telecommunication

Networks 31Ž. 1999 257±273

The impact of the on architectures

Jean-Pierre Hubaux ), Constant Gbaguidi 1, Shawn Koppenhoefer 2, Jean-Yves Le Boudec 3 Institute for Computer and Applications() ICA , Swiss Federal Institute of ( EPFL ) , Lausanne, Switzerland

Abstract

The ever-growing popularity of the Internet is dramatically changing the landscape of the communications marketplace. The two separate worlds of the Internet and are converging. The respective advantages of the two environments are being integrated to fulfill the promise of the super-highways. In this paper, we examine the impact of the Internet on the main telecommunication architectures, namely the IN, the TMN and TINA. There are two new tendencies for implementing services in combination with the Internet: running part of the control system over the Internet, or conveying both the user and the control information over the Internet. We examine these two tendencies, and elaborate on possible ways of salvaging the best parts of the work achieved by the TINA-Consortium in the Internet context. q 1999 Elsevier B.V. All rights reserved.

Keywords: ; Telecommunications management network; Telecommunications information networking architecture; PSTNrInternet interworking; Internet telephony; Virtual

1. Introduction ity, and the absence of any consistent way to control it, caused a wealth of difficulties for anyone trying to Until the late 1970's, introducing new services in monitor, analyze, and plan the operation of the - a network was a slow and difficult pro- work resources needed to provide services. This cess, requiring the modification of switch's software dismal situation was intolerable. Two cleansing spread all over the network. Customers might not waves simultaneously washed away some of this have been happy with their dependence on their dependence. The first wave, called the Intelligent operator but they had little choice in the matter. The NetworkŽ. INwx 1,2 , provided a means to decouple operators may not have been happy with their depen- serÕice-specific software from basic call processing. dence on their equipment suppliers, but they had no The second wave, called Telecommunications Man- choice. At the same time, the equipment heterogene- agement NetworkŽ. TMNwx 3 , organized, across a certain number of layers, the management of telecommunication equipment, thus facilitating the management of heterogeneous networks. ) Corresponding author. Tel.: q41-21-693-2627; : q41-21- Due to the increased pace of developments in the 693-6610; e-: [email protected]. 1 E-mail: [email protected]. area of Telecommunications, it was quickly per- 2 E-mail: [email protected]. ceived that, despite many of the good ideas imple- 3 E-mail: [email protected]. mented in the IN and TMN architectures alone,

1389-1286r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S0169-7552Ž. 98 00263-3 258 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 neither one, nor even their coexistence, could ad- 2. A reminder on telecommunication architec- dress all the challenges of provisioning and tures network management that began to pose in the early 1990's. However, by merging the best While readers familiar with IN, TMN and TINA ideas of those , a new architectureŽ TINA may consider skipping the more tutorial Section 2, ± Telecommunications Information Networking Ar- we describe some original concepts with Fig. 2 and wx chitecture 4. was created by a worldwide consor- Fig. 4. tium, TINA-C, formed in 1992. The Telecommuni- cations community finally believed that they had a reference architecture for many years to comeŽ or at 2.1. The intelligent network least the late 1990's. . Was this belief just a mirage, or a foreseen bridge to another realm? The term Intelligent NetworkŽ. IN was first intro- Now, we are witnessing a third wave that is duced by Bellcore in the 1980's following the de- challenging the positions held by IN, TMN and even ployment of ``800'' number services in the US. The TINA: the Internet 4. In the same way as the best IN is an architectural concept allowing a rapid, ideas of IN and TMN led to TINA, the interweaving smooth and easy introduction of new telecommuni- of the Internet with today's telecommunication solu- cation services in the network. It was standardized tions is generating something new that we are only by the Telecommunications Sector of the Interna- beginning to discover. In recognition of some of the tional Telecommunication UnionŽ. ITU-T , and the strengths of the InternetŽ e.g., open service creation European Telecommunications Standards Institute environment, ubiquitous access, scalable resource lo- Ž.ET-SIwx 5 . Detailed presentations of the IN are cation, and standardized resource access. , some ser- provided inwx 1,2 . vices traditionally based on the Public Switched The IN is based on a simple principle: the Telephone NetworkŽ. PSTN are now being ``ported'' service-specific software is separated from the basic to the Internet. In a similar , the strengths of call processing and is run on a specialized . In IN, TMN, and TINA might have a positive influence IN parlance, this specialized node is called the Ser- on the future of the Internet. By bringing together the Õice Control Point Ž.SCP , while the switches are advantages of both worlds, it is conceivable that the called SerÕice Switching Points Ž.Ž.SSP Fig. 1 . The disadvantages of each can be greatly diminished. Service Management SystemŽ. SMS contains func- This is the issue that we investigate in this paper. tions to enable the management of the IN system. We organize the paper as follows: We introduce The Service Data PointŽ. SDP is a that the IN, TMN and TINA architecturesŽ. Section 2 . holds information related to the serviceŽ e.g., cus- Then, we show how the advantages of the two tomer profile. . The IN is provided with a Service environmentsŽ. i.e., the PSTN and the Internet can Creation EnvironmentŽ. SCE that contains service be used to create, deploy, control and manage com- development tools. among those ele- munication services in a more satisfactory wayŽ Sec- ments is done through the Common Channel Sig- tion 3. . In Section 4, we examine a number of nalling no. 7Ž. CCS7wx 6 . assumptions that have changed since the introduction Consider the implementation of Freephone. When of TINA. We show how this has changed the rules of the SSP detects the ``1±800'' pattern, it temporarily the in such a way that ``TINA as a solution'' suspends the basic call procedure and requests the should now be questioned; we also show that some of the SCP. The SCP realizes that the of the better concepts from TINA could be salvaged. communication fees must be charged to the called party, and asks the SDP for the physical address of this party. The response from the SDP is forwarded to the SSP which can then request the connection to 4 In this paper, by ``Internet'' we designate both the worldwide be set up between the two parties. network itself, and the underlying technology, namely TCPrIP The development of the IN has been organized in Ž.Transmission Control ProtocolrInternet Protocol . several phases, each of them being characterized by J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 259

Fig. 1. Simplified architecture of the intelligent network. a specific capability set. The oldest one is Capability the telecommunication activities. Among all different Set 1Ž. CS-1 , which covers single-ended services, interfaces, the main ones are the Q3 interfaceŽ lying, i.e., service that apply to one and only one party in a e.g., between an OS and the managed resource, or call and are independent of any other parties that between two OSs of a given management domain. may be participating in the call. Examples are num- and the X interfaceŽ lying between two OSs belong- ber servicesŽ e.g., , or ing to different TMN domains. . universal personal telecommunication. , alternate Although the TMN was defined with network billing servicesŽ. e.g., credit card calling , and screen- management in mind, it can be used to provide a ing servicesŽ e.g., originatingrterminating call wealth of other services. One of them is the Virtual screening, or security screening. wx 2 . Private NetworkŽ. VPN . The VPN is a telecommuni- The CS-1 is followed by two other phasesŽ i.e., cation service that provides corporate networking CS-2 and CS-3wx 2. which extend it with more between geographically dispersed customer premises; sophisticated capabilitieswx 2 . Much of the discussion it is based on a shared public switched network in this article addresses only CS-1. . The main features, which made up the early VPN specification intended for implementation 2.2. The telecommunications management network over the IN infrastructure, were Private Numbering PlanŽ. PNP , Closed User Group Ž CUG . , and security The Telecommunications Management Network wx5,7 . PNP is a feature that enables the customer to Ž.TMNwx 3 can be looked at from three points of define her own phonebook. CUG allows the cus- view: , functional architec- tomer to define groups of users; for example, there ture, and physical architecture. may be one CUG for top managers, another one for The TMN information architecture provides data researchers, and so forth. representation of the network resources for the pur- Fig. 2 shows the physical architecture of a VPN pose of monitoring, control and management. The configuration management systemwx 8,9 . The config- object-oriented approach is considered for the speci- uration management architecture consists of a set of fication of the information model. OSs:Ž. 1 the CPN OS that manages the CPN re- The TMN functional architecture describes the sources,Ž. 2 the PN OS that manages the public realization of a TMN in terms of different categories network resources,Ž. 3 the PN-service OS that is of function blocks and reference points among these responsible for the management of the services of- blocks. fered over the public networkŽ e.g., a virtual path The TMN physical architecture corresponds to the service in an ATM network.Ž. , 4 the CPN-service physical realization of the functional architecture. OS whose role is to administer the services provided Each function becomes a physical block, and over the CPN, and finallyŽ. 5 the VPN-service OS reference points are transformed into interfaces. The that manages the overall VPN service. The X inter- Operation SystemŽ. OS is an important physical face enables interactions among the VPN service block. It deploys the logic necessary for managing actorsŽ i.e., the customer, the service provider and 260 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273

Fig. 2. VPN physical management architecture. the network provider. . The Q3 interface lies between blesome. The TINA architecture was expected to OSs of a given management domain. solve this complex problem. The IN and TMN architectures overlapwx 10 . This is illustrated by the VPN example we have just presented. Indeed, the implementation of the VPN 2.3. The telecommunications information networking makes use of management primitivesŽ e.g., band- architecture width reservation within the network by means of management techniques. and therefore has to be A major design principle for TINA was the use of realized in the TMN. However, what happens if the distributed computingŽ e.g., Open Distributed Pro- VPN has to interwork with services supported by the cessing, ODPwx 11 and the Common Object Request IN, such as call forwarding or three-way calls? This Broker Architecture, CORBAwx 12. . The rationale example shows that unless both IN and TMN archi- behind this principle was the fact that architectures tectures are made more consistent, the interworking based on centralized scale badly when the of IN and TMN applications will be very difficult; number of services and service sessions increases. A interoperation between applications, developed worldwide consortium was set up in 1992, named the within two independent architectures, may be trou- TINA-Consortium or TINA-Cwx 4 .

Fig. 3. TINA objects involved in a service scenario. J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 261

TINA is composed of three architectures: After this brief overview of the telecommunica- Ø The computing architecture defines the concepts tion architectures, the next two sections are devoted for designing and building distributed software to the study of alternatives in the realization of these and the software support environment, based on architectures using the Internet. We start with tele- object-oriented principles. It describes the TINA phony services; they are basic services, from the Distributed Processing EnvironmentŽ. DPEwx 13 , understanding of which more complex applications which was recently recommended to be CORBA can be implemented. wx14 . Ø The serÕice architecture provides a set of con- cepts to build, deploy and manage TINA services 3. Using the Internet to unshackle telephony ser- wx15 . In a TINA system, a service consists of a set vices of components interacting with one another, and deployed over the DPE. The service architecture In this section, we present many advantages that defines the objects required for the realization of can be drawn from bridging the Internet and the a service, their composition and interactions. The Telecommunications worlds. We emphasize the ben- service architectureŽ. Fig. 3 can be illustrated by efits of using the Internet for service creation. Hence, considering the supervision of a com- we look at the porting of the main telecommunica- munication between two end-users. In this exam- tion architecture for service creation in PSTNsŽ i.e., ple, an audiorvideo session is established be- the IN. to the Internet. tween two objects corresponding to the two user Briefly, the strengths of the IN are:Ž. 1 legacy applications. Other objects, located in the service gained from the deployment of a large number of provider domain, supervise the session. services,Ž. 2 service creation using a simple and Ø The network resource architecture defines a small set of reusable Service Independent building reusable group of functions which manage net- BlocksŽ.Ž. SIB , 3 independence of the service Ž and work transport resources and, thus, provide con- the control thereof. from the network infrastructure, nection management that assists telecommunica- andŽ. 4 a thorough conceptual model for service tion servicesŽ. distributed applications in their creation which shows a gradual ``shrinking'' of a need for connections. service's complexity across the model's planes. A simplified representation of TINA is shown in The current weaknesses of the IN are:Ž. 1 limited Fig. 4. The Transport Network, typically based on : introducing a new service is very difficult ATM, contains the switching and transmission because there is no standard service creation envi- equipment in charge of the transportation of the user ronment, the call models used by the switches in the data. It is controlled by what we call in this paper the network are not the same, and service interaction Information Network, which is composed of the wx16,17 is still a challenging problem, andŽ. 2 limited kernel Transport Network Ž.kTN in TINA parlance, openness: between IN systems oper- and a set of applications implemented on top of the ated by different stakeholders is still an issue to kTN. The kTN is a network of nodes over which address and there are significant differences between CORBA is deployed. IN architecturesŽ e.g., the Advanced Intelligent Net-

Fig. 4. A simplified view of TINA. 262 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 work from Bellcore uses a protocol and a call model providers, and the lack of standards related to the that are incompatible with the ones recommended by management of the INwx 20 . the ETSI. . Regarding the Internet, its main strengths arewx 18 : 3.1. Interworking between the PSTN and the Internet Ž.1 an open service creation environment for content services,Ž. 2 a devolved service architecture manage- In this section, we present the general framework ment: each user can create and manage her own laid out by the IETF PINT working groupŽ Section service profile, for example a ,Ž. 3 ubiqui- 3.1.1. . Then, we report on realizations that fit into tous access via the Internet imple- the PINT reference model, particularly the WebIN mented world-wide,Ž. 4 hierarchical, scalable transla- architecturewx 18,21Ž. Section 3.1.2 . The focus of the tion service through a powerful Sys- PINT working group is on enabling the user to temŽ.Ž. DNS , 5 scalable resource location Ž support- request IN-supported services from the Internet. We ing over 20 million today.Ž. , 6 standardized shall see that WebIN deploys a higher number of resource accessŽ.Ž. HTTP, CGI, MIME , 7 standard- control mechanismsŽ. not only request mechanisms ized service logic languagesŽ.Ž. HTML, Java , and 8 on the Internet than intended by the PINT group. very fast service deployment environmentŽ Web Lastly, Section 3.1.3 presents a possible implementa- pages and CGI scripts easily written. . tion of the VPN over a combination of PSTN and The current weaknesses of the Internet are:Ž. 1 Internet. relatively low level of securityŽ even if this level is increasing, the public is still skeptical.Ž. , 2 only 3.1.1. The PINT reference model best-effort in the current imple- The IETF PINT group suggested a way that ser- mentation,Ž. 3 little commitment of Internet Service vices currently provided over PSTNs could take ProvidersŽ. ISP to guarantee quality of service within advantage of the strengths of the Internet. They and across their domain. proposed a framework which achieves this inwx 19 There are two tendencies toward bringing to- Župdated inwx 22. . This on-going work emphasizes gether the advantages of the Internet and the the interfaces between the modules that make up the Telecommunications worlds. The first tendency uses frameworkŽ. Fig. 5 . The main modules are: Service the PSTN as the transport infrastructure, but NodesŽ. SN , Service Management Systems Ž SMS . , devolves part of the request mechanisms to be run on Web Servers, PSTNrInternet Gateways, Service the Internet. This tendency is exemplified by the Control PointsŽ. SCP , Central Offices, and Mobile work going on within the PSTNrInternet Interwork- Switching CentersŽ. MSC . The main difference be- ingŽ. PINT groupwx 19 at the Internet tween an SN and an SCP is that, unlike the latter, Task ForceŽ. IETF . The PINT contribution is de- SNs can perform switching functions as well as scribed in Section 3.1. activities traditionally carried out by specialized re- The second tendency alleviates the PSTN as the sourcesŽ such as voice recognition devices, and text principal infrastructure for the transport of user data, to audio transcoders. . In simpler terms, if switching and promotes the Internet as a serious alternative for or specialized functions are needed, then SNs must conveying this data. As a result, the complete tele- be used instead of SCPs. phony service architecture will be deployed over the Four services are considered as case studies for Internet: this is IP telephonyŽ. Section 3.2 . the reference model in Fig. 5. These services are: Both tendencies are presented in the following Click-to-Dial, Click-to-Fax, Click-to-Fax-Back, and sections, and some of their strengths and weaknesses Voice-Access-to-Content. Consider the usage and are revealed in the context of the Virtual Private implementation of the Click-to-Dial service. While NetworkŽ. VPN which is historically one of the browsing the Web page of a company, a user be- services that first demonstrated the limitations of the comes interested in talking to a representative. IN model in providing fairly complex services. These To do so, she simply clicks on a button to send her limitations are mainly due to the lack of interwork- request. The user is understood to request the phone ing between IN systems operated by different connection to be set up between her telephone equip- J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 263

Fig. 5. Reference model for PSTNrInternet InterworkingŽ.Ž PINT augmented fromwx 19. . ment and the one of the sales representative. The Internet. This effort was spent by several companies Web of the company concerned forwards the like Siemenswx 25 , Hewlett±Packard wx 21 , IBM wx 26 , request to a PSTNrInternet gateway which, in turn, and Vocaltec Communicationswx 27 . None of their calls the Service NodeŽ. SN through an A interface solutions, except that from Hewlett±Packard, ad- Ž.Fig. 5 . Upon receipt of the request, the SN deter- dressed the particular issue of porting the IN archi- mines which sales representative to call; the com- tecture to the Internet. Consequently, we concentrate pany may have subscribed to a call distributionŽ or on the project from HP, which was developed at the . service. Afterwards, the SN passes the cho- HP in Bristol, UK. The main outcome of sen representative's address to the central officeÐor this project is a prototype architecture called WebIN the mobile switching centerÐto initiate the call. Ž.Fig. 6 . WebIN resembles the IN standard architec- This is done through either the C or I interface. The ture, except in three respects:Ž. 1 SDPs and the SMS company can update its profile by interacting, via the are connected to the Internet;Ž. 2 SCPs are connected , with the SMS through a B interface to SDPs through a DPE that could be either the Web which is based on the Simple Network Management Ž.HTTPrCGI or CORBA; Ž. 3 the role of the SCP is ProtocolŽ. SNMPwx 23 . confined to finding out the correct reference of the The thorough description of the interfaces be- SDP that corresponds to the service actually invoked. tween the components of the PINT reference model Note that in Fig. 6 the SCEŽ Service Creation is under specification. These interfaces are cast with Environment. is located within the Internet domain. respect to their relevance to the standards bodies at Hence, WebIN can benefit from the easy service play, namely the IETF and the ITU. The interfaces creation environmentŽ. HTML, Java, etc. on top of A, B, and E would be standardized by the IETF, the Internet. After the service logicŽ using while the ITU would deal with the restwx 24 . HTML, Java, , etc.. , the service creator simply Many implementation efforts were carried out in her service logic into the Web server dedi- the area of InternetrPSTN interworking. In the fol- cated to her. lowing section, we report on some of them. 3.1.3. ProÕision of the Virtual PriÕate Network() VPN 3.1.2. Realization of InternetrPSTN interworking serÕice A great deal of effort was expended in the past on In this section, we show how well a fairly com- the design of gateways between the PSTN and the plex service such as the VPN is currently imple- 264 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273

Fig. 6. The WebIN physical architectureŽ adapted fromwx 28. . mented over the PSTN, and how it could be provided Že.g., not being able to generate calls to outside of using the Internet for control and management. We the company, not being able to interact with people consider two sites located in two different countries outside the CUG, etc.. . After everything is checked, serviced by two public operators. the SSP related to user A is instructed to generate a call request to user B's physical address. The same 3.1.3.1. VPN implementation oÕer the PSTN. Con- processing phases take place when user B wishes to sider user A in Lausanne, Switzerland, wishing to communicate with user A. The IN system in the communicate with user B in New York, USAŽ Fig. USA is understood to comply with Bellcore AIN, 7. ; both users belong to the same VPN. Since two IN while the one in complies with ETSI recom- from different operators rarely inter- mendations. As mentioned in the introduction of operate, the PNP and CUG descriptions must be Section 3, the two IN systems considered in the implemented in both networks. User A uses the example are incompatible. Therefore, the VPN pro- extension number to communicate with user B. A file must be duplicated in each IN infrastructure. The translation from extension numbers to physical tele- consistency of this profile everywhere then becomes phone addresses is needed at the SCP connected to an issue in the very likely situation where all the the SSP, which user A is attached to. The physical are not updated at the same time. Consider number of user B is then found. Furthermore, the that we move user A from one CUG to another in SDP, that holds the VPN database of the company of the same VPN. If the change is not simultaneously interest, checks whether the two users belong to the reflected everywhere, user A will be using the privi- same CUG and are not subject to any call restrictions leges of the two CUGs for some time.

Fig. 7. Provision of a VPN service across two IN provider domains. J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 265

3.1.3.2. Running the VPN control system on the can be assured by using tunneling and data encryp- Internet. Fig. 8 depicts a possible realization of the tion techniques. Improving the efficiency of the VPN service in a context that uses the Internet to run scheme needs more research. the control system. The SSP associated with the The PINT reference model described above still caller, issues a request to the SCP with the caller'sÐ uses the PSTN as the medium carrierŽ i.e., communi- as well as the callee'sÐidentity and telephone num- cations still go through the PSTN. . A radically dif- ber. Each IN operator is given the address of a Web ferent approach is taken by the promoters of tele- server where the service data and logic can be phony over the Internet. In their scheme, not only requested. The Web servers attached to the SCPs part of the control system runs on the Internet, but all cooperate through the Internet in order to find the the control as well as the user information transfer right location of the data needed. Specifically, the will be achieved using the Internet. This approach is data related to the CUG to which users A and B described in the next section. belong, may not be held by the server attached to the SCP in Lausanne. Assuming that the CUG data 3.2. IP telephony: the Internet as a transport net- resides on the server attached to the SCP in New work York, there will be interactions, over the Internet, between the two servers involved. Therefore, the The tremendous market penetration of the Internet PNP and CUG profiles can be split over the servers makes it possible to envisage its use as an integral used, and there is no need for data duplication voice transport network. Schulzrinnewx 29 assessed Ž.unlike in the case described in Section 3.1.3.1 . the situation of both the Internet and the legacy Changes in the VPN profile are immediately re- telephone system. He provided valuable motivations flected. Therefore, the lack of interoperability be- for re-engineering the latter. However, there are tween IN infrastructures is solved in a simple way in issues that undermine the provision of telephony the case where the control and management system services on the Internet: the costŽ do we really want is run on the Internet. Moreover, the customer can to buy a $2000 phone, even though we may use it for update the VPN profile through the Internet; she other purposes?. , and the delay suffered by packets therefore is equipped with control and management traveling on the Internet. Both issues, especially the capabilities over her service. She can perform these last one, are being worked on intensely, as we report tasks without interacting with the VPN service below. providers. In Section 3.2.1, we present the overall - However, running the control system on the Inter- work for IP telephony. In Section 3.2.2, we propose net presents a number of issues such as security and a technical implementation framework that identifies efficiencyŽ the processing of a service request can the main protocols to be used when providing IP take a longer time than in the legacy IN. . Security telephony. In Section 3.2.3, the provision of the VPN

Fig. 8. A realization of the VPN service with the control system. 266 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 service within the IP telephony framework is briefly its absence, however, undermines interoperability discussed. among differing network technologies. Therefore, H.323 fully fits within the framework depicted in 3.2.1. Architecture Fig. 9. The internal architecture of a gateway is not A standard framework for IP telephonyŽ. Fig. 9 prescribed in H.323; a possible layout can be found was proposed by Sinnreich and Young inwx 30 . The inwx 25 . An H.323 gatekeeper performs network ad- main ideas behind this architecture are continuous ministration, re-negotiation and address data through the InternetŽ unlike the work translation. H.323 terminals must get permission from described in Section 3.1. , and interoperability among the gatekeeper before they can place or accept a call. legacy telephone equipment and . Four A gatekeeper is not required in an H.323 system; groups of possible interactions were identified:Ž. 1 however, its presence empowers the network admin- gateway-to-gateway signaling and information trans- istrator with much control over the network, and ,Ž. 2 interactions between the SCP and the gate- provides users with the possibility to define alias way databases,Ž. 3 PC-to-network signaling, and Ž. 4 addresses that are independent of the network ad- management information flow. dresses. The gatekeeper is a helpful component that can be used to implement many supplementary ser- 3.2.2. A Technical implementation framework vices such as some of those currently supported by Two relevant proposals for IP telephony are the the INŽ. e.g., call forwarding, call screening . ITU-T recommendation H.323wx 31±33 and the Ses- SIP is a protocol that enables the invitation of sion Initiation ProtocolŽ. SIPwx 34 being worked on at users to participate in multimedia sessions. It also the IETF. enables user mobility by forwarding invitations to H.323's primary goal is to enable audiovisual the user's current location. A more precise descrip- interactionsŽ i.e., provision and control of audior tion of the use of SIP for IP telephony can be found video interactive services. among terminals situated inwx 35 . Unlike H.323 which describes an entire in various environments withrwithout Quality of system encompassing many network technologies, ServiceŽ. QoS guarantees. The key H.323 compo- SIP has a more limited scope; it is mainly intended nents that are important to our discussion here are for the Internet. the gateway and the gatekeeper. An H.323 gateway There is one issue that neither H.323 nor SIP have is in charge of translating call signaling, control currently addressed: the resource reservation style to messages and techniques across the net- be used within the Internet. This style may be any of work technologies involved in the call. While the that by the IETF Integrated ServicesŽ. int-serv group, gateway is an optional element in an H.323 system, the one proposed by the

Fig. 9. A standards framework for IP telephonywx 30 . J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 267

Ž.diff-serv group, the YEt another Session The main strength of these alternatives over RSVP Internet ReservationŽ. YESSIR protocolwx 36 , or the is that they demand little modification in the routers Scalable Resource Reservation ProtocolŽ. SRPwx 37 . as currently implemented. Guerin wx 45 gives a more The int-serv group proposes an detailed discussion on new trends for delivery in architecturewx 38 that recommends the Resource packet networks. Moreover, an interesting critique of reSerVation ProtocolŽ. RSVPwx 39,40 as the protocol the Internet paradigm for real-time services is given to be used for reserving resources in the Internet. inwx 46 . Two network services can currently be requested with RSVP: guaranteed servicewx 41 and controlled- wx 3.2.3. ProÕision of the VPN serÕice load service 42 . The former service guarantees the The provision of the VPN service within the IP Ž. traffic burst, average rate and reservation parame- telephony realm is straightforward from Fig. 8: SSPs Ž. ters bandwidth, delay, and losses negotiated at the can be replaced by QoS-capable routers, and the connection setup time. Guaranteed service is re- WebSCP can be replaced by a SIP server. The quired by applications that have tight quality require- control of the VPN service will be achieved through ments. The controlled-load service guarantees only interactions among these servers: the address of the the traffic characteristics negotiated. It can be re- Web site that the VPN profile will be given by quested by applications that can adapt to the network a SIP server. state. Over the years, RSVP showed a number of draw- backs, importantly the necessity to keep the state of 3.3. Conclusion on telephony serÕices each and every flow that travels through the . The state information to be kept will then grow In this section, we have presented the influence of significantly as the number of users increases. This the Internet on the IN through the two main tenden- weakness has steered new alternatives, such as cies identified from the literature. These tendencies Ø YESSIR: an extension of the Real-time Transport are: use of the Internet to implement part of the ProtocolŽ. RTPwx 43 to support resource reserva- service control system, and consideration of the In- tion along the path between the sender and the ternet as a competing medium transport infrastruc- receiver; ture to the legacy PSTN. We assessed how well the Ø Differentiated serviceswx 44 : a scalable resource tendencies support a fairly complex service, i.e., the reservation style that aggregates packets from dif- VPN. We could show that interoperation among IN ferent sources into a number of service classes. infrastructures can be achieved when the Internet is These packets are then treated according to the used to run the service control systemŽ. Fig. 8 . class to which they belong. Compared to the Moreover, the customer can update the profile of his int-serv solution, diff-serv proposals reason in VPN without interacting with the service provider. terms of service classes, instead of flows with Services can therefore be easily created. specific source and destination addresses. In this Even though the two tendencies outlined already way, the state information to be kept by the have major implementations, there are many issues routers is proportional to the number of service yet to be solved. For the tendency exemplified by the classes. PINT working group, clear interface specifications Ø SRP is a reservation protocol which achieves between the framework elements are still to come, scaling for a large number of flows by aggrega- whereas several inconsistency flaws infect the IP tion on each link in the network. Users do not telephony frameworkwx 46 . Nevertheless, there is se- explicitly connection parameters; instead, rious likelihood that the two solutions will be de- mark packets not covered by an existing ployed on a large scale in the future. reservation as REQUESTs. A router's decision to After discussing the impact of the Internet on accept a REQUEST packet is based on an esti- telephony services, we concentrate, in the next sec- mate from measurements of already reserved traf- tion, on the future of the TINA architecture within a fic. context more and more in favor of the Internet. 268 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273

4. An outlook for TINA Ø The IN CS-1 was already partially deployed at the time TINA was launched; the IN had proved 4.1. Introduction and assessment of the current situa- its ability to support a significant number of tion Ž.voice-based services. Ø The World-Wide Web was still in its prototyping From its very beginning, TINA has been a project phase, and very few telecommunication compa- funded and carried out by the traditional telecommu- nies had realized at that time its latent power. nication companies, namely the network operators Ø Network operators had an understandable reluc- and their equipment providers. These powerful stake- tance to see their role reduced to that of humble holders couldŽ. and still can have leverage on the connectivity providers. following factors: In the meantime, the Internet showed certain dy- Ø high dependability of the services they provide namicity in service provisioning, which is not quite Žwireline and telephony, ISDN, data the case of TINA: New softwareŽ e.g., Java applets transfer over X.25, Frame Relay and Switched wx47. can be downloaded by terminals during an Multimegabit Service ± SMDS. ; ongoing session. TINA should then be revised in Ø strong internal research effortŽ but sometimes with order to take into account the possibility for some a limited awareness of what is happening ``out- objectsŽ. Fig. 3 in the service provider domain to be side''. ; executed in the customer domain, because of the Ø in most cases, strong dependence on the political increasing processing power and ``intelligence'' of power of their home country. the end-systems. These factors proved to be extremely efficient Network operators and service providers should even in the recent past, allowing very ambitious realize that the interface between the terminal and projects to be defined and implemented on a wide the network does not necessarily correspond to the scale; one of the most convincing examples to illus- management responsibility border between the ser- trate this capacity is the successful deployment of the vice provider and the user. For instance, a service GSMŽ. Global System for Mobile communications consisting in hosting Web pagesŽ. of a company can in Europe and in many other regions around the be provided by an operator or a third party. In this world. case, the company outsources information and net- However, these factors can also become weak- work-related services to another service actor; we nesses if the rules of the game are suddenly modi- believe that this is a key new way to look at service fied, and especially if the evolution of the telecom- provision. Beyond outsourcing, operators should also munications business becomes dramatically unpre- concentrate on the provision of services that are dictable. To some extent, TINA has been a victim of better supported by the operating the this change. To better understand what happened, it connectivity means. This may be because is worth having a close look at some of the, explicit of scale can be found, or because the placement of or implicit, assumptions on which the TINA initia- the service inside the network bears some fundamen- tive is based. It is important that previously ingrained tal advantages. Examples are mobility mechanisms, doctrines and solutions based on it, be re-evaluated which allow the users to access the same services in order to determine whether they still make sense. from anywhere, as well as routing mechanisms. By This will help us better identify the future perspec- concentrating on these aspects, network operators tives. can protect themselves from becoming mere connec- tivity providers and revitalize their role in the provi- Assumption 1. The services will continue to be sion of services to end-users. provided by the network or network-based servers Assumption 2. The B-ISDN will be based on end- rather than the end-user terminals. to-end ATM. This emphasis on the role of the network might be ATM was defined with the precise goal of being defended given the following arguments: the transfer mode to support B-ISDN. In spite of the J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 269 fact that TINA tried to remain technology indepen- notŽ. yet fully responded to the challenge of the dent, the transport network of TINA was usually provision of multiparty, multimedia services. In par- considered to be a high-speed and connection-ori- ticular, the guarantee of a given quality of service is ented network. The possibility of coping with a still problematicwx 46 . This means that even if TINA connectionless transport network has only been taken will never be implemented to the extent it was into account recentlywx 48 . initially intended, some of the better concepts could New technologies, such as the Gigabit be re-used. Recently, several TINA proponents have wx49 and Terabit SwitchesrRouters wx 50 , can deliver been studying the applicability of TINA to the Inter- satisfying QoS with less overall complexity than netwx 52±55 . ATM. Therefore, it is likely that the B-ISDN will What can be salÕaged from TINA? Certainly, the leverage on these technologies, at least in access idea of deploying an Object Request BrokerŽ. ORB , networks, while ATM will mainly stand as a back- such as CORBA, in order to support sophisticated bone network technology. and distributed supervision functions, has a strong potential. Unlike TINA-C, we believe that is is unre- Assumption 3. The pace of the telecommunications alistic to entrust the establishment and release of evolution will remain under the control of the main communications to the kTN, because its ORB-based telecommunication stakeholders. philosophy cannot currently cope with the real-time nature of the problem in a efficient way. Even though progress is being made in ORBs to support This assumption is clearly based on the real-time services, the performance achieved is still monopolisticŽ. or oligopolistic tradition of this do- low, compared to that of typical solutions using main; for decades, and until only recently, it has conventional signaling or routing of IP frames, with- been almost impossible for a newcomer to capture a out any middleware in between. Therefore, commu- share of the Telecommunications market, at least as nication establishment and release, as well as data- a network operator. Assuming that the pace of evolu- stream transport, are better performed by the Trans- tion can be controlled as before, reflects a nostalgia port Network. Hence, it is most probably in the area of the golden age, during which the former CCITT of management, and management-based services, that Ž.now ITU-T would issue a set of new recommenda- the kTN of TINA can be useful. tions at the end of four-year-long study periods. The A possible integration of the Internet with the TINA Consortium followed the same step. TINA architecture, based on the above analysis, is Meanwhile, the development of the Internet pro- shown in Fig. 10Ž which is derived from Fig. 4 by tocols has proved that it is possible to ``do first and replacing ATM with IP. . Unlike with TINA, the standardize later''. Incremental deÕelopment is now establishment and release of short-lived flows, or a usual practice, which unbelievably speeds up the connections, in the architecture that we propose here development process. would be fully achieved within the Transport Net- TINA is not the only victim of the change intro- work itself. This would alleviate the lack of perfor- duced by the Internet; the legacy mance observed when the connections are entrusted was also shaken out. Isenbergwx 51 assessed this to the Information NetworkŽ due to the high impact by analyzing, as we did for TINA, the as- of CORBA. . The Information Network would be sumptions made by operators of the telephone net- devoted to functions that require a more sophisti- work. catedŽ. albeit slower software machinery. This could include service management and billing, and could 4.2. What can be salÕaged from TINA be based on a distributed object-oriented framework such as CORBA. This evolution is compliant with In the previous section, we have seen that most of the trends in network management researchwx 56 . the assumptions which led to TINA are no longer Communications among the nodes of the Informa- valid because of the complete change in landscape tion Network and the routers of the Transport Net- brought on by the Internet. However, the Internet has work would be supported by SNMP. 270 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273

Fig. 10. A possible integration of the Internet with the TINA architecture.

Control and management functionsŽ e.g., billing, allocation between assured and best-effort services is resource management, and fault management. , lo- described inwx 57 . cated within the of the Information The provision of the VPN service, as defined in Network, interact by means of an Application Layer Section 2.2 and discussed throughout Section 3, ProtocolŽ. ALP , which is the Common Management would be easy to implement within the proposed Information ProtocolŽ. CMIP in the case of the OSI architecture: all Operation Systems would reside in management model. The interface between two co- the Information Network; they would monitor the operating network provider domains is then a TMN resources devoted to the assured services, in the X interfaceŽ. see Section 2.2 . The application pieces Transport Network. use the kTN to communicate with one another. The Another aspect that can be salvaged from TINA is Internet Inter-ORB protocolŽ. IIOP supports the the idea of generic session control. In the IETF, communication between kTNs of different network there is a tendency to keep creating new protocols, operators, and can help implement the functionality leading to a growing complexity of the software on of a TMN X interface. the terminals; the genericity endeavor of TINA can As for the Transport Network, it is understood to be useful for the implementation of the numerous provide two categories of services: assured services functions that we placed in the Information Network. and best-effort services. We define an assured ser- The TINA initiative can be salvaged provided: Õice as a serÕice that requires some resource reser- Ø the 3 assumptions discussed in Section 4.1 are Õation mechanism from the network; this service reconsidered, may be firmŽ e.g., guaranteed service considered in Ø the importance of the Internet is recognized, wx41.Ž or looser e.g., the controlled-load servicewx 42. . Ø the focus is set on the most important technical In this case, the network operator is expected to challenge: the provision of information services establish connections with the requested QoS. In the based on the Internet, case where the technology supporting the IP network Ø the attempt to define an framework from is an ATM backbone, the connectivity is provided by scratch is avoided, even for management services. means of Virtual Path Connections or Virtual Chan- The second phase of the TINA projectŽ 1998± nel Connections. In a pure IP 2000. wx 58 integrates part of our critique. The impor- Ž.not based on ATM , reservations can be made by tance of the Internet is being partially taken into RSVP or by newer reservation styles such as differ- account, and more emphasis is being laid on the entiated serviceswx 44 . One way to optimize resource implementation of the solutions proposed. J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 271

5. Conclusion assumptions reflected the situation years ago, when the Internet was just that ``toy network'' without any The tight boundaries that grew up over time potential to compete with telecommunication net- between the telecommunications and the Internet works. The advent of the Web and advanced tech- worlds have been falling apart for the last few years; nologies such as Java brutally changed the course of these worlds can no longer ignore each other. The things, and drove the telecommunications world into successful ideas of both communities are being an embarrassing position. We elaborated on the TINA brought together in order to create a new paradigm ideas that are likely to survive; these are the concept that satisfies all of the actors involved in the provi- of generic session control and the use of ORBs. This sion of services, using technologies from the two led us to an architecture made up of two main realms. The dependability and reliability of guaran- networks: an IP-based Transport Network and a teed services in the telecommunications world can CORBA-based Information Network. The establish- inspire the Internet community. Conversely, the case ment of short-lived connections is entrusted to the of service creation, deployment, control and manage- Transport Network, while long-lived connections are ment, that characterizes the Internet can help allevi- enforced by the Information Network, which also ate some of the weaknesses of the telecommunica- supports service control and management mecha- tions world. nisms. The Transport Network can cope with both In this paper, we investigated the impact of the best-effort services and assured services. Internet on the main telecommunication architectures A crucial issue is the study of the convergence of Ž.i.e., the IN, TMN and TINA . We used the VPN as the Internet and the Telecommunications worlds. In a case study to assess the influence of the Internet particular, the comparison of mobility services in the over these architectures. two worlds, and the way they can be integrated, are Two tendencies were outlined for the interwork- key notions that we are currently investigating. ing between the PSTN, over which the IN is de- ployed, and the Internet. The first tendency keeps the PSTN as the only transport infrastructure, but de- Acknowledgements volves part of the request mechanismsŽ e.g., service data and logic. to be run on the Internet. A reference The authors are indebted to the Guest Editors and model for this tendency is proposed by the IETF the reviewers for their relevant feedback PINT group. We sketched an implementation of the which helped improve the quality of the article. They VPN service which uses the Internet to run the also wish to express their gratitude to Joergen Dyst, control system. We then showed that interoperation Tim Eckardt, Pierre-Alain Etique, Igor Faynberg, between any two IN systems operated by different Henning Schulzrinne and Chris Smith, as well as stakeholders can be easily achieved. This interopera- Holly Cogliati, Sebastian Staamann, Paul Hurley, tion is still a problem in existing IN systems, even Falk Dietrich and Xavier Logean for their valuable though the IN standards were released a long time inputs to, and comments on this paper. ago. The second tendency towards using the Internet to deploy telephony services, promotes the Internet as an integral transport infrastructure: this is IP References telephony. wx1 I. Faynberg, L.R. Gabuzda, M.P. Kaplan, N.J. Shah, The We did not directly address the ``porting'' of the Intelligent Network Standards, their Application to Services, TMN to the Internet, since TMN is rather a frame- McGraw-Hill, New York, 1996. work than a real architecture with well specified wx2 T. Magedanz, R. Popescu-Zeletin, Intelligent Networks: Ba- elements. However, the problems that this might sic Technology, Standards and Evolution, Intl. Thomson cause are revealed in our study of the influence of Computer Press Ed., 1996. wx3 ITU-T, Principles for a Telecommunications Management the Internet on TINA. We started with the examina- Network, Rec. M.3010, May 1996. tion of some relevant assumptions that led to the wx4 W.J. Barr, T. Boyd, Y. Inoue, The TINA initiative, IEEE complexity of the solutions proposed by TINA. These Communications MagazineŽ. March 1993 70±76. 272 J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273

wx5 ITU-T, Introduction to Intelligent Network Capability Set 1, Proc. IEEE ICCCN '97, Las Vegas, Nevada, September Rec. Q.1211, March 1993. 1997. wx6 A.R. Modaressi, R.A. Skoog, Signaling system no. 7: a wx26 IBM, CallPath Developers Toolkit, 5th ed., June 1996. tutorial, IEEE Communications MagazineŽ. July 1990 19±35. Available as http:rrwww.hursley.ibm.comrcallpathrkhsl4r wx7 J.-P. Gaspoz, Object oriented method and architecture for khsl4mst.. virtual private management, Ph.D. Disserta- wx27 VocalTec Communications, The VocalTec Telephony Gate- tion No. 1446, Communication Systems Division, Swiss way White Paper. Available as http:rrwww.vocaltec.comr Federal Institute of Technology, Lausanne, Switzerland, 1995. productsrgtwrgtw_intro.htm. wx8 J.-P. Gaspoz, J.-P. Hubaux, S. Znaty, A generic architecture wx28 C. Low, The Internet telephony red herring, Proc. IEEE for VPN configuration management, Journal of Network and GLOBECOM '96, , UK, November 1996. 4Ž.Ž 4 1996 . 375±395. wx29 H. Schulzrinne, Re-engineering the telephone system, Proc. wx9 J.-P. Gaspoz, Methodology for the development of dis- IEEE Singapore Int. Conf. on NetworksŽ. SICON '97, Singa- tributed telecommunication services, Journal of Systems and pore, April 1997. Software, 1996. wx30 H. Sinnreich, J. Young, Standards framework for Internet wx10 G. Pavlou, D. Griffin, An evolutionary approach towards the telephony, Draft Proposal for the IETF PINT WG, Munich, future of IN and TMN, Interoperable Communication Net- Germany, August 12±15, 1997. works, Special Issue on Telecommunication Services, 1 wx31 ITU-T, Visual Telephone Systems and Equipment for Local Ž.1998 1±16. Area Networks which Provide a Non-Guaranteed Quality of wx11 ITU-T, Basic Reference Model of Open Distributed Process- Service, Rec. H.323, Geneva, Switzerland, November 1996. ing ± Part 1: Overview and Guide to Use, Rec. X901, 1994. wx32 J. Toga, J. Ott, ITU-T activities for interac- wx12 OMG, The Common Object Request Broker: Architecture tive multimedia communications on packet-based networks: and Specification, Rev. 2.0, July 1995. H.323 and related recommendations, Computer Networks 31 wx13 TINA-C, TINA Distributed Processing EnvironmentŽ TINA- Ž.1999 205±223, this issue. DPE. , TINA-C Deliverable No. TB_PL001_1.0_95, July wx33 G.A. Thom, H.323: the multimedia communications standard 1995. for local area networks, IEEE Communications Magazine 34 wx14 S. Vinoski, CORBA: integrating diverse applications within Ž.Ž12 1996 . 52±56. distributed heterogeneous environments, IEEE Communica- wx34 M. Handley, H. Schulzrinne, E. Schooler, SIP: Session Initia- tions MagazineŽ. February 1997 . tion Protocol, Internet Draft, 31 July 1997. wx15 TINA-C, Service Architecture, Vers. 5.0, 16 June 1997. wx35 H. Schulzrinne, J. Rosenberg, Internet telephony: architecture wx16 P.-A. Etique, J.-P. Hubaux, X. Logean, Service Specification and protocols ± an IETF perspective, Computer Networks 31 and Validation for the Intelligent Network, Interoperable Ž.1999 237±255, this issue. Communication Networks, Special Issue on Telecommunica- wx36 P. Pan, H. Schulzrinne, YESSIR: a simple reservation mech- tion Services, 1Ž. 1998 41±69. anism for the Internet, IBM Research Report, RC 20967, T.J. wx17 P.-A. Etique, Service specification, verification and valida- Research Center, September 1997. tion for the Intelligent Network, Ph.D. Dissertation No. 1442, wx37 W. Almesberger, T. Ferrari, J.Y. Le Boudec, SRP: a scalable Communication Systems Division, Swiss Federal Institute of resource reservation protocol for the Internet, Technical Re- Technology, Lausanne, Switzerland, 1995. port, March 1998. Available from http:rrlrcwww. wx18 J. O'Connell, P. Hoft, Web-IN: integrating intelligent net- epfl.chrsrp. works and the Internet, HP white paper, 30 November 1996. wx38 R. Braden, D. Clark, S. Shenker, Integrated Services in the wx19 I. Faynberg, M. Krishnaswamy, H. Lu, A Proposal for Internet Architecture: an Overview, IETF Informational RFC Internet and Public Switched Telephone NetworksŽ. PSTN 1633, Network Working Group, June 1994. , Internet Draft, March 1997. wx39 L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, wx20 RACE Project PREPARE, IBC VPN Services, Specification RSVP: a new Resource reSerVation Protocol, IEEE Net- CFS D721, December 1993. work, 1993. wx21 C. Low, Integrating communication services, IEEE Commu- wx40 R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, nications Magazine 35Ž.Ž 6 1997 . . Resource ReSerVation ProtocolŽ. RSVP ± Version 1 Func- wx22 M. Krishnaswamy, PSTN-Internet Interworking ± An Archi- tional Specification, IETF RFC 2205, September 1997. tecture Overview, Internet Draft, November 1997. wx41 S. Shenker, C. Partridge, R. Guerin, Specification of Guaran- wx23 J. Case et al., Protocol Operations for Version 2 of the teed Quality of Service, IETF RFC 2212, September 1997. Simple Network Management ProtocolŽ. SNMPv2 , IETF wx42 J. Wroclawski, Specification of the Controlled-Load Network RFC 1905, Draft Standard, January 1996. Element Service, IETF RFC 2211, September 1997. wx24 L. Conroy, M. Lautenbacher, R. Scholl, Analysis of Services wx43 H. Schulzrinne, S. Casner, R. Frederik, V. Jacobson, RTP: A and Interfaces used when Interworking the Internet and the Transport Protocol for Real-time Applications, IETF RFC Intelligent NetworkŽ. I.N. , Internet Draft, July 1997, Work in 1889, January 1996. progress. wx44 K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated wx25 P. Simeonov et al., @INGate: A Distributed Intelligent Net- Services Architecture for the Internet, Internet Draft -draft- work Approach to Bridge Switching and Packet Networks, nichols-diff-svc-arch-00.txt), November 1997. J.-P. Hubaux et al.rComputer Networks 31() 1999 257±273 273 wx45 R. Guerin, V. Peris, Quality-of-service in packet networks: Constant Gbaguidi graduated in at EPFL, basic mechanisms and directions, Computer Networks 31 Lausanne, Switzerland, in 1995. Since then, he has worked at Ž.1999 169±189. EPFL as a research and teaching assistant in telecommunication wx46 D. Hutchison, R. El-Marakhy, L. Mathy, A critique of services and management. His diploma thesis was on an imple- modern Internet protocols: the issue of support for multime- mentation of a Virtual Private NetworkŽ. VPN over the OSF's dia, Proc. ECMAST '97, Lecture Notes in Computer Sci- EnvironmentŽ. DCE . In the summer of ence, vol. 1242, Springer, Berlin, 1997, pp. 507±522. 1996, he was a Visiting Scholar at , New wx47 D. Flanagan, Java in a Nutshell, A Desktop Quick Reference York, where he worked with the COMET group on porting a for Java Programmers, O'Reilly, May 1996. network prototyping framework to CORBA. Currently, his inter- wx48 H. Kim, F. Steegmans, N. Narayanan, J. Rajahalme, Manag- ests span distributed computing, QoS management, and use of the ing TINA streams that use Internet transport, Proc. TINA Internet to facilitate service management. '97. wx49 R. Mandeville, D. Shah, Gigabit gets it done, Data Commu- Shawn Koppenhoefer was born in Canada in December 1968. He nications MagazineŽ. February 1998 . Available as http:rr successfully completed a double honours program at the Faculty www.data.comrlab_testsrethernet.html. of Mathematics of the University of Waterloo in 1990. From 1990 wx50 Avici Systems, The World of Terabit SwitchrRouter Tech- to 1996 he was a research assistant in the Industrial Computing nology, March 1998. Available as http:rrwww.avici.comr at the Swiss Federal Institute of TechnologyŽ. EPFL . htmlrwhite_paper.html. In 1996, he successfully completed his Ph.D. Dissertation on wx51 D. Isenberg, Rise of the Stupid Network, June 1997. Avail- formal abstractionsrmodels of synchronous time-critical control able as http:rrwww.computertelephony.comrctratt.html. systems. At the start of 1997 he was invited to join the Telecom- wx52 C. Smith, Applying TINA-C service architecture to the Inter- munications LaboratoryŽ. TCOMrTSG and he started teaching an net and , Proc. TINA '97. introductory course on Networks and Protocols. Currently, he can wx53 G. de Zen et al., Value-added Internet: a pragmatic TINA- be found in the Department assuming teach- based path to the Internet and PSTN integration, Proc. TINA ingrresearchradministrative responsibilities in the newly created '97. ICA institute. His professional areas of interest include security in wx54 C.A. Licciardi, R. Minerva, C. Moiso, G. Spinelli, M. network management, online validation of telecommunication ser- Spinolo, TINA and the Internet: an evaluation of some vices, cryptographic protocol analysis and the study of formal scenarios, Proc. TINA '97. logics of trust and belief. wx55 F. BoujemaaŽ. Ed. , Introduction of Distributed Computing Middleware in Intelligent Networks, White Paper P.508. Jean-Yves Le Boudec was born in France in 1958. He graduated DC-MIN.10, Vers. 10.0, EURESCOM Project P508, 31 July from Ecole Normale Superieure de Saint-, Paris, where he 1997. obtained the Aggregation in Mathematics in 1980. He received his wx56 J. Pavon, J. Tomas, Y. Bardout, L. Hauw, CORBA for doctorate in 1984 from the University of Rennes, France, and network and service management in the TINA framework, became an Assistant Professor at INSArIRISA, Rennes. In 1987 IEEE Communications Magazine 36Ž.Ž 3 1998 . 72±79. and 1988, he was with Bell Northern Research, , Canada, wx57 P. Oechslin, J.-Y. Le Boudec, IMMuNe framework docu- as a member of scientific staff in the Network and Product Traffic ment, Internal Report, Communication Networks Laboratory, Design Department. In 1988, he joined the IBM Zurich Research Department of Computer Science, Swiss Federal Institute of Laboratory at Ruschlikon,È Switzerland, where he was manager of Technology, Lausanne, Switzerland, 1996. Available from the Customer Premises Network Department. In 1994, he formed http:rrlrcwww.epfl.ch. the Laboratoire de Reseaux de Communication at EPFL, which in wx58 http:rrwww.tinac.comr. autumn 1997 became part of ICA. His interests are in the architec- ture and performance of communication systems. Jean-Pierre Hubaux has been an associate professor at EPFL Ž.Swiss Federal Institute of Technology, Lausanne since 1990, where he is now co-director of the Institute for Computer Commu- nications and Applications. His current area of interest is service engineering, and in particular the convergence of telecom and Internet-based services. At the beginning of his activity at EPFL, he defined the curriculum in Communication Systems; this cur- riculum integrates EE and CS courses; it is today the division of EPFL attracting the largest number of students. Prior to this position, he spent 10 years in France with Alcatel, where he was involved in R&D activities, mostly in the area of switching systems architecture and software. He was also in charge of the introduction of artificial intelligence techniques, especially for system troubleshooting.