Connection Management Architecture

Network connections in TINA are established with management methods, as is indicated in Figure 5.5, and not with signalling. As a result of this there is no difference in the connection setup procedure on the source or sink side of a flow. Connection management in TINA has to

Figure 5.5. Overview of the TINA service and connection management architecture.

Consumer

deal with administrational and technological boundaries. It must support the establishment of end-to-end connections that span the domains of multiple connectivity providers and that cross multiple technological boundaries. A set of contiguous subnetworks that is based on the same networking technology is called a layer network. In general, the boundaries of layer networks and administrational domains do not coincide. Connection establishment across layer networks is controlled by Layer Network Coordinators (LNC). If a layer network crosses administra-tional domains, LNC’s of all involved domains have to cooperate in setting up a connection, as is indicated in Figure 5.5. The actual establishment of connections is done by Connection Per-formers (CP). A Network Management Layer CP (NML-CP) is responsible for the establish-ment of a connection across the part of the layer network that belongs to its administrational domain. To this purpose, an NML-CP orchestrates multiple Element Management Layer CP’s (EML-CP). EML-CP’s are responsible for the management of single network elements, like for instance switches.

An SSM that wants to establish a connection between the stream interfaces of a set of UAP’s creates a CSM via a CSM factory and asks it to establish the respective logical connec-tion graph. Connecconnec-tion graphs can be point-to-point or point-to-multipoint and are unidirec-tional. The CSM informs the Terminal CSM (TCSM) within every concerned terminal about the imminent connection setup. The TCSM receives a token that allows it to match incoming connection setup requests with stream interfaces. The CSM then creates a Connection Coordi-nator (CC) which establishes the end-to-end connection in cooperation with one or more LNC’s. It has to be noted that there is one CC for every active connection, or connectivity ses-sion, but only one CSM per service session.

Figure 5.5 only shows the most important connection management objects. The TINA con-nection management architecture defines significantly more objects, and is much more com-plex than it appears here. The setup of a simple unidirectional point-to-point connection requires a multitude of operation invocations, of which a significant part has to be conveyed over the network. It can therefore be expected that the setup of a multipoint-to-multipoint con-nection takes a couple of seconds to complete. Most of the complexity of the TINA concon-nection management architecture stems from the fact that it is tailored to switched networks. The con-nection management specification states that the integration of concon-nectionless networks, and here namely the Internet, is an open issue.

5.4.5 Assessment

Table 5.3 shows the overall evaluation of TINA. The ultimate goal of TINA is to provide a business environment for the provision of advanced telecommunications services. It conse-quently defines a business model and an elaborate service architecture that allows stakeholders with different business roles to interact on a computational level. More than half of the mem-bers of the TINA consortium are telecommunications operators for which the sale of connec-tivity is a core business. It is therefore clear that their requirements will have a significant impact on the TINA architecture in general, and most importantly on the connection manage-ment architecture. The TINA connection managemanage-ment architecture cannot build on a network layer that hides the heterogeneity of network hardware and protocols, simply because such a network layer does not exist in the realm of telecommunications. The connection management architecture must therefore work out details all the way down to the network elements.

The TINA architecture is a framework for the provision of MMC services in the sense that it defines a service architecture and that it allows services to establish flow connections between

the stream interfaces of computational objects. It does not provide explicit support for the development of services, and most notably it does not provide any support for the structuring of the service session beyond SSM and USM. The SSM appears as a monolithic application with which the developer of a service is let alone. Architecture support for service federation will be a big step towards application reuse, but this is not sufficient. What is needed are stan-dard service building blocks that help assembling a service without being exposed to TINA details. The only building block defined so far that points in this direction is the CSM.

The TINA architecture does not define any multimedia abstractions beyond the stream and flow abstractions of RM-ODP. It does not address synchronization and presentation, which suggests that a multimedia middleware like IMA-MSS would need to be layered on top of TINA in order to provide an acceptable programming environment.

TINA

Requirement Fulfilled Remark

Open ❄❄❄ Inter-domain and intra-domain reference points in OMG-IDL

Extensible ❄❄ RM-ODP object model, but no explicit provisions for extension Programmable ❄ would need to be augmented with toolkits

Scalable ❄❄❄ no inherent scalability limitations

Deployable ❄ requires modification to the network infrastructure

Simple no complex connection management architecture

Session Management ❄❄❄ refined session concept

Connection Management ❄❄ CSM offers unicast and multicast connection establishment Multimedia Data Processing ❄❄ RM-ODP object model, but no special multimedia abstractions Multipoint Control Comm. ❄❄ point-to-point control communication with CORBA

Resource Management ❄❄ the notion of QoS is omnipresent

Synchronization no mentioned in the specifications, but not addressed

Mobile Code no for further study

Presentation Environment - outside the scope of the architecture Federation of Applications no foreseen, but not yet provided

Security no no solutions for security provided

Mobility ❄❄❄ addresses user, session and terminal mobility Directory Service ❄❄❄ information services via the broker business role Platform Management ❄❄❄ platform consists of various management architectures Accounting ❄❄❄ defines an accounting management architecture Standard DPE ❄❄❄ defines a standard DPE based on RM-ODP and CORBA

Table 5.3. Evaluation of TINA.