Part A of the report on the principles and architecture of the GII is drawing a number of recommendations from the material that is presented in part B. The first two recommendations address the principles which the standards activities in support of the evolution of the GII in Europe should adhere to. The second group of recommendations is providesing architectural guidance on the evolution of the GII. It provides succinct statements on the architectural direction to be followed by standardization activities to contribute to the harmonious development of the GII. The final recommendation is commenting on the value that EPIC might add with respect to GII standardization activities that are already being undertaken worldwide.
Recommendation 1: Changing Commercial FrameworkThe enterprise model, which in itself is already an abstraction of the business environment, illustrates the complexity and multiplicity of the business relations in the GII. Neither the usage- based service paradigm of the telecommunications industry, nor the flat rate paradigm of today’s Internet are sufficient to cover the multitude of commercial relationships that need to be supported by the GII.
Project 4.1 recommends that GII standardization activities take account of the evolving and changing commercial framework of the GII and built in the necessary features in GII service and application components to support the commercial requirements that apply to interfaces across organizational boundaries.
Recommendation 2: Service Approach anFud nctional approach Standards activities in support of the GII should take into account both service aspects and functional aspects and they should be treated together and not serially or as separate activities. Service aspects should ensure that the services of the GII are:
Functional aspects of the GII should ensure that:
In the past the telecommunications industry has tended to be service- focussed and this has resulted in service- specific networks while the IT industry, and in particular Internet applications, has tended to be function- focussed, which has resulted in an environment where it is difficult to construct commercial services.
Project 4.1 recommends the use of, the four models described in Part B of this report as a framework for standards development in the GII in order to ensure that both the advantages of the service approach and the advantages of the function approach, can be achieved.
Recommendation 3: Intelligent Terminals
While the telephone will continue to be a very important terminal for voice communication and some voice- based services, the great majority of service will require and use intelligent terminals, supporting applications such as e-mail and WWW. Standards activity for the GII, and particularly IN activity, should be oriented towards intelligent terminals. This implies:
Project 4.1 recommends that IN activity should be clearly divided between IN services for enhancing the voice telephony service, and intelligence services for the GII. The latter should be based on an architecture which assumes intelligent terminals and should not be based, on "triggers" in the local exchange.
Recommendation 4: Distribution ProtocolsThere are currently several candidates for a framework and set of standards with which GII applications can be developed. Three are of particular importance:
These three have many common and compatible features, even if somewhat different approaches, and are all likely to find extensive use in the GII.
While proprietary and standardized distribution protocols in support of IN and mobile is appropriate for voice telephony applications, they are not appropriate to the GII or any network services in support of GII. In addition, OSI will continue to be important in network management;, however, it too is highly unlikely to find extensive use in the GII.
These three activities are all progressing within their own bodies; CORBA within the OMG, WWW/Java/IIOP within the W3C and the IETF, and ActiveX/DCOM within the AcxtiveX Consortium. There is probably little that EPIC can directly add to these activities.
Project 4.1 recommends that current IN or mobile architecture should not be evolved for the GII and that OSI activity equally should not be considered as a likely contender for supporting GII applications and services.
In addition, Project 4.1 recommends that EPIC tracks the activities of CORBA, WWW/Java/IIOP, and ActiveX/DCOM and possibly look to providing a forum for European delegates to these activities to co-ordinate European- specific views. Such a forum should be clearly in support of these activities and not in addition to these activities.
This recommendation covers the current scope of projects 2.7, 2.8, 2.9, and 2.11.
Recommendation 5: Open
BPIs in Terminal EquipmentsThe advent of intelligent terminals substantially alters the view of open interfaces to users equipment. An intelligent terminal requires only a simple telecommunications interface and a basic programming interface in order to function as part of the GII. Application protocols, and even most middleware protocols do not need to be an inherent part of the specification of the users terminal.
All middleware components and applications components can be loaded onto the users terminal and these components can then support the middleware and application protocols. In this way updates and additions to middleware and application protocols can be loaded on the users terminal without the need for any physical change to the users terminal. With the network computer paradigm, this loading can take place every time the user turns on their terminal equipment.
Project 4.1 recommends that specification for users terminals should concentrate on the basic telecommunications interface, the basic programming interface, and its baseware functionality.
Recommendation 6: Management & Control Aspects for Commercial
ServicesThe standards described in recommendations 4 and 5 allow the construction of a distributed platform on which distributed application components can be mounted and communicate. This is based on processing platforms interconnected by telecommunications networks. While such a distributed platform fully meets the technical requirements of GII baseware, it still lacks the features needed to support commercial services. Another set of functionality needs to be added to this environment in order to offer to application components an environment within which commercial transactions can successfully take place.
The extra functions require standardisation support and need to cover functions and protocols for commercial and legal aspects of the relationships between roles. These should give full expression to the both the rights of a role, such a copyright, and the obligations of a role, such as a commitment to offer service to an agreed level of quality. At a more detailed level, these functions will cover the different phases of service from the initial negotiation to provide service, to the customisation of a service interface, to the monitoring of individual instances of service usage and the quality of service delivery, to charging and billing for the service, and to policing for abuse of the service.
Project 4.1 recommends that the further functionality which is needed, in addition to that of a distributed platform, in order to support application components and services with a fully commercial framework carefully analysed. This should identify the required functions and protocols and that, if need, standards should be developed in support of these functions and protocols.
Recommendation 7: IP, ATM and differentiated Quality of ServiceThere are several different views on the way in which IP and ATM should fit together. These cover the following broad areas:
- the way in which the real-time services supporting audio and video streams are carried and whether they should always be carried in an IP packet or whether they should carried "native" on ATM (both H.320 and the MPEG frame are factors in this discussion);
- the set of connection control protocols which should be used, whether the signalling protocols of ATM, eg Q.2931, or the capacity reservation protocol (RSVP) of the Internet;
- the extent to which it is useful to carry IP packets in ATM cells in or to can multiservice traffic efficiency.
These discussions do not often consider the service features which affect the commercial relationship between a service provider and the user. Both IP and ATM have grown up with very different structural models for services. IP has grown up with a structural model, whereby the user pays for subscription tariff and can access anywhere for as long as desired within the subscription agreed. However, it is very difficult to offer a differentiated quality of service, even by subscription, and certainly not on an individual usage basis. In addition, most content is shared freely, either through altruism or for advertising purposes. ATM has grown up in the structural model for telephony where there is a subscription charge (line rental) andby also a significant usage charge which is dependent on duration of usage, distance of the connection, and the bandwidth of the connection. This structural model, while able to offer differentiated quality of service, does not reflect the transport usage patterns in the GII.
Project 4.1 recommends that neither of the existing structural models of IP or ATM is sufficient and an integrated structural model is required for transport services of the GII. This will include the ability to offer differentiated quality of service. The integrated structural model should be a major driver in the decisions on the fit of IP and ATM.
Recommendation 8: Role of StandardizationMany of the initiatives within the GII are fully global including DAVIC, ATM Forum, IETF, OMG, W3C, ActiveX Consortium, The Open Group, etc. and these bodies do not have a history of regional co-ordination, especially through regional standards bodies. However, there is no specific activity, other than the early activity in ITU-T and ISO on an overall architecture framework in which all these activities fit.
Please send questions or comments to: Reid Andy: reida@oldpaul.agw.bt.co.uk .