Engineering of a broadband connectivity service: the TINA approach
N. Charton, Y. Hervé, N. Mercouroff · 1997
The Telecommunications Information Networking Architecture Consortium, TINA-C, has defined a business model identifying domains for the future telecom industry. One of these domains is the connectivity provider domain, in which stakeholders will support the connectivity requirements of the services within the retailer domain.The network provider offers the connectivity service to the retailer, that is, through the network to the service, via an interface. The interface supports the specifications of a reference point called the Connectivity Service Reference Point, ConS-RP. The ConS-RP allows for the request of connectivity in the form of a connection graph, independently of the implemented underlying infrastructure (ATM, PSTN, IP, etc.).The ReTINA ACTS project aims at developing an industrial-quality distributed processing environment (DPE) for telecommunication applications. The ReTINA DPE thus offers a number of services targeted for this type of telecommunication application. Whereas some of these services offer extensions to traditional CORBA services, such as trading and notification services, others support specific requirements from TINA applications, connectivity requirements in particular.In 1996, a TINA connectivity service implementation was provided for the ReTINA DPE, based on connection management applied to ATM networks. The ReTINA activities include several trials (BVPN service, information service) experimenting the ReTINA DPE implementation, in particular its DPE connectivity service. Feedback from this experimentation allows preliminary observations to be drawn on the service requirements. In particular, it has been shown that performance is a key component for a usage not limited to the sole support of network planning and configuration.Several solutions for exhibiting sufficient performance of the connectivity service are envisioned. Among these solutions, careful engineering of distributing the connectivity service over CORBA is a key issue. One of the engineering angles covers the definition of the API through which telecommunication services request connectivity. The API takes the form of IDL specifications, and needs to follow the TINA specifications for the ConS-RP. Building a connectivity graph potentially demands several interactions between telecommunication services and a connectivity service. To reduce the number of interactions, which may be related to operation invocations across international networks, it is proposed to factor repetitive invocations into a single, multi-parameter operation invocation.Regarding the implementation of the connection management itself, it is proposed to tune its engineering to allow for parallelism and concurrency. With parallelism, simultaneous routing can be established in subnetworks belonging to a same network. Concurrency allows for the treatment of simultaneous requests to the connectivity service. While the former decreases the overall response time in connectivity establishment, the latter minimizes the blocking of requests to the connectivity service.A final aspect of connection management engineering is related to the general deployment of the service over the network. Implementing connection management implies inherent distribution of intelligence. One part of this intelligence is dedicated to the support of connectivity provision to telecommunication services through the ConS-RP interface. Cautious engineering practices advise putting this intelligence as close as possible to the telecommunication service components requesting the connectivity. Other parts of this intelligence are dedicated to the control and management of resources belonging to the network, such as subnetworks and network elements. Once again, a good engineering practice entails locating these parts as close as possible to the resources of concern. This implies contradicting requirements on the implementation which should be handled with care.The article concludes with the need to support the approaches presented by current trials to find an efficient balance between intelligence distribution over the network and overall performance.