i !I!!

'0 MMI,IN I ,,r;, 10 1II!j;

ISU RV YS &

U'ORIA 5 __

hil II" Hr I}n i� �1iII"':; i nil 9 F

Or Igl n'li I 1i . ... r.!tQ.'1I.w'Q.!:I �un'.'iI Arlie I !II:!:

TI NA: ITS ACHIEVEMENTS AND ITS FUTURE DIRECTIONS

HENDRIK BERNDT, TINA CONSORTIUM

TAKEO HAMADA, FUJITSU LABS. OF AMERICA

PETER GRAUBMANN, SIEMENS AG

ABSTRACT

The Telecommunications Information Networking Architecture (TINA) has reached a mature state and TINA solutions are now appearing in the market. This article presents a brief sketch

of TINA's past and the overall objectives as they are seen today. It further describes the current technological state of the architecture with its business model, the computing

environment requirements, the session model, the networking resource model, and its impact on the network technology evolution. Eventually, the path TINA

will take into the future is indicated by outlining the TINA Trial project and the workgroup activities; the driving forces during TINA's current phase.

The Telecommunications Information Networking Architecture (TINA) is one of the driving forces in bringing together two industries whose merging has

long been anticipated: TINA is at center stage when the telecommunications and information technology industries meet. This process, based on a vision that still needs much work to make it happen, has seen periods of excitement and disappointment. The reasons for this oscillation vary, yet one thing seems to be certain: the lack of an adequate common technical framework and the absence of a supporting commu­nity. Unfortunately, it has often been the case that a still immature technology was pressed upon software architects, telecommunication engineers, and system implementers who were neither trained in the technology nor were given true community support during the time of application develop­ment. This happened because system architects and develop­ers of generalizable architectures had to face economic realities and, pressed by the competition of the market, did not manage to get sufficient collaboration and support from the community to make their work more sustainable for the industry as a whole.

TINA was initiated in the TINA Workshop in 1990. It started quite informally as a network of telecommunications specialists (in particular, but not exclusively, coming from the area of Intelligent Networks) that wanted to coordinate a series of advanced but insulated research activities in their companies. Then, TINA gained momentum through the cre­ation of the TINA Consortium (TINA-C). At the end of 1992 approximately 40 leading companies, including network oper­ators, telecom vendors, and IT vendors, had joined the con­sortium.

When TINA-C was founded, its goal clearly was to set up a

mature, implementable telecommunications-centered architec­ture together with the specifications of crucial components. To overcome the pitfalls described above, all specifications should be based on common efforts and on the joint agree­ment of a broad majority of involved companies. The TINA-C motto, "A Co-operative Solution for a Competitive World," expresses this spirit. Achieving this goal turned out to be quite a challenge.

By the end of 1997, when its first phase ended, TINA delivered the architecture; it provided specifications for the TINA service architecture, the TINA network resource archi­tecture, and the distributed processing environment (DPE) architecture.

The feasibility of key architectural concepts and relevant component specifications were proven by international trials in 1997 and 1998. They have been demonstrated in many confer­ences and exhibitions, for instance at TELECOM '95 in Geneva. Further business cases for TINA applications have been con­tinuously presented to the public, and most recently new sce­narios have been shown, again in Geneva at TELECOM '99.

What was yet to be achieved was the development of busi­ness-driven TINA applications in the large. As a consequence, the focus within TINA-C shifted from specifying the architec­ture to providing ready-to-implement component specifica­tions and their implementation, aiming at selected business cases. It is expected that this new direction will lead to a glob­al adoption of TINA, creating new business opportunities both for operators and vendors. In response to this challenge, TINA's second phase started in 1998 to accelerate the adop­tion of proven-in-the-field industry specifications, and to facil­itate the market-driven adoption of TINA.

In this tutorial article, we present the status and future

2 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

directions of TINA, together with TINA-C second-phase activities. When describing the architecture, we focus on cur­rent and future technical issues and challenges for TINA. TINA-C's history and organization are outlined very briefly. Readers interested in more detail are referred to [1] or the TINA-C Web site (http://www.tinac.com). For more extensive coverage of the basic concepts of TINA, the reader is directed to a comprehensive book by leading TINA experts [2]. For a more thorough overview of TINA's history, see [3].

TI NA OBJECTIVES

The objectives of TINA are to solve the urgent needs of the telecommunications market in its entire complexity. Yet, they still reflect the particular business roles of the various TINA-C stakeholders. Telecommunication architects perceive TINA as a vision for globally manageable telecommunications networks with a seamless service delivery far beyond the pos­sibilities of Intelligent Networks. Software architects take TINA to be a challenging opportunity to introduce modern computing paradigms such as object orientation and distribut­ed computing into a real-time-sensitive environment with immense complexity.

TINA is dedicated to an approach toward integration and unification. It is designed to provide integrated services for all the information and information exchange patterns being introduced by the industry. These integrated services are designed to provide a unique view to management (i.e., they comprise management capabilities that allow every compo­nent involved to act as manager or to be managed), thus extending the original TMN approach of manager and man­aged objects. TINA also propagates the idea of a uniform infrastructure for network services and network operation provided for by one common abstract platform, the TINA DPE.

To describe it in more detail, TINA's objective is to pro­vide an architectural framework that exhibits the following distinctive features:

• Openness (with the consequence of supporting interfaces having clearly defined semantics).

• Flexibility against regulations (by defining reference points according to market driven business roles).

• Uniform support of any kind of management (i.e., man­agement is simply another service).

• Support of new services with a focus on multiparty and multimedia service features.

• Inherent mobility support. • Scalability. • Reusability of software (to achieve a rapid service intro­

duction). • Separation of service delivery from network transport. • Network technology independence.

Many of these objectives are generic, and they have indeed already been partially stated one way or another in the areas of Intelligent Network (IN), Telecommunication Management Network (TMN), the Internet domain, and oth­ers. What is unique about TINA's efforts is that they com­bine a collection of new computing technologies and apply them coherently to a complete set of architectural principles to shape a future-safe telecommunication and information marketplace.

While TINA offers a vision of the infrastructure of the future, it also allows for gradual evolution and co-existence of the new with the present. TINA offers a spectrum of options, thus allowing the stakeholders to employ smaller or bigger parts of the new architecture in accordance with their business

plans. TINA's flexibility has yet another reason: it was per­ceived that TINA must facilitate the adoption of regulatory changes, and thus, by separation of concerns, it particularly eases the entry of new business entities and allows changing relationships between different parts of the industry.

TINA ARCHITECTURE OVERVIEW

The value and influence of TINA has been and will be mea­sured by the extent to which it provides for industry imple­mentation of TINA-like products, which support certain compliance criteria. Given that TINA-C's objective is to pro­vide a common and coherent software architecture for the provisioning of telecommunication and information services, its achievement consists of a set of specifications for systems and components that make it possible to meet the objectives as described earlier. Reflecting these objectives, the primary application areas for TINA services are envisioned to be:

• Teleconferencing. • Computer supported collaborative work (CSCW). • High quality Internet information services. • Electronic commerce. • Video on demand (VoD). • Virtual home environment/next-generation Universal

Mobile Telecommunications Systems (UMTS). • Virtual private network (VPN) customization and man­

agement in a global environment. Some of these applications, as the reader will recognize,

require close coordination between the communication and information processing services, at a level not yet available by current telecommunication services or by current Internet transport services as offered by Internet service providers. One of the significant aspects of TINA is to literally provide within its architectural framework a set of common features as a substrate for applications, whereas the applications can be "plugged-in" later as separate components embodied by dis­tributed objects. These common features are made available through reference points, a set of APIs that make it possible for stakeholders such as end users and service providers to collaborate more closely and effectively than is possible today, by enabling access to each other's components in a more open "programmable" fashion.

MODELI NG THE TELECOMM UNICATION AND

I N FORMATION SERVICES

Although the motivations and basic objectives of TINA are sound, it would have become an impossible task without a set of proper methodologies. TINA has closely followed the view­point separation, defined by the Reference Model of Open Distributed Processing (RM-ODP) (Fig. 1) [4], applying speci­fication rules for business, information, computational, and engineering viewpoints. Thus, TINA specifies, designs, and develops software components by describing them from differ­ent angles, each one emphasizing a specific concern and disre­garding others, depending on the chosen "point of view."

In short, in a TINA system: • The business viewpoint defines business roles and policies

for the parties involved. • The information viewpoint focuses on information-bearing

entities and the relationships among them. • The computa tional viewpoint models data types and func­

tions in terms of interacting computational objects. The formal description techniques applied to the specifica­

tion process used in TINA are a simplified version of the Guidelines for the Definition of Managed Objects (GDMO),

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 3

called q-GDMO, in combination with the Generic Relation­ship Model (GRM) for information modeling [5], and the TINA Object Definition Language (TINA-ODL).

The TINA information modeling methodology has its his­torical roots in RM-ODP, GDMO [6, 7], GRM [8], and the Object Modeling Technique (OMT) [9], which by now forms an integrated part of the Unified Modeling Language (UML) [10]. TINA selected its own harmonized combination from these methodologies, that is, it took the viewpoint concept from RM-ODP, the language syntax from GDMO and GRM, and the graphical representation and an event sequence description technique from OMT. The power of this informa­tion modeling methodology can best be perceived by the TINA Network Resource Information Model specification [11]. Since UML is now emerging as an industry standard object-oriented modeling language, efforts are ongoing in the TINA community to adopt UML as an essential part of its modeling methodologies. As a consequence, the TINA Com­pliance and Testing workgroup (CAT) has already adopted UML as the basis for its TINA standard compliance and test­ing process.

Stakeholder Stakeholder

Adm i n . Domain Adm i n . Domain

I Business role I .. Business role I .. I RP

I Business role I 41� RP

Stakehol er

411 � RP Adm i n . Domain

Adm i n . Domain I Business role I I Business role I .. Business role I .. I

RP

Framework and requirements

TINA-ODL [12, 13] evolved from the original design in the TINA core team and has now been issued as ITU-T stan­dard Z-130. It can be viewed as a superset of the Object Man­agement Group's Interface Definition Language (OMG-IDL). The extensions provide for specific telecommunication requirements such as multiple interfaces, stream interfaces for continuous information flow, quality of service parameters, and others.

For future work on TINA specifications, TINA-ODL will gain further momentum as a platform-independent compo­nent language, and it is targeted, together with due exten­sions, to become a part of the UML profile for the telecommunications domain.

THE TINA B USI NESS MODEL

TINA was strongly motivated by the need to create a collabo­ration consensus among the different players in the telecom­munication field. These players include operators, equipment vendors, and application developers, who want to share the huge business opportunities emerging from the convergence

Generic relationsh ip

Composition (aggregation)

Type3

Type2

Data modeling and semantics

TINA system

Object instance interaction and animation

CO

Computational interface

CO

Computational object

� CO

CO ef---...J Of------'

� \Stream

interface

Computational viewpoint

• FIGURE 1. ODP viewpoint modeling in TINA

Network nodes

Component distribution and transparencies

kTN

Engineering viewpoint

4 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

Business roles - -- - - -- - - -- -'-

• FIG U R E 2. Business modeling in TINA

of telecommunications and information technologies, but at the same time want to diminish the risks incurred by these new businesses. The architectural guidelines and the TINA reference point specifications are openly provided to every­one, yet the definition and realization of specific component features are left to the individual provider in order to allow for competition. The formal expression of that concept is the TINA business model that identifies the main players (stake­holders) and their business roles. It is based on the projection that current telecommunication systems shall evolve into an open deregulated multi-provider telecommunications and information marketplace.

The TINA business model has recently been adopted by the lTV -T Study Group 11 Q6 as a reference model for the open telecommunication market. Its full description can be found in [14]. It is a generic model that allows for service bro­kerage including concepts of electronic commerce, one-stop shopping at the retailer, and a market opening for a variety of new players such as third-party service providers. The business model also allows for service federation, involving two or more parties subscribed to different retailer domains, and it describes service composition, where new services are created from existing components by enabling retailers to combine and resell services from different third-party service providers. In essence, the TINA business model offers an architectural framework, where two parties in the system, the user and the provider, can trade services. The variety of services involved naturally spans from communication services to application­oriented services such as electronic commerce.

The TINA business model represents a universal paradigm, the user/provider relationship, which is applicable to any situ­ation in which a user makes use of a service offered by a provider. The user/provider relationship can be mapped in a flexible way onto each TINA reference point, which provides the specifications of interactions taking place between them, and the specifications of interfaces being used between differ­ent administrative business domains. The TINA business model is depicted in Fig. 2. The ongoing work on reference point specifications has been prioritized according to their market relevance. Since consumers will request a large variety of services, there will be an immense number of different pro-

Inter-domain reference points: :;� Purpose: Interoperation

Bkr ConS CSLN

LNFed Ret RtR TCon 3Pty

Broker RP Connectivity service RP Cl ient-server layer network RP Layer network federation RP Retailer RP Retai ler-to-retai ler RP Term inal connectivity RP Third-party service RP

(RP: reference point)

Intra-domain reference points: Purpose: Procurement

viders, including the rapidly growing number of Internet ser­vice providers. Therefore, consumers will be able to choose services from a large number of retailers, leading to a rich feature set and prioritization for the Retailer (Ret) reference point. The complete Retailer reference point specification in its current version 1.1. is available on the TINA Web site at www.tinac.com. Even though not all reference points are fully specified at this time, it is expected that market needs will lead to quick implementation based on enhanced TINA speci­fications, which in turn will complete the TINA reference points through fast-track adoption in the TINA Consortium.

As a consequence of the ongoing market deregulation, with service providers rushing into the open marketplace, one of the most significant changes in future business scenarios will be the clear separation between service delivery and net­work provisioning. The de-coupling of service provisioning from the heavy investment needed for network installation ensures a highly competitive market for both a reliable com­munication infrastructure, and flexible, fast-to-market service delivery. For that reason, the Connectivity Service (ConS) ref­erence point and the Terminal Connectivity (TCon) reference point have been specified with high priority.

THE SESSION MODEL

Another TINA output receiving market acceptance is the ses­sion model. A "session" is a generic concept particularly use­ful for telecommunication services, where processes and user/provider interactions involved in the provisioning of a service are associated to a certain period of time, during which quality of service control and accounting management is executed. TINA has identified a three-layered session struc­ture that distinguishes access session, seIVice session, and com­munication session. These three sessions are depicted in Fig. 3.

The access session corresponds to the activities involved in user/provider interactions to choose, establish, and maintain a service, including procedures for subscription, user profile set­tings, authentication, and others, also making it possible to combine and/or conduct several services at the same time.

The service session corresponds to the provisioning and usage of the service itself, handling the overall control and

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 5

c o

';::; CO

,!d 0.. 0..

� LLJ C/) ::J

Service session

Provider service session

User service session

Commun ication session

• FIG U R E 3. Session modeling in TINA

management of the service, and user interaction during run­time. It can further be subdivided into two parts. The user ser­vice session is responsible for managing the involved individual user's activities and the resource attributes (e.g., accounting context, current page, etc.). The provider service session repre­sents service logic and functions needed for joining and invit­ing further participants. It also manages individual service-supporting objects, if required.

The communication session provides the required network resources according to the quality of service (QoS) requests of the service session. For connection-oriented services that require guaranteed QoS, it provides an abstraction of the actual connectivity needed for running the service (trails, sub­network connections, termination points). In the case of an IP-type connectionless network with different QoS, the con­nectivity representation may consist of termination points (IP address and port number) only. This variability of the model is an important point, and it should be emphasized here that the TINA connection management architec-ture is suitable for both connection-oriented and connectionless networks, by incorporating the new concept of a layer network binding [15]. Thus, emerging connectionless QoS frameworks such as DiffServ can be seamlessly integrated into the model. Further activities in this direction are currently pursued in the IP control and management workgroup (IPCM) in TINA phase two.

TINA service component

TINA applications

OPE-----�

OPE implementation

Kernel transport network

Inter· OPE interface (e,g" lOP)

NCCE Hardware ----t-t�

Transport network

c C/) en 22 OJ

"'0 "'0 ii' OJ "" o :::J

.+--+---+---1

er, embodied in the Internet world by portal services, who plans to integrate several pay-per-view channels in order to build an on-line movie theater. To correctly handle the involved business relationships, including charging and accounting, the underlying service model must be able to represent, at any time, who is viewing which chan-nel. In addition, it must provide suffi­cient flexibility and control mechanisms so that the users, the ser-vice provider, and possibly other stakeholders, are able to play their respective business roles in this changing environment.

The issue is inherently complex, and this complexity will presumably show in any satisfactory solution. The

TINA session model can cope with such complexity. It is applicable to a wide range of different business domain rela­tionships, and it provides the needed mechanism to describe them. For example, if two federated administrative domains in a peer-to-peer relationship offer a single, unified view of net­work resources, the session model allows behaving as if two administrative domains reside and coordinate the applications in a single service session.

Although the session is a natural framework for telecommu­nication-oriented services, where certain control and mainte­nance of quality of service is part of the requirements, its benefits become clear only when the concept is systematically applied. A prominent example is the TINA service architecture itself. It provides reusable components for service access and control. By passing a management context between layered ses­sions and between administrative domains, consistent end-to­end subscription and accounting management becomes possible.

o 0 o

TINA network resource component

Although the basic session struc­tures already offer a sufficient framework for applications with advanced communication needs and prospective Internet services based on broadband communica­tion, the service model envisioned for future business applications may demand more flexibility in handling changing relationships between par­ties involved in the running applica­tion. TINA answered this requirement by developing the ser­vice session graph as a way to express the changing structure in the service session. Imagine a retail- • FIGURE 4. Telecommunications information systems.

6 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

..

, ,.-

:

I� � p �

Represented by the logical connection graph

-

I CSM I , :---

'- � I = -

service depends very much on the TN technology,

NETWORK RESOURCE

MODELI NG IN TINA

Terminal Publ ic network Term inal The TINA network modeling prin­ciples are based on the TINA Net­work Resources Information

" " . .....

Subnetwork:

Trail

: Represented by : : the physical : : connection graph: --:... ...: ...

• Link

Tra i l

..... NWTP pool

Model (NRIM) [11], which con­tains specifications of the informa­tion elements, such as trails, links, and network termination point pools (NWTP), that represent the topological and connectivity struc-

Link

Trail

'", ............... :',. Subnetwork

ture in a network. Early drafts of NRIM have been influenced by lTV -T documents such as 0,803 [16], 0,805 [17], and 0,853 [18], The TINA Network Resource Architecture (NRA) [19] defines computational/engineering models

� � - - -. - - - - of the NRIM, whereas the NRIM itself contains information models

• FIG U R E 5 A. Network resource modeling in TINA - information objects. of network resources and elements, Interested readers will find an overview of the NRIM and its

This added flexibility supports a wide range of services with enhanced manageability, such as telecommunication and Inter­net services, allowing for further customer-tailored services.

D PE: THE COMPUTI NG ENVIRONMENT

The overall structure of a TINA system is shown in the lay­ered architecture within Fig. 4. The encapsulated service application and network resource component objects reside on top of a Distributed Processing Environment (DPE) [14]. The DPE hides the complexity of distribution and heterogene­ity from the service developer. Thus, an abstraction from dif­ferent data representations (access transparency), from current positioning of the object (location transparency) or, if desired, a masking of failure detection and recovery actions (failure transparency) is obtained. In the deployment of real systems, however, one must choose between maximum trans­parency support and real-time performance. Features added to the basic DPE communication environment are provided by generically-defined DPE services. For example, DPE ser­vices include trader and notification functions, performance monitoring, transaction services, and others. The work per­formed in TINA was directed toward specifying requirements of DPE services that meet explicit telecommunications needs.

A logical signaling network core, known as the kernel Transport Network (kTN), is designed to transfer information between different DPE nodes, bootstrapping multi-domain DPE connectivity across different administrative domains. Today, there are different implementations of DPE nodes available off the shelf, a typical one being CORBA 2.1. The layer describing the Native Computing and Communication Environment (NCCE) contains operating systems/language­specific functions, communication protocol stacks, and other system-specific functions. The Transport Network (TN) mod­els the underlying network with respect to user plane aspects in the same way that the kTN models a network carrying mostly control and management traffic. The Transport Net­work guarantees the handling of continuous streams of audio and video for multimedia applications. Obviously, quality of

design principles in [20], The major benefit of the TINA network resource model

is its technology-independent view of network resources, This particularly supports the development and management of multimedia applications: only the relevant network char­acteristics, in particular service quality features of streams, are presented to the applications, whereas less relevant char­acteristics, such as the chosen message transfer units or com­pression options, are abstracted out. The TINA NRIM/NRA also allows network resources to be more explicitly visible and controllable through the use of the connection graph, This feature is useful, in particular when complex call con­trol, such as third-party call control and party management, is required,

In the TINA network resource model, control and man­agement of network resources have been handled in a uni­form manner, in contrast to the usual separation of control and management functions in existing networks, This is feasible since both control and management operations are based on a single distributed object-oriented substrate, the DPE, where control and management are treated as two facets or interfaces of the same computational object, rather than two entirely different categories of operations on networks, For management and maintenance of com­plex services involving many network resources, this uni­form approach pays dividends immediately since network control and management are essentially intertwined in these cases,

In terms of its relationship to the business model, the TINA NRIM/NRA illustrates the connectivity provider role; in terms of its relationship to the session model, the scope of the NRA is the communication session, It describes the connectivity of multi-point to multi-point con­nections and handles complex communication sessions based on multimedia service requirements, Figures 5a and 5b give a high-level overview of the information and com­putational objects involved in TINA connection manage­ment.

An abstraction of the connectivity is provided by the con­nection graph, The information model describes the connec-

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 7

tion between the user applications (UAP) as a logical connec­tion graph. Its refinement with respect to the network opera­tor's view is the connectivity description within the network boundaries, provided by the so called physical connection graph. Thereby, the complexity of the connection manage­ment is broken down into a hierarchically layered structure of connection management components, as shown in Fig. 5b:

• The communication session level. • The connection coordinator level. • The layer network level. • The network management layer level. • The element management layer level.

Connection less Networks as TINA Transport Networks -The Transport Network (TN) is a technology-independent abstraction of transport layer networking in the TINA connec­tion management. The TINA connection management was primarily developed to support stream-based, multimedia telecommunication services. As a matter of fact, ATM tech­nology was the primary source of influence in characterizing technical features of the Transport Network. By the end of TINA phase one, the importance of connectionless networks and their modeling needs became apparent, due to the rise of the Internet as the common, universally accessible data net­work. Efforts have been undertaken to respond to this new development [14], and results of these studies were incorpo­rated into the TINA baseline specifications [21]. In TINA's second phase, the IP control and management workgroup (IPCM) has been initiated, which concentrates on control and management issues for IP connectivity service provisioning. The group will focus on the impact of a connectionless Trans­port Network, in particular the Internet, on control and man­agement issues in TINA's NRA.

THE I MPACT OF TINA ON

N ETWORKING TECHNOLOGY EVOLUTION

Originally, a major goal of TINA-C was to overcome the limi­tations of existing networks and service provisioning concepts, particularly those of Intelligent Networks (IN) and Telecom­munications Management Networks (TMN). An extension of this focus was due to the rapid development of the Internet in recent years, which has considerably changed the landscape of networking technologies, but still shows certain deficiencies with regard to service delivery and, particularly, QoS assur­ance. For the migration of those network technologies toward TINA to take place, however, it is not only necessary that the new TINA systems are better, allowing new features and opportunities. In addition, a smooth path from existing sys­tems to new ones must be offered.

It is not difficult to see that TINA inherited sound techni­cal features from both IN and TMN, adding its own concepts to meet future market needs. For example, TINA has much in common with IN, in both its principles and its operational concepts, with regard to call control, service creation, and management. TINA shares with TMN the distributed style of management and the network resource view. Hence, in both contexts, TINA can be seen as an adequate evolution. This is of particular importance for telecommunication operators who are undertaking large investments, but at the same time must protect the investments already made in existing tech­nologies.

Scenarios detailing the migration from current networks to TINA, as well as the interworking of those technologies, have been fairly extensively studied toward the end of phase one of TINA-C. For example, the EURESCOM projects P508 [22], P715 [23], and P847 [24] discussed exhaustively the benefits of

TINA and the migration and inter­operability issues caused by introduc­ing TINA into the telecom carrier business. The overall conclusion of these considerations is that the

Logical connection graph migration toward TINA from IN or TMN is indeed possible and feasible, even if it may not be an easy task. The basic strategy they suggest to follow is to utilize existing compo­nents as long as they can sufficiently substitute for generic TINA compo-

Communication session level

Physical connection graph

Connection coordinator level

Trail

Layer network level

Subnetwork connection

Network management layer level

nents.

- - - - - - - - - - - - - - Subnetwork connection

TINA and IN - An operator may choose to replace an entire system, or to gradually evolve toward TINA, while continuously interworking with existing systems through interwork­ing gateways or adaptation units. A gradual upgrade by introducing small parts of TINA will require adapta­tion functions, i.e., mostly protocol conversions, to connect between the original part of the system and the part that has been "TINA-ized" (i.e., the legacy components enhanced by TIN A -like interfaces). Figure 6 depicts a solution for interworking between IN and TINA by using a CORBA/SS7 gateway to bridge between the INAP and the Inter-Orb protocol (lOP), making it possible to exploit the benefits of the TINA ser-

Element management layer level

• FIGURE 58. Network resource modeling in TINA - computational objects.

8 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

TINA service arch itecture

vice architecture in the shape of "dis­tributed IN components." TINA and TMN - To see TINA as a mere integration of IN and TMN would be too simplistic a view. TINA, by its design, is either reducing or complementing the limitations of IN and TMN in an essential way. Dis-tributed-objects computing with the TINA DPE allows freedom of compo­nent location and utilization of dis-tributed resources, thus taking advantage of the increasing CPU power at the user terminal. This is in contrast to the original IN concept, where the bulk of the processing load is put onto the centrally controlled service control points (SCPs).

On the other hand, by adopting ODP viewpoints and the easy-to-use DPE syntax, plugging off-the-shelf DPE services to support system man­agement as specified by TINA is far easier than it is with the original CMIP-based TMN. In this sense, TINA can be seen as an extended ver-sion of TMN. In fact, TINA has inher-ited and adopted TMN concepts in its network resource view and connection

components ,--------,

lOP

SS7

OPE

x Switch

OPE

- -, ,

Switched transport network

SSP

X

CORBAlSS7 gateway

SCP

U (Legacy)

(Legacy)

I NAP IN appl ication protocol lOP Inter-orb protocol SS7 Signaling system No. 7 SCP Service control point SSP Service switching point

management [11]. As CORBA-based TMN systems can be expected to be dominant in the future, TINA and TMN will share more and more a

• FIGURE 6. InteIWorking of TINA with existing networks.

common design. Figure 7 illustrates the relationship between TINA and

TMN. In short, the complementary strengths of TINA and TMN will enable co-evolution of two networking technologies toward a more integrated service and management paradigm.

TINA and the Internet - The evolution of the Internet has had a significant impact on the development of networking technology, not to mention its social and economic impact in recent years. Although the Internet itself may be regarded as having evolved from the technologies of the 1970s, its unique contribution is to have brought about the first universal data communication protocol, thus providing a universal substrate where communication and information processing technolo­gies can meet. In a sense, the Internet has at least partially fulfilled one of the original goals of TINA (i.e., it has consid­erably reduced the effort necessary for service provisioning). For example, due to the wide availability of cheap Internet­ready PC terminals, much of the transport technologies envi­sioned by TINA, namely the Transport Network (TN) and some portion of the kernel Transport Network (kTN), are now predominantly IP-based, or at least partially dependent on IP-derived protocols.

It has become increasingly clear, however, that Internet technologies, in their current form, have limitations. Despite long and intensive efforts by the Internet Engineering Task Force (IETF), an end-to-end control and management mecha­nism to realize guaranteed QoS is not yet in sight. Although often considered an advantage by the Internet community, the missing separation of control and data traffic has often been the source of reliability problems in actual business scenarios. Increasingly fractured sets of protocols developed by separate working groups tend to enforce duplication of functions rather than encouraging reuse, thus further burdening developers

and products. TINA itself, of course, is by no means a solu­tion for all these problems. As we have explained throughout this section, however, the reader shall notice that TINA pro­vides essential features for addressing the issues stated above, and we are certain that further development of TINA will lead to detailed architectural solutions to overcome the draw­backs of the current Internet framework.

Summarizing this section, Table 1 highlights important common aspects and differences of representative networking technologies in comparison with TINA.

TINA IMPLEMENTATION AND PRACTICES

Many researchers and developers around the globe collaborated to make TINA a reality, and a significant amount of prototyping and validation has been performed toward the end of TINA phase one. In TINA phase two, starting in 1998, serious devel­opment efforts for TINA-based systems intended for real usage started to emerge. Given our space limitations, we can only pre­sent a few representative results. We want to mention, however, that there are many projects focused on TINA and TINA-based systems, whose results are equally important as those in the fol­lowing samples both in technical and practical terms.

TTT: THE TI NA TRIAL PROJECT

The TINA Trial (TTT) was a joint effort of the TINA com­munity to perform trial activities in order to validate the TINA architecture during the 1996-1997 period. The main objectives of these trials were:

• Demonstrating TINA-specific added values. • Showing how to achieve compliance with TINA specifica­

tions.

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 9

PSTN/BISDN I N/Mobility TMN Internet TINA

Interface structuring Signals Messages Managed objects Frames, IP Objects, reference principles protocols points, methods

Support of scalabi l ity Lim ited by Lim ited by I NAP Scalable, d istributed Scalable, d istributed Scalable, d istributed trunk signal ing and MAP or IS 41 mgmt. arch itecture control arch itecture control arch itecture

Separation of service No Yes, physical No No Yes, logical (software) and network

Integrated control No No, management part Partly (only Yes Yes and management is not standard management)

Efficient service- Not yet Yes, qu ick if new No Yes, terminal Yes, first investment creation environment service fits I NAP business may be large, but Rol

by later re-use

Product avai labi l ity Available Ready, major Major investment Avai lable but no Mid-term investment made ongoing network control

Shared development No Partly (custom ization of Yes (for components Yes, (for appl ications Yes can also imply risk prepared parameters) with GDMO standard) and services) third-party components

• Table 1. Common and contrasted aspects of existing architectures in comparison with TINA

• Handling multi-domain, multi-services, and multi-net-work environments.

• Exploiting the synergy with the latest technologies. • Experimenting with maximum flexibility in policies. • Performing field trials with real users.

The Global One Alliance TTT, which included partners from Deutsche Telekom, France Telecom, and Sprint, is one of sever­al trials that have successfully demonstrated the interconnectivi­ty between various providers in a transatlantic environment at the TINA '97 conference. Based on a heterogeneous CORBA 2.0 distributed processing environment consisting of various ORB products from multiple vendors, this TTT demonstrated a combination of the universal access and call completion services showing the ability to integrate existing telephone (POTS) into TINA systems. The overall TINA platform and the supported services have been built by integrating distinct service architec­ture objects, relying on the compliance to the Ret and RtR ref­erence points. Business benefits from applying the TINA-C architecture have been proven mainly in the fields of seamless service provisioning, reusability of software components, extensi­ble service platforms, and user and service mobility.

Another TTT has been carried out by a second group of partner companies, including Digital Japan, Fujitsu, Hitachi, IBM, lona Technologies, NEC, NTT, and OK!. In this trial, TINA service and network resource architecture components have been developed and implemented by a single partner company. These components, compliant with the TINA refer­ence point specifications (such as Ret, TCon, and ConS), suc­cessfully worked together proving that interoperability via the TINA reference points is feasible. They provided a platform for electronic shopping malls, video on demand (VoD) ser­vices and Customer Network Management (CNM) services over IP/ATM networks across multiple domains. This TTT system also demonstrated a possible solution for the integra­tion of existing TMN-based network management systems and DAVIC-compliant VoD systems with TINA components. As the first business target, a networked digital library service is being built on top of this TTT platform.

EUROPEAN ACTS PROJECTS

During TINA's first phase, the specification work in the core team, research work at various institutions and universities, and prototyping at TINA-C member companies went on in parallel. All these efforts influenced each other in their

progress. Overall, a significant amount of research was done during this period, some still continuing into phase two. In particular, research opportunities in Europe were unique, as the European Union supported several important TINA research projects through the ACTS Program, which resulted in research output with high visibility and highly flourishing collaboration among participating members. All of the follow­ing ACTS projects have influenced the progress and solidness of TINA. Some of the ACTS projects, such as VITAL, have provided, besides validation of service architecture, additional specifications to Network Resource Architecture components, which have been incorporated in the latest TINA baseline documents. ReTINA has influenced the alignment of OMG and TINA regarding real-time DPE and minimal kernels, and DOLMEN has extended terminal mobility for TINA. Not all findings were accepted within TINA, but all of them have been acknowledged as valuable contributions.

VITAL (TINA Service Architecture) - The objective of the ACTS project VITAL [25-27] is to demonstrate and validate the development, deployment, management, and use of het­erogeneous service features on an Open Distributed Telecom­munication Architecture (ODTA) which is TINA-based, while integrating existing networking concepts such as TMN, IN, and the Internet. VITAL's ODTA includes building blocks such as an enhanced TINA subscription and accounting man­agement subsystem. The design of VIT AL was validated through an international trial, in which national hosts such as Portugal Telecom, Belgacom, Telefonica 1+ D, and CSELT participated.

DOLMEN (TINA Service Architecture) - The aim objective of the ACTS project DOLMEN [28] is to develop, validate, and promote a service architecture called Open Service Archi­tecture for an integrated fixed and mobile environment (OSAM). The DOLMEN architecture design is TINA-based, with enhancements and supporting features for mobile net­works such as GSM and UMTS radio access. Two trials were performed, one in its first and the other in its second and final year, using mobile networks in the UK and Finland, and an international ATM link between the two countries.

SCREEN (TINA Service Creation) - The ACTS Service Cre­ation Engineering Environment (SCREEN) project [29] tar­gets TINA-based, CORBA-based, multi-vendor service

10 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

Commonal ities: Natural distribution and object orientation in both T INA and TMN ITU-T roles correspond to T INA business model T INA NRIM extends TMN standard TMN-l ike connection management is a subclass of the T INA connectivity service

Mapping: EMLlN ML corresponds to TINA Network Resource Arch itecture SMLlBML corresponds to TINA Service Architecture

Benefits: Avai labi l ity of the advantages of the TINA Arch itecture

, - - ' , ' - - - - - - - - - � , _ _ _

Consumer

- - - - - - - -, - - ,- - - - -

, ' , '

, - - ' , '

- - - -, ' - - - - -, ' , '

, - - ' , , '

Broker

- - - - - - f - -

i. - - - - - - - - - - -

� - - :

Retai ler BMF

ConS

I DL-based connectivity provision (q-interface) and federation (x-interface) reference points

L. _ _ _ _ _ _ _ _ _ _ , ' _ _ _ _ _ , ' , '

LNFed

BMF Business mgmt, function SMF Service mgmt, function NMF Network mgmt, function SMF Element mgmt, function : _ - - - - - - - - - - - : : : :- - - - -

Communication provider EMF

�--------'======='-----�

, - - ' , ' - - - - _ . ,- - - - - - - - - - - - - -, ' , '

• FIGURE 7. TINA incorporates TMN.

creation environments. In this project, selected functions of service creation environments were evaluated by two trials internal to SCREEN, and by two external trials done by the ACTS projects VITAL and DOLMEN.

TOSCA (TINA Service Creation) - The main objective of the ACTS TINA Open Service Creation Architecture (TOSCA) project [30, 31] is to develop an open service creation plat­form applicable both to TINA and IN. The service creation environment took advantage of SDL tools coupled with OMT principles and IDLIODL interfaces. The first target of TOSCA was a TINA-based service creation and target deploy­ment platform. The secondary targets were the IN/TINA interworking issues.

REFORM ( TINA Network Resource Architecture) - The ACTS project REFORM [33] aims at prototyping and testing a TINA-based framework with real operator requirements such as high performance, availability, and fault tolerance. In this project, a TINA-based operation system prototype was built on top of ATM-based IEC networks, and its integration with and migration from TMN components were tested.

ReTINA (TINA DPE) - The ACTS Project ReTINA [33-35] developed a TINA-compliant, innovative, highly flexible and modular DPE architecture. It can be seen as a series of soft­ware frameworks that can be tailored to fit the requirements of different application domains: the core framework, the binding and communications framework, and the resource framework. The core framework constitutes a minimal DPE kernel. ReTINA provided three complementary implementa­tions: the industrial strength Chorus ORB (Chorus Systems, now Sun Microsystems, in C+ +), DIMMA (APM, now Citrix, in C+ +) to experiment with modularity and flexibility in the binding and communications framework, and Jonathan (France Telecom/CNET, in JAVA) which is currently being further developed and extended as part of an open source effort. The project further developed or adapted several DPE services (trading, notification, transaction, concurrency con­trol, persistence, and query services), and it extended and refined a connectivity service on the basis of the TINA-C con-

nection management, in order to support QoS-constrained connections and to integrate it with Internet-based services.

TI NA- BASED COMMERCIAL PRODUCTS

TINA's acceptance in the market is best measured by the appearance of commercial products; both from the operator side and from the vendor side. Although full adoption of TINA in the global telecommunication service market has not occurred yet, there are already a variety of complex commer­cial applications. In the following sections, a few examples of these TINA-based products are presented.

Sprint ION (TINA Service Architecture and DPE) - In the Spring of 1998, Sprint announced the ION (Integrated ON­demand) service [36, 37]. The beginning of the second phase of TINA-C was thus marked with the appearance of a com­mercial product with real deployment efforts. Sprint ION is a TINA-based system, taking advantage of the control and man­agement flexibility offered by the TINA DPE and the TINA network resource modeling. The system enables its users to request service provisioning on-demand, making broadband multi-services available to home and business users alike, while keeping overall maintenance and management costs low. The experience and the results of Sprint ION have proven to be very valuable assets to the TINA community, as Sprint is actively contributing its experience through TINA's Compliance and Testing and the DPE workgroups (CAT, DPE).

Alcatel f-l3S ( TINA Service Architecture and Business Modeling) - Alcatel developed TINA-based middleware, named f-l3S, which stands for Multi-Service, Multi-Network, Multi-Terminal Service Framework) [38]. f-l3S is a middleware platform for integrating heterogeneous networks and services, based on TINA, providing a universal and uniform service platform for various network technologies including IP, ATM, ADSL, VoIP, etc

SA TIN ( TINA Service Architecture and IN Services) -

SATIN is a cooperative project between Deutsche Telekom

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 1 1

and France Telecom. The goal of SATIN is a service platform prototype that integrates existing IN services with TINA ser­vice concepts [39] and allows for interworking of different ser­vice platforms. Based on the previous studies by EURESCOM P50S [22] on migration and interoperability issues between IN and TINA, SATIN has demonstrated that services belonging to different network operators can interoperate based on TINA reference points, and a smooth migration from IN to TINA is indeed possible. From the TINA side of SATIN, the service control point (SCP) of IN is seen as a TINA service box representing a legacy component. From the IN side of SATIN, the TINA service platform and the service compo­nents are seen as extensions and enhancements of the IN SCPo In the middle of the two worlds, SATIN serves as an adaptation unit, which translates between INAP requests of IN services and CORBA requests of TINA services. The SATIN team is a contributing member of the TINA-IN adap­tation unit RFP issued by the TINA IN workgroup (TINA­IN).

Starvision (TINA DPE) - Fault tolerance of operation sys­tems is very important for commercial network operators, PSTN operators, Internet service providers, and cable TV operators alike, because fault tolerance contributes directly to high reliability and high availability of the operation. Although fault transparency is one of the RM-ODP transparencies sup­ported by TINA, the current TINA DPE specification has not yet incorporated it, and fault-tolerant CORBA is still in the making at the OMG. Starvision built a fault-tolerant DPE [40] to fill this need, implementing fault detection and recovery measures in its DPE design.

CONTRI BUTION TO

STANDARDI ZATI ON BODIES AND I N DUSTRY FORA

As large and complex telecommunications and information systems with global coverage, TINA-like systems can only be made possible by the cooperation of many service providers, network operators, and IT vendors in setting and observing international standards. The focus on facilitating TINA-based products distinguishes the second phase of TINA. There is also the clear recognition that, while TINA provides a solid technical basis for the future telecommunication and informa­tion marketplace, there are many TINA activities that overlap with those of other organizations such as international stan­dards bodies and industry fora active in the same technical domain. For the industry to move together toward TINA-like systems, it is henceforth necessary to contribute to, and to work within, related organizations to achieve the common goals.

Object Management Group (OMG) - TINA-C has had and maintains contacts with important industry organizations, both formal and informal, for the reasons stated above. The collab­oration with the Object Management Group (OMG) [41] has proven to be important and productive, particularly with respect to DPE and CORBA-based platforms [42-45], the Telecommunication Domain Task Force, and, more recently, in the area of e-commerce in an open electronic market. Rapid progress in distributed computing technology in the IT industry has made OMG one of the most active and produc­tive industry fora. On the other hand, TINA provides strength in the architectural principles, the business model, and techni­cal requirements specific to service and management of telecommunication networks. By combining their complemen­tary strengths, joint RFPs and a common specification process between the two groups are being explored.

TeleManagement Forum (TMF) - During the past year, the relationship with the TeleManagement Forum (TMF) expanded, until now it is becoming a more formal collabora­tion. TMF is one of the largest telecommunication industry groups, focusing on network and service management issues in the telecom industry. There are several focal points in this collaboration. TMF has identified telecommunication busi­ness processes [46] and a vision of telecommunication busi­ness evolution [47]. TINA has defined its business model [15], which gives the overall framework for telecommunica­tion businesses, the business processes, and the reference points for the interactions between business entities. One of the results of the collaboration is the mapping between the TINA business model and the TMF business process model [4S].

Parlay - Parlay [49] is a consortium consisting of several leading operators and equipment vendors, including British Telecom, Microsoft, Lucent, Nortel, Siemens, and Ericsson, most of them also TINA-C members. Although its scope and objectives differ from those of TINA-C, its activities overlap with TINA, particularly with respect to TINA-IN interworking issues and the service provisioning API at the Ret reference point. The approach taken by Parlay is simi­lar to TINA's approach: both use a distributed object-ori­ented API to make IN services better accessible and customizable for the PC-based end users. Members of the Parlay group regularly attend the TINA-IN workgroup meetings, and have contributed to the TINA-IN adaptation unit RFP. The Parlay group also collaborates with TINA-C in response to the OMG Telecommunication Service Appli­cation: Provisioning and Subscription RFP [50], to which TINA member companies such as Deutsche Telekom, GMD Fokus, NTT, Hitachi, and Alcatel responded together with the Parley group. The contributors are now finalizing their specification [51].

I TU- T and A TM Forum - In the ATM Forum (ATMF), TINA-C contributed its connection management model [11, 19] to the ATMF management view [52, 53]. Within the ITU­T, the TINA object definition language (ODL) [13] became the ITU -T standard Z-130 and the TINA business model has became a part of the SG 11 Q6 recommendation.

THE TINA WAY INTO THE FUTURE

In TINA-C phase two, there was a clear recognition among member companies that TINA provides a sound technical framework, but the work needs to be continued to give use­ful specifications for real TINA applications and to have feedback from TINA realization/deployment efforts. As a result, a new working procedure was adopted, where work­groups recommend specifications based on the responses from member companies on a Request for Proposal (RFP) for a specific target area. This procedure is illustrated in Fig. S.

Each TINA-C technical workgroup has a specific focus with stated goals on grounds of business case scenarios. Mem­ber companies can participate in workgroup activities accord­ing to their interests. The center of the workgroup activities is the RFP (Request for Proposal) process. After a workgroup has identified certain problem areas, based on member com­panies' business needs, a RFP document is issued, requesting proposals for solutions from interested parties inside and out­side the TINA-C community. After a given time frame, usual­ly six to 12 months, depending on the scope of the RFP,

1 2 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

responses are collected, compared, revised, and integrated into a final specification. This final specification is to be voted on and recommended for technology adoption first by the workgroup, then by governing organizations within TINA-C, such as the TINA Architecture Board (TAB) and the Techni­cal Forum (TF). Criteria for evaluation of submissions include availability of prototypes, pre-products, or products as an important measure of practical value of the proposal. Cur­rently, the TINA Consortium has nine workgroups and one special interest group, which are: • TINA and Intelligent Networking Workgroup (TINA-

IN). • Electronic Commerce Workgroup (EC). • Application of TINA Workgroup (APPL). • Service Architecture and Reference Points Workgroup

(SARP). • Service Management Workgroup (SM). • Carrier Class Distributed Processing Environment Work-

group (DPE). • IP Control and Management Workgroup (IPCM). • Compliance and Testing Workgroup (CAT). • Virtual Home Environment Workgroup (VHE). • Security Special Interest Group.

The updated workgroup agendas, meeting reports, and more detailed descriptions of workgroup activities can be found on the TINA-C Web site, http://www.tinac.com. To kindle the reader's interest in becoming a part of TINA-C through participation in one or more activities, we would like to give brief sketches of these workgroups and the SIG.

T I NA AND I N WORKGROUP

The TINA and Intelligent Networking Workgroup (TINA­IN), chaired by France Telecom, analyzes and specifies TINA components and defines the necessary interfaces at the rele­vant reference points, to assure that TINA supports regular IN services, fulfilling interworking and migration require­ments. The workgroup issued as its first RFP, the IN-TINA adaptation unit RFP [54]. TINA member companies, partici­pating in the workgroup, responded to this RFP, which was then further refined by discussions within the workgroup. Contributions from the participating member companies have been integrated and the resulting response has been officially adopted as a TINA standard. It details the IN -to-TINA migration scenario as proposed by, e.g., Eurescom P508 [22], and puts it to practice.

ELECTRONIC COMMERCE WORKGROUP

The Electronic Commerce Workgroup (EC), chaired by KPN (PTT Netherlands), studies and defines components necessary to support electronic commerce in a TINA-compliant open electronic market, and it specifies the necessary interfaces at the involved reference points. The workgroup collaborates closely with the corresponding electronic commerce task force in OMG in order to prepare the foundation for an Open Ser­vice Market (OSM) [55, 56]. The TINA business model [15] provides an important framework for this work in two ways. First, the TINA business model describes the framework for business entities, shows where they can interact with each other, and where they can engage in electronic commerce activities through standardized interfaces defined at respective reference points. Second, the TINA business model gives a blueprint for future evolution of the telecommunication ser­vice marketplace, in which electronic commerce is expected to play a most prominent role.

ApPLICATION OF T I NA WORKGROUP

The Application of TINA Workgroup (APPL), chaired by NTT, identifies and defines TINA components for applications that may demonstrate the essential synergy between telecommunica­tion and information technologies (examples are digital libraries, settlement services, etc.). The objectives of the workgroup are to show that the TINA framework is viable, and that it is ready to provide real and useful services for the future fusion of the two industries beyond current Internet services. Efforts are ongoing to identify and elaborate on new TINA-based services with spe­cific, clearly identifiable requirements. Electronic commerce was recognized as one of the first services for which it seemed worthwhile to concentrate in a separate workgroup.

SERVICE ARCHITECTURE AND

REFERENCE POI NTS WORKGROUP

The Service Architecture and Reference Points Workgroup (SARP), chaired by Alcatel, is responsible for specifying and maintaining the reference points defined by the TINA busi­ness model. Although activities of the workgroup are not nec­essarily directly linked to TINA applications, it has a significant place in the overall workgroup activities, consider­ing the importance of the reference points and the business model within TINA. Based on the work on TINA reference points [57], this workgroup is in close collaboration with the OMG Telecom Domain Task Force, in specifying the service subscription and provisioning interface standards [46]. Responses from participating members are collected, and the group is currently finalizing the specifications by merging con­tributions from the participating member companies [47].

SERVICE MANAGEMENT WORKGROUP

The objective of the Service Management Workgroup (SM), chaired by Fujitsu, is to enable the development of industry­quality products by offering service management solutions for TINA business applications and for advanced Internet-based applications with solid quality/service management support. The current focus of the workgroup is the advanced VPN (A VPN) service RFP [58], aimed at carrier-class support for the quality and service management of VPN services. The RFP process is ongoing; a call for participation has been issued. The TINA Service Management workgroup has also been in charge of coordinating the collaboration with other telecommunication management related industry groups, in particular with the TeleManagement Forum.

CARRIER-CLASS DPE WORKGROUP

The Carrier-Class Distributed Processing Environment Work­group (DPE), chaired by Sprint, defines carrier-class DPE specifications. The major goals of the workgroup's activities are to provide manageability, reliability, and fault-tolerance requirements, needed by carrier-class DPE operation, and interoperability between interworking DPE systems, which are not readily available with commercial CORBA products in the market. Motivated by the ION experience of Sprint, the DPE workgroup is attracting new interest and insights into DPE issues such as telecom-specific requirements for reliability, real-time, and fault tolerance, for which the IT community in the OMG has only partly shown sufficient attention up to now. Feedback from the DPE workgroup is also shedding new light on topics such as the ORB pluggable protocol mecha­nisms. Joint efforts and collaboration with related OMG workgroups are also expected.

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 1 3

TINA

'd ) Arch itectu re

o D L-I _-------,> Business model

Session model

OPE requirements

Network resource model

o D ,-----I _-----,> • FIGURE 8. The TINA way in to the future.

I P CONTROL AND MANAGEMENT WORKGROUP

The IP Control and Management Workgroup (IPCM), chaired by Telia, is responsible for formulating operator-driven requirements on IP network control and management from a business-oriented perspective. When required, the TINA net­work resource architecture and the related reference points will be updated. The workgroup also plans to influence con­cerned IP standards bodies by carrying out the results from the workgroup activities. The first RFP from this workgroup, titled "A Framework for Connectivity Service Delivery Pro­cess" [59], has recently been approved by the TINA TAB. It focuses on IP-based connectivity service provisioning issues, and will result in a TINA-based IP network control and man­agement framework. The RFP also addresses the problem by incorporating and taking advantage of specifications provided by important industry groups such as the IETF Policy Frame­work WG and the Distributed Management Task Force (DMTF).

COMPLIANCE AND TESTING WORKGROUP

The Compliance and Testing Workgroup (CAT), chaired by Sprint, defines compliance and testing suites so that TINA products satisfying the compliance and conformance tests can be considered proven to work together and to interoperate. The activities of the workgroup are important in the sense that the CAT test suites in industrial reality will define "what TINA is." The workgroup will work closely with the TINA Compliance and Testing Center, to be set up by GMD Fokus, Berlin.

The workgroup has released its first RFP, titled "TINA Conformance Testing Framework" [60]. This RFP is based on previously defined TINA specification methods such as ODL, on the OSI conformance testing methodology and framework from the ITU-T, and on UML-based compliance measure­ment and testing techniques developed by GMD Fokus. One of the most serious problems in the area of telecommunica­tion services is that for the respective software development processes, there are almost no established compliance and testing procedures in place with respect to given service speci­fications. A common resentment in this field is that it is

Workgroups

o D L-I _-------,> I N-TINA Interworking

Appl ication of TINA

Electronic Commerce

Service Arch. and Ref. Pts.

Service Management

Carrier-Class OPE

IP Control and Mgmt.

Compliance and Testing

Virtual Home Environ.

Security SIG

o D ,-----I _-----,>

Integrated solutions

Any service

Any time

Any place

� Integrated solutions

extremely hard to distinguish high-quality from low-quality implementations, which often results in complaints about the quality of the standardization process. By establishing its reli­able compliance and testing measures according to the high quality standards of TINA, CAT has already taken a signifi­cant step to overcome this unproductive attitude. The work­group is now also becoming the center of the activities concentrating on the evolution of the TINA specification methodology. CAT has started to define new concepts and terms for compliance and testing. One of the most important new concepts is the facet, a set of interfaces related to a given reference point. Each reference point can be decomposed into a collection of self-consistent facets, whose interfaces jointly perform a meaningful subset of activities among the reference point interactions. The facets help significantly to break down the complexity of a reference point and its associated behavior description, resulting in a more manageable compliance and testing process.

VIRTUAL HOME ENVIRONMENT WORKGROUP

The Virtual Home Environment Workgroup (VHE), chaired by Alcatel, studies and defines a service architecture for third­generation mobile systems, based on TINA principles and results. In particular, the TINA business model and its service architecture will be used as the main input for the specifica­tion of a third-generation roaming model, and for the imple­mentation of the VHE system. The workgroup, being in discussion with the ETSI UMTS WG and the corresponding OMG workgroup, is working toward a RFP for a TINA VHE specification.

SECURITY SIG

Security is of great concern in TINA, in which many stake­holders and players interact with each other at different layers with different degrees of mutual trust. As an example, consid­er two business partners being engaged in electronic com­merce transactions, as may occur between end users and service providers, or two connectivity providers having feder­ated in a peer-to-peer connection management. They all have

1 4 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1

a vital interest to protect their own assets and to identify their partners correctly. So, even if the business model with its ref­erence points and roles dictates the basic framework and characterization of such TINA business transactions as men­tioned above, an underlying security mechanism must support the security requirements for them all.

The Security SIG, chaired by the Swiss Federal Institute of Technology, Lausanne, is in charge of developing the overall security concepts of TINA, from the application layer to the DPE layer. Security is an important feature of the service environment for each operator to distinguish itself in competi­tion with other operators. Critical information and network resources must be protected from malicious attacks and inad­vertent mistakes. Separation of security interests must be properly done, followed by protection in the domain. The activity of the Security SIG focuses mostly on security issues at the architecture level, since most engineering mechanisms (e.g., key management and secure ORBs) can already be found in relevant IETF and OMG specifications.

CONCLUSIONS

At the outset, TINA was a grand vision. After eight years of continuous work by numerous researchers and engineers around the globe, we see the vision come to life through real, business-oriented systems that are emerging. Knowing the consensus building process that involved all member compa­nies, one of the most convincing facts about TINA is that its original goals and basic principles remain mostly unchanged. That holds true despite all the tumultuous and often intense changes in networking technology and the surrounding phe­nomena - one of which has been the fast growing amount of products related to the Internet. All those changes have been embraced by, and made applicable to, the TINA architecture. We, as active members in the TINA community, see this fact as proof of the soundness of the technological and design principles on which TINA is based. The first appearance of TINA products in 1998 showed that the market has acknowl­edged TINA solutions. Those products are actually creating revenue by now.

As we indicated throughout the previous section, work­groups and their activities are one of TINA's responses to the changing world. Their goals are carefully set, and are aligned with the business needs of TINA member. The steady progress made by TINA will continue, accumulating knowledge and hands-on experience of engineers and developers running TINA architecture implementation on a global scale, thus embodying the spirit of TINA, a cooperative solution for a competitive world.

ACKNOWLEDGMENT

The authors want to express their heartfelt thanks to unknown reviewers of this article, who provided helpful comments and key references for important TINA works. The authors also thank Dr. Peter Czezowski and Dr. David Blight of Fujitsu Labs. of America for their helpful comments.

REFERENCES

TINA-C documents are available to the public at the Web site http://www.tinac.com. [1 ] Y . I n o u e , D . G u h a , and H . Berndt. "The T I N A Consorti u m , "

IEEE Commun. Mag., Sept. 1 998, pp. 1 30-36. [2] Y . I noue, M. Lapierre, and C. Mossotto (Eds.) , The TINA Book,

Prentice· Hal l Europe, 1 999.

[ 3 ] F . D u puy, G . N i lsson, and Y. Inoue, "The T I N A Consort i u m : Towards Networking Teleco m m u n ications I nformation Ser· vices, " Proc. 155'95, Apr. 1 995, pp. 207-1 1 .

[4] ISOII EC ITU·T, ISOII EC HC 1 0746 1 ·4 I ITU·T Standard X. 900, I nformation Technology · Open Distributed Process ing · Refer· ence Model.

[S] T I NA·C, I nformation M o d e l i n g Concepts, Version 2 . 0 , Apr i l 1 995.

[6] ITU·T, Recommendation M .301 0, Principles for a Telecommuni· cations Management Network, 1 992.

[7] ITU·T, Recommendation M . 31 00, Generic Network Information Model, 1 992.

[8] ISOIIEC, ISOII EC 1 01 6S·7, Information Technology · Open Sys· tems Interconnection · Structure of Management I nformation: General Relationship Model, 1 996.

[ 9 ] J . Rumbaugh e t al. , Object- Oriented Modeling and Design, Prentice· Hal l , NJ, 1 991 .

[1 0] G. Booch, J. Rumbaugh, and I . Jacobson, The Unified Mod­eling Language User Guide, Addison- Wesley, 3rd Ed i t i o n , 1 999.

[1 1 ] T I NA·C, Network Resource I nformation Model Specification, Version 2.2, Nov. 1 997.

[1 2] TI NA·C, Computational Model ing Concepts, Version 3 .2 , May 1 996.

[1 3] T I NA·C, TINA Object Defin it ion Language M a n u a l , Version 2.3, Ju ly 1 996.

[1 4] H . C . K im e t al. , Managing T I N A Streams that use I n ternet Transport," Proc. TINA '97, Santiago, Chi le, Nov. 1 997.

[1 S] TINA·C, Service Architecture, Version S .O, June 1 997. [1 6] ITU ·T, Recommendation G . 803, Arch itectures of Transport

Networks Based on the Synchronous Dig ita l H ierarchy (SO H ) , J u n e 1 992.

[1 7 ] ITU ·T, Recommendation G . 80S, Arch itectures of Transport Networks. June 1 995.

[1 8] ITU· T, Recommendation G . 8S3·01 , Common Elements of the I nformation Viewpo i n t for the Management of a Transport Network, June 1 996.

[1 9 ] T I NA·C, Network Resource Arc h i tecture, Version 3 . 0 , Feb. 1 997.

[20] N . Natarajan, "T INA Network Resource Information Mod e l , " Journal of Ne twork a n d Systems Management, pp 2 8 3 · 3 1 1 , vol . 6, no. 3 , 1 998.

[21 ] TI NA·C, Network Component Specification, Draft Version 2.2, Dec. 1 997.

[22] Eurescom project PS08, Evolution, Migration Paths and Inter· working to T I NA, Web site: http ://www.eurescom . de/P u b l ic/ Pub I ications/Projectresu Its/PSOO·series/SOOS. HTM

[23] Eurescom project P71 S, The I ntra Domain Interfaces with in the TINA User Domain, Web site: http://www.eurescom .de/Pub· I ic/Pu b I ications/Pro jectresu Its/P7 OO·series/7 OOs. htm

[24] Eurescom project P847, What is T INA and is it useful for Tel· Cos?, Web site: http://www.eurescom . de/P u b l ic/Publ ications/ Projectresults/P800·series/800s.htm

[2S] ACTS project AC003 VITAL Validation of Integrated Telecom· m u n i c a t i o n s Arch itectures for t h e L o n g T e r m , Web s i te : http://www.mari .co.uk/vital/

[26] J. Pavon et al., "The VITAL Network Resource Architectu re, " Proc. TINA '98, Santiago, Chi le, Nov. 1 997, pp. 1 30-38.

[ 2 7 ] T. Mota et al., "TINA as a Virtual Market P lace for Telecom· mun ication and I nformation Services: The VITAL Exper iment, " Proc. TINA '99, pp. 96·1 06, Turtle Bay, Hawai i , Apr. 1 999.

[28] ACTS project AC036 DOLMEN Service Mach ine Development for an Open Long·term M o b i le and F i xed Network Environ· ment. Web s ite : http ://www. i n fowi n . o rg/ACTS/RUSITR I ALS/ ac036.htm

[29] ACTS project SCREEN Service Creation Eng ineering Environ· ment, Web site: http://www . i n fowin.org/ACTS/RUS/PROJECTS/ SCREENI

[30] ACTS project AC237 TOSCA Tina Open Service Creation Arch i· tectu re, Web site: http://www. i n fow i n . org . lACTS/RUS/PRO· JECTS/ac237. htm

[ 3 1 ] K. K i m b l e r , F. L o d g e , a n d B. Str u l o , " F r a m ew o r k · a n d Parad i g m · based Process for T I N A Service Creatio n m , " Proc. TINA '99, pp. 1 97·204, Turtle Bay, Hawai i , Apr i l 1 999.

IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1 1 5

[32] ACTS project AC208 REFORM Resource F a i l u re and Restora­t i o n M a n a g e m e n t in AT M - b a s e d I B C N , Web s i t e : http://www.algo.com.gr/actslreform/

[33] ACTS project AC048 ReTINA I ndustrial-Qual ity, TI NA-Compl i ­ant , Rea l-Time D istr ibuted Process ing Environment. Web site: http://www.infowin.org/ACTS/RUS/TRIALS/ac048.htm

[34] J. B . Stefa n i e t al., "The ReT I NA OPE Kernel : A F lexible Rea l ­t ime ORB Framework," Proc. IS&N '98, Antwerp, Belgium, May 1 998.

[35] M. Banfield et al., "Providing Scaleable QoS-based Connectivi­ty Services," Proc. TINA '99, Turtle Bay, Hawai i , Apr. 1 999.

[36] Sprint ION, Web site: http://www.sprint.com/ion [37] S. Bannerman, B . Stockdel l , and M. Stutz, "Network Topology

Configuration Management Experience Report," Proc. TINA '99, Turtle Bay, Hawai i , Apr. 1 999, pp. 1 37-39.

[38] F. Steegmans, N . Mercouroff, and B . Ceccaldi , " M u 3S: A M id­d leware P latform for Teleco m m u n ications I nformation Net­work i n g , " Proc. TINA '99, Turtle Bay, Hawa i i , Apr. 1 9 99, p p . 1 31 -33.

[39] C . Cape l l m a n n and J . - M . Pageot, "A TINA Service P latform integrated with c u rrent I n te l l igent Network systems, " Proc. TINA '99, Turtle Bay, Hawai i , Apr. 1 999, pp. 295-301 .

[40] S. Stanley, " B u i ld ing a Fault Tolerant D istributed Processing Environ ment, " Proc. TINA '99, Turtle Bay, Hawa i i , Apri l 1 999, pp. 1 34-36.

[41 ] OMG, Web site: http://www.omg.org [42] T . Mowbray and R . Zahavi, The Essential CORBA : Systems

Integration Using Distributed Objects, Wiley, 1 995. [43] OMG, CORBA: Architecture and Specification, 1 996. [44] OMG, CORBAservices, 1 996. [45] OMG, CORBAfaci l ities, 1 996. [46] TMF, Telecom Operations Map, Vers ion 1 . 1 , T M F G B901 ,

1 999. [47] TMF, Technology Integration Map, TMF GB909, 1 999. [48] ACTS project AC335 FlowThru Co-operative Secure Manage­

ment of Mu lti Technology and Admin istrative Domain Network and Service Management Systems, Web site: http://www.cs.ucl . ac .uklresearch/flowthrul

[49] Parlay Consortium, Web site: http://www. parlay.org [50] OMG, Telecommun ications Service App l ication: Provision ing

and Subscription, RFP, 1 999. [51 ] O M G , Telecom m u n ication Service Access and Subscr iption .

Joint Revised Submission, Draft, 1 999. [52] ATM Forum, CMIP Specification for the M 4 I nterface (Net­

work Element View), Version 1 .0, af-nm-0027 -001 , Sept. 1 995. [53] ATM Forum, M4 Network View CMIP M I B Specification, Ver­

sion 1 .0, af-nm-0083-000, January 1 99 7 . [54] TI NA-C, I N Access t o T I N A Services a n d Connection Manage­

ment, T INA RFP, Oct. 1 998. [55] TI NA-C, Response to OMG RF I " Open Service Marketp lace , "

June 1 999. [56] OMG: Open Service Marketplace, RFI . 1 999. [57] TI NA-C, Retailer (Ret) Reference Point, Version 1 .0, Jan . 1 998. [58] TI NA-C, Advanced VPN Service, T INA RFP SM-1 , Feb. 1 999. [59] T I NA-C, A Framework for Connectivity Service Del ivery Pro-

cess; C l ient/Server and Federations, T INA RFP, Oct. 1 999. [60] TI NA-C, TINA Conformance Testing Framework. T INA RFP, Ju ly

1 999.

ADDITIONAL READING

[1 ] T I NA-C, Engineer ing Mod e l i n g Concepts ( O P E Arch i tectu re) , Version 2 .0, Dec. 1 994.

[2] P . Hel lemans et al., " Development and Deployment of a Het­erogeneous Set of Services Challenging a TI NA-based Telecom­mun ication Arch itecture, " Proc. IS&N '98 Conference, Antwerp, Belgium, Springer, May 1 998, pp. 205-1 8.

[3] G . Pavlou and D. Griffin, "Realising TMN- like Management Ser­vices in T I N A, " Journal of Network and System Management. Special Issue on TINA. vol . 5, no. 4, P lenum P u b l ishing, 1 99 7 , p p . 437-57.

[4] S . Palazzo e t al. , " I ntegration of Mob i l ity Functions into an Open Service Arch itectu re: the D O L M E N App roac h , " Proc. IS&N'97 Conf., Cernobbio, Italy, Springer, May 1 997, pp. 391 -402.

[5] F . Lucid i , H . Idzenga, and S. Batistatos, " Development of TI NA­l ike Systems: the DOLMEN Methodology," Proc. IS&N '98 Conf., Antwerp, Belgium, Springer, May 1 998, pp. 379-92.

[6] S . Efremidis et al., "TI NA-oriented Service Engineering Support to Service Composition and Federation , " Proc. IS&N'98 Conf. , Antwerp, Belgium, Springer, May 1 998, pp. 409-22.

[7] F . Lodge, K. Kimbler, and M. Hubert, "Alignment of the TOSCA and SCREEN Approaches to Service Creatio n , " Proc. IS&N '99 Conf. , Barcelona, Spain, Springer, Apr. 1 999, pp. 277-90.

[8] D. Ranc e t al., "A Staged Approach for T M N to T I N A M igra­tio n , " Proc. TINA '97 Conf. Global Convergence of Telecommu­nications and Distributed Object Computing, I E E E Computer Society, ISBN 0-81 86-8335-X, 1 997, pp. 221 -28.

[9] P . Georgatsos et a l . , "Technology I nteroperation in ATM Net­works: the R E F O R M System, " IEEE Commun. , vo l . 3 7 , n o . 5, IEEE , 1 999, pp. 1 1 2-1 8.

BIOGRAPHIES

HEN DRIK BERNDT, P h . D . , (hberndt@tinac.com) has been involved for many years in the telecom m u n ications i n d ustry in a variety of engineering and managerial roles, including B- ISDN pi lot projects on ATM trials and d istributed process ing technology. He was the Deutsche Telekom AG representative to the TI NA-C core team , o n e o f the contributing authors a n d ed itors o f the TI NA-C Service Architecture and the l iaison for the information and telecommuni­cations i n d u stry sta n d ard i za t i o n bod i e s . After h is core team assignment he was a p p o inted Execut ive D i rector of Advanced Technology for Global One in Reston Virg i n ia , the joint venture between Deutsche Telekom, France Telecom and Sprint. Berndt is now Chief Technology Officer of the T INA Consortium.

TAKEO HAMADA (thamada@fla .fuj itsu .com) g raduated from the Un iversity of Tokyo with BE and M E degrees in Electrical Engineer­ing in 1 984 and 1 986, respectively. He received h is P h . D . in Com­puter Science from U CS D in 1 9 92 for research in p hysical VLSI design. He has been with Fuj itsu since 1 986. From 1 995 unti l the end of 1 99 7 , he was with the T I NA-C core-team at Red Bank, NJ, where he was engaged in research and development activities on the TINA service and resource management arch itecture. Takeo H a m a d a has been with F uj itsu Labo rato r ies of America s i n c e 1 998. H is current research interests include network management and service management issues in IP networks, and pol icy-based networking. He currently serves as T I NA-C service management WG leader.

PETER GRAUBMANN (peter .graubmann@mchp. siemens.de ) is with the corporate technology d ivision of S iemens AG in M u n i c h . He has been invo lved in many research projects covering software engineering methods, formal description techniques, component­or iented development and p latform techno logies. Graubmann was the TI NA-C core team representative of Siemens AG and one of the authors of the TINA OPE-Arch itecture. Recently he worked on the TINA-related European ACTS project ReTINA (Real-Time Dis­tributed Process ing Environ ment) with a focus on qual ity of ser­vice issues.

1 6 IEEE Communications Surveys & Tutorials· http://www.comsoc.org/pubs/surveys • First Quarter 2000, vol. 3 no. 1