MANAGING QUALITY OF SERVICE IN MULTI-PROVIDER ENVIRONMENT

Transcription

1 MANAGING QUALITY OF SERVICE IN MULTI-PROVIDER ENVIRONMENT Terje Jensen, Irena Grgic, Ola Espvik Telenor AS (Norway) Abstract Ensuring Quality of Service (QoS) today is a challenge, because the provider usually does not have full control over all the resources involved. Frequently, a user/customer will require that one provider guarantees the QoS, even if the service delivery involves multiple providers. A generic framework suitable for such a multi-provider situation capturing QoS-aspects in the present and future situations is presented here. The framework is complementary to existing frameworks and models and thereby might work as a joining description. It is applicable independent of services, technologies, networks, etc. The QoS provided to a user is a function of a provider s local influence and the QoS contributed by any sub-providers. As seen from a provider, it is the sole responsible for the aggregated QoS delivered to a user. Determining the appropriate QoS-related mechanisms to apply locally and in co-operation with others is an essential challenge in a multi-provider environment. Interchange of information between users/providers is also a central part of managing QoS. 1. INTRODUCTION For many telecommunication services, a provider has frequently to rely on service contributions from a number of providers in order to fulfil service obligations. Still the provider would be responsible for delivering the agreed QoS (Quality of Service) to the user (one-stop responsibility). It is foreseen that more users will require more explicit guarantees of QoS for provision of services, like services considered as part of the Internet. Thus, the control and verification of QoS is becoming increasingly important to both service providers and their users. Having a structured collection of concepts (i.e. a QoS framework) enables Public Network Operators (PNOs)/Service Providers (SPs) to handle QoS more efficiently. In particular, a QoS framework includes QoS terminology and related aspects like characterisation and management. Various international bodies have made efforts towards making QoS frameworks e.g.: ITU (International Telecommunication Union) where part of Rec. E.800, [1], is adopted by IEC (International Electrotechnical Commission) as terminology standard IEC 191. ETSI (European Telecommunication Standards Institute) framework, [2]. This framework is based on the work of the FITCE (Federation of Telecommunication Engineers of the European Community) Study Commission [3]. The ISO (International Standards Organisation)/OSI (Open System Interconnection) QoS framework [4]. The Telecommunication Information Networking Architecture Consortium (TINA-C) QoS framework [5]. ETNO (European Public Telecommunications Network Operators Association) Working Group 07/95 on QoS, which is constantly working toward a 1 consistent set of common European QoS parameters (QoS indicators). The aim is to harmonise European QoS definitions and possibly performance targets for pan-european services, in order to facilitate comparison of the results of the measurements. The work is based on the approach of the FITCE Study Commission and ETSI. The work has hereto concentrated upon voice telephony. EURESCOM (European Institute for Research and Strategic Studies in Telecommunications), which has addressed QoS issues in a series of projects e.g. [6], [7], [8]. Although a majority of PNOs traditionally applies the ITU QoS framework, the existence of a mixture of frameworks/qos parameters and PNO internal inventions makes the QoS problem even more complex both for the user and the provider. In addition, they create inefficiency in research programs addressing QoS issues. Considering the challenge of assuring QoS, one of the main achievements would be to arrive at harmonised understanding of QoS among the myriad of actors involved in service usage/provision (e.g. users, service providers, content providers, regulatory authority, etc.). In view of the ever growing number of services, actors, networks, technologies and their structuring and relationships, such an understanding should be as general applicable as possible. However, further details can be supplied for specific service implementations without contradicting the principles of the generic QoS framework. A generic structure of interconnection agreements between involved actors will be described as part of a harmonised understanding. This is an area of steadily increasing interest, facing questions like how to provide adequate end-to-end QoS when several providers are involved. This also addresses the question of how the content of the set of agreements would be related for a service delivery. In particular, this is an essential issue for the interface towards the end-user, related to other interfaces in the service provision chain.

2 Managing QoS includes activities for establishing and following up QoS-related issues. A central element in order to manage successfully QoS is to have an adequate framework in place. Such a framework should meet the following requirements: Applicable in a multi-provision environment, where relationships between the involved actors are requested, implying provisioning of services at different types of interfaces. Applicable to all service life cycle phases of a service provision. Applicable to all types of services at different functional levels. Applicable to all types of actors (i.e. providers, users), networks (logical as well as physical) and technologies (e.g. copper, fibre, radio). Applicable for management aspects related to QoS, such as measurements and degradation tracing. As far as possible, in line with, or at least not contradictory to existing frameworks, models, methods, etc, as well as Open Network Provision (ONP) directives. In this paper a generic QoS framework answering on those requests is described. It is developed within EURESCOM P806-GI project, and therefore named EQoS (EURESCOM QoS) framework. The EQoS framework is generally applicable for the multi-provider configurations, and it may serve as a basis for elaborating more service/implementation specific models. The basic concepts and main achievements of this framework are described in Chapter 2, followed by a short example related to IP-based services given in Chapter 3. Some relationships with other QoS models are briefly presented in Chapter 4. Chapter 5 discusses selected topics for managing QoS in a multi-provider environment. 2. FUNDAMENTALS OF THE EQoS FRAMEWORK In general, a QoS framework defines QoS-related terminology and concepts helping us to handle QoS. The EQoS framework brings a harmonised understanding of terms essential to managing QoS. It also introduces the notion of one-stop responsibility and elaborates the possibilities of applying it in a multi-provider environment. 2.1 QoS the term A starting point when establishing terminology related to QoS is the term Quality of Service itself. In the EQoS framework QoS is defined as the degree of conformance of the service delivered to a user by a provider with an agreement between them. QoS is described through the selection of a set of QoS parameters, specification of QoS target values and the choice of QoS measurements and evaluation mechanisms. A QoS parameter is a variable that characterises QoS. This is a strengthening of the QoS definition compared to the one given in by ITU-T Rec. E.800, [1], as illustrated in Figure 1. As depicted in Figure 1, [1] refers QoS to a user s satisfaction. This involves a certain level of subjective evaluation taking into account that different users are likely to have different expectations and understandings of the service provisioning. In principle, expectation and understanding may neither completely cover or be covered by the area of satisfaction. Compared to this, EQoS refers QoS to an agreement in order to introduce more objective considerations. As shown in Figure 1, there might not be complete overlap between the area of satisfaction and the agreement. As seen from a provider s point of view, the area of satisfaction for an individual user may vary during time, e.g. depending on a user s equipment, mood, etc. making it too volatile for business relationships. Therefore, an agreement is chosen as reference for QoS. SATISFACTION AGREEMENT ITU-T Rec. E.800 EQoS QoS Figure 1 QoS references (agreement and satisfaction) It is essential to observe that the quality of a service is, basically, different from the functions provided by the service. This means that QoS is not an attribute of the service itself, but it is rather related to how the service is provided. This recognises the choices of a provider that typically include the service portfolio to provide, the price of the services in the portfolio and the quality by which each service is provided. 2.2 Service provision terms Some terms have been defined in order to clarify the interpretation of the EQoS framework. They are illustrated in.figure 2 An entity is a generic unit characterised by its set of states and transitions. A number of entities can be composed into a new entity. Here, the behaviour of an entity is described as seen from an outside observer. An interaction point is a point where to entities exchange information. A set of interaction points constitutes a logical boundary between two entities i.e. an interface. A service is the result of executing a set of functions and is provided at the interface. It might be composed of multiple information exchanges between the entities. A provider is an entity that provides service to another entity. A user is an entity that makes use of a service provided by another entity. 2

3 USER ENTITY SERVICE INTERFACE PROVIDER ENTITY Figure 2 Provider, user, service and interface Such a fairly abstract level of description allows for capturing the provision of any telecommunication service. Furthermore, it is not restricted only to telecommunication services, but in a similar way it applies to provision of most services in other areas/industries. The contributions from other areas can also be considered and appropriate results incorporated. It should be noted that the term entity relates to user or provider while the term actor refers to units related to service provision (e.g. organisation or person). 2.3 Recursion and dependency In a multi-provision environment, the QoS provided by one entity usually depends on adequate operation of other entities. Thus, there may be a need for relating the QoS levels obtained for the different interfaces, see Figure 3. QoS ji QoS kj L_QoS j Provider k User i Actor i Service ji Provider j User j Actor j Service kj Actor k Figure 3 Schematic illustration of QoS related to interfaces between (groups of) entities Naturally, multiple interfaces may exist between one pair of actors in an actual configuration. However, due to the potential dependencies between interfaces, mechanisms for supporting the realised QoS at the interface may be implemented in a number of ways. This could also be looked upon as a business decision: the utilisation of local QoS-related mechanisms as opposed to the QoS seen on the interfaces towards sub-providers. In fact, such a tradeoff could be an essential issue for a provider. In principle, the QoS provided/delivered at the interface between actor j (as a provider entity) and actor i (as a user entity) can be formulated as a function f: ji ( QoS ) kj, L _ QoS j QoS = f (1) Where: QoS ji is the QoS seen by entity i on the interface between entity i and entity j. QoS kj is the QoS seen by entity j on the interface between entity j and entity k (entity j then as a user). L_QoS j are the QoS mechanisms involved, which are present locally in the entity j. Referring to Figure 3, it should be noted that service ji would typically differ from service kj. For instance, actor j could be an Internet Service Provider while actor k is an operator providing leased lines. Service kj may then be a leased line service and service ji could be an IP-based webbrowsing service. Naturally, for this example a range of actors of type k would be present. It is emphasised that although dependencies are identified between QoS referring to different interfaces, a single provider is responsible for the aggregated QoS towards a certain user. Simply, in Figure 3, actor j is responsible for QoS towards actor i, QoS ji, even though this depends on other actors as exemplified by (1). This is the one-stop responsibility concept. Naturally, a user may see various levels of details of services (and service components). Having a clear view of which service that is provided at an interface is essential. That is, the service provided has to be unambiguously specified. The QoS has to be described accordingly. 2.4 QoS parameters The QoS parameters related to each service can be arranged in a hierarchical manner, e.g. as described in [1], as well as by specialising and elaborating derived parameters, ref. [9]. The quality of a service is expressed by assigning values (e.g. target values or actual, measured values) to a number of parameters. Grouping QoS parameters and assigning target values would invite for identifying QoS classes. That is, examining the requested QoS for services, typical correlation between parameters might be found. For instance, tight requirements on delay and appropriate requirements on information loss ratio could be stated for real-time services. Some non-real-time services could request weaker requirements on delay while information loss ratio is tighter. Three categories of QoS parameters are identified, ref. [10]: Speed characterises the temporal aspects. Accuracy characterises the degree of correctness with which a given function is realised. Dependability characterises the degree of certainty that a function is performed. An illustration of these categories of QoS parameters referring to a function is given in Figure 4. Considering the various phases of a service life cycle, relevance of parameters may vary. Furthermore, the actors involved may change their roles as the various service life cycle phases evolve. 3

4 Dependability (probability that the result from executing the function is obtained) function Speed (delay from entrance to exit) Accuracy (correctness of result from executing the function) Figure 4 Categories of QoS parameters associated with the way a function is executed in order to provide a service In particular, returning to the EQoS definition of QoS, an agreement is referred to. This, however, does not mean that an explicit agreement has to be in place between the actual pair of user and provider. An agreement could also include the conditions announced by a provider or required by a regulator on which a user might base the potential service provision. That is, the different viewpoints, like requested QoS, offered QoS, etc. as described in [2], would also be considered by the EQoS framework. 2.5 User provider agreement QoS aspects as part of agreements would be related to most interfaces, for instance starting from the end-user and considering the set of providers involved. As discussed in the previous section, a number of providers/operators can be involved in the service provisioning. However, the onestop responsibility concept implies that one provider is responsible for the (aggregated) effect of the QoS present at the interface. A number of topics will be included in such agreements, e.g. see [11]. The QoS-related issues of a generic interconnection agreement are depicted in Figure 5. user Interface description Traffic patterns agreement service QoS QoS class Measurement schemes provider Reaction patterns Figure 5 An agreement established for an interface between a user and a provider presence of such agreements is a central matter in managing QoS. On one hand, the set of agreements facing an actor restricts the actor s flexibility. On the other hand, it also supports the actors when determining its management dispositions. Furthermore, agreements would also allow for higher degree of predictability concerning the actions undertaken by the actors. The set of considered issues includes descriptions of: Interface and service Traffic flow patterns described by assigning values to relevant traffic parameters QoS class given by QoS parameters and related target values Measuring schemes and mechanisms Reaction patterns to apply in case agreed restrictions on traffic patterns or QoS parameter values are not fulfilled Several of the terms (like traffic patterns) could be generalised in order to be applicable for every service life cycle phase. The corresponding terms might then be adapted in order better to describe the relevant aspects. The actors must also be seen to behave according to the intentions behind the agreement. Therefore, enforcing the behaviour sought for the actors, adequate reactions should be implemented. The nature of reactions would be multiple, depending on the phenomena on which the reaction is to regulate. That is, load control, charging schemes, legal actions, etc., may all be covered by the reaction patterns. Generically, one could say that the agreement structure describes the interface/service, how the user should behave (traffic patterns) and how the provider should behave (QoS class). Then, ways of assessing the actors behaviour (measurement schemes) and appropriate actions in case the behaviour is not as agreed (reaction patterns) are included. That is, this should be seen as applicable to most service provision situations. 3. SIMPLE INTERNET-BASED SERVICE EXAMPLE The essential issues discussed in previous sections are applied on a simplified example of Internet-based services. The Internet services are requiring adequate operation of a number of network domains and end-systems managed by different providers/operators. One portion that we focus on here is shown in Figure 6. Let us first identify the actors involved in such a configuration: End-user (U) Internet Service Providers (ISP1, ISP2). A structure of interconnection agreements describes possible aspects that should be included. One motivation for elaborating an agreement structure is to allow for more rapid, accurate and automatic establishments of such agreements. In particular, this is requested because of the multitude of actors that could be involved. In fact, the 4

5 U X IA x QoSA X ISP 1 ISP 2 IA Y QoSA Y Y interface ISP Internet Service Provider IA Interconnection Agreement QoSA QoS related part of IA content Figure 6 A www browsing involving two providers ISP1 is a service provider offering services to U at the interface X. They would then establish agreement IA X. In order to fulfil its user s requirements for a specific content, ISP1 has to rely upon the service provided by ISP2. Thus, ISP1 is acting as a user towards ISP2 having interconnection agreement, IA Y. On the other hand, ISP1 is the main provider responsible for assuring the content access to U, in which case IA X is relevant. In the following, examples of QoS issues to include in an IA are described. Naturally, when deriving the actual values, end-to-end requirements should be considered. The possible content of QoS part of IA Y, QoSA Y, is treated in the following. Interface description: Includes a description of protocols used. In this case, the version of IP possibly based on an underlying data link layer protocol would be stated e.g. IPv4. Traffic pattern: Characteristics of the traffic flows, e.g. specified as mean value (and higher order moments) of bitrates. Different types of traffic flows like user-related, routing updates, and so forth, could be given. Examples of such characteristics, referring to a certain period are: - total traffic between ISPs - peak traffic load - duration of sustained peak traffic load QoS class(es): Parameters could refer to mean values and higher order values. Aggregates of parameters might also be relevant as well as differing on types of traffic flow. A selection of parameters could be, e.g. [12]: - IP- packet transfer delay (Speed) - IP- packet error ratio (Accuracy) - IP- packet loss ratio (Dependability) - IP- transfer availability (Dependability) To exemplify this approach, the QoS parameter of availability is observed. Let us name the availability of the service provided by ISP1 at the X interface as A X, while A Y is availability provided to ISP1 by its sub-provider ISP2. Applying the approach and formula discussed previously, the resulting availability at interface X is: X Y ISP1 ( A, L _ A ) A = f (2) where local mechanisms for assuring the availability in ISP1, L_A ISP1, expresses the contribution to the total availability provided by ISP1. The function f in this case may be represented as a multiplication function. Then, a simple expression for the availability observed at the interface X might be given as: X Y ISP1 A = A L_ A (3) Considering the actual values when applying (3), it simply means that if the availability agreed in QoSA Y is A Y =0.95, and the local mechanisms for managing availability within ISP1 domain give no less than 99%, i.e. L_A ISP1 =0.99, then accumulated availability provided to U is A X =0.95*0.99=0.94. This implies that in QoSA X the availability value should be no greater than 94%. In case it is delivered less than 94%, ISP1 might have to apply compensation scheme or some other reaction patterns to compensate the degradation for U. Measurements: Schemes for how to carry out measurements have to be described in order for the two actors at the interface to obtain an unambiguous view of the situation. Traffic characteristics and QoS parameters addressed above have to be measured. Measurement schemes can be chosen by considering e.g. ref. [13], [14], [15]. Reaction patterns: Reactions related to the nonconformant traffic incoming at the interface can be alert/warning/error messages, load control, traffic shaping, re-configuration of reserved resources, etc. Reactions regarding QoS parameters could be re-routing of traffic flows, re-configurations, penalties, increased accounting rates, and so forth. As an example, UUNet experience [16] can be considered. 4. THE EQoS FRAMEWORK PERSPECTIVES The EQoS framework is collecting a limited set of basic concepts outlined in Chapter 2 namely: The QoS definition The service definition The one-stop responsibility concept The agreement at interfaces The user - provider recursivity Together those principles make a generic super structure that allows us to encompass all standardised QoS frameworks into a coherent approach to QoS - given they adopt the EQoS definition of QoS. In that way the EQoS framework can also be considered as a framework that harmonises existing QoS frameworks. The existing frameworks taken up in Chapter 1 do not contradict each other. In fact they complement each other in the sense that they are tailored to specific viewpoints. This is illustrated by the EQoS framework triangle as depicted in Figure 7. The generic concepts of the EQoS framework are located on the top of this triangle. As given by the set of requirements to be met by the generic framework, it is to be applicable for different services, users, networks, technologies etc. Fulfilling these makes EQoS framework a basis for deriving more specialised instances related to specific services, networks, etc. One specific issue is the definition of relevant QoS parameters, which can be adapted to the network/system/service considered. 5

6 level of tailoring generality EQoS framework specialised frameworks Figure 7 The EQoS triangle One of the ideas in the EQoS framework is the description of user provider pairs and the corresponding service, in particular its quality. This can also be looked upon as a depends-on relationship. Such a depends-on view is less clear in other QoS models, e.g. compared to ITU-T Rec. E.800, [1]. However, grouping of QoS parameters for different areas as presented in [1] can be applied. This does not oppose the categorisation depicted in Figure 4, also found as parts of ITU-T and ETSI documents. A depends-on view could also be considered as part of the ISO OSI model, where a subordinate layer provides service to the next one. By the EQoS framework this could be seen to be generalised into any service provision between any pair of user and provider. 5. MANAGING QoS 5.1 Handling QoS agreements Given a service provision configuration, the set of interfaces should be described and relevant agreements should be attached. Processes related to the actions should be automated as much as possible. This includes performance reporting, network resource reservation, trouble ticket reporting, measuring and information exchanging, which should be maintained according to the schedules/rules stated in the agreement. As seen from one provider s point of view, the increasing number of actors further emphasises the urge for having automatic routines involved. This includes all steps from announcement and negotiation till cessation. Then, service and QoS should be understood in a wide sense. Generally, an agreement is an arrangement of understanding made between two actors, represented as a set of statements. However, an agreement, in this context, could also be made of announced conditions from one of the actors on which another actor could base the potential service provision. Conceptually, several parts of a QoS agreement can be formulated as a set of statements like: if <conditions> then <actions> else <actions>. Conditions refer to the thresholds found for characteristics of traffic patterns and the QoS class, while actions refer to the reaction patterns and possibly measurement schemes. Then, a set of statements could be applied in order to describe the behaviour accompanying the operation of an agreement. Recognising the resemblance of such a statement and software code statements invites for further exploitation of software agents in order to handle parts of the agreement conditions. 5.2 Application of software agents A software agent is often introduced in order to make routines more automatic and increase the speed and accuracy of certain operations. Considering sets of interconnection agreements, potential applications of software agents can be identified. One list of activities which a software agent could undertake is, see Figure 8: Situation recognition, e.g. through sensors/input devices Objective formulation and tracing Planning of tactics, including deciding which further activities to carry out Execution of plans, including set of output devices Knowledge base, storing information based on the experiences done as well as initial information planning execution objective tracing recognition knowledge base Figure 8 Schematic picture of an agent s activities with main information flows (all activities would also interact with the knowledge base) Naturally, a spectrum of application areas could be possible. For instance, one application area is collecting measurements results and initiating further specific measurements if found needed. Another application is acting like a purchasing agent, that is, taking care of the negotiations in order to arrive at some of the conditions in an agreement. Some of the conditions in an agreement might be formulated in a fairly technical language. Considering a human end-user, specific applications of agents could be translating between a technical language and user-adapted ways of expressing the conditions. One area of interest for applying agents is to initiate reactions based on specified trigger criteria. A set of reaction patterns must be described, related to exceeding one/more of the thresholds/limits stated in the agreement. This is to be applied in case agreed values for certain QoS parameters are not met, or, simply, when degradation/failure is detected. A number of possible (re)actions may be taken by either party upon degradation, like: 6

7 No action (present best-effort service provisioning principle) Monitoring the achieved QoS, possibly storing an observed value for future reference (e.g. for enquiry purposes) Reserving or reallocating resources Information flow controlling mechanisms such as traffic shaping, admission policy control as attempting to keep information flow within limits Warnings, error signals to the customer or service provider Suspending or aborting the service The list of possible reactions would be part of the information/knowledge within an agent. In addition, the agent must have means to initiate the proper actions. Again we see a range of potential applications for a software agent. 5.3 Reporting QoS-related data The growth of telecommunication markets has a consequential need for automated, efficient and standardised information exchange processes between the parties involved in service provisioning/usage both at the service and the network level. Appearance of new services and new interface types and the information necessary to be exchanged between each pair of actors are becoming more complex and rapidly growing. Descriptions of information exchange principles need to be included into an agreement. QoS can be improved by supporting rapid, accurate and reliable information exchange between the involved parties. A simplified illustration of potential parties involved, based on the EQoS Business Interface Model, is given in Figure 9. Information collecting/processing EQoS Business Interface Model User Transport/connectivity provider Service provider Figure 9 Simplified illustration of potential parties involved in information exchange and accompanying interfaces Here, an information collector is a party taking care of gathering, systemising and advertising (parts of) the information according to the rules decided. In principle, this can be any entity. However, this can also be considered as a common body, e.g. acting on behalf of a regulator. Naturally, such an information collector (that is, as a separate/external entity) may not be present. From the outset, the information exchange principles should cover all service life cycle phases, although some phases will be of more interest than others. Depending on the level of information exchange, different practices should be worked out. In some cases the presence of an information exchange centre, as a separate actor, would be necessary and would determine, to a great extent, the method of working. One example is found in the EU regulatory articles. An information exchange centre should be a trusted organisation that collects data and guarantees confidentiality of the information as appropriate. Even if different groups of users would be sharing their data amongst the members of each individual group, one information exchange centre could serve all those groups. It should then keep the data sharing restricted for use within the groups In principle, one may strive for a uniform measuring system which opens the possibilities of sharing data that resulted from measurements. Such information exchanges can be performed in various ways, depending on the degree to which the parties involved are prepared to cooperate. The following options have been determined: No data exchange: the measurement data are collected, but are not disseminated. The measurement data are for internal use only. Bilateral data exchange: data are exchanged between the connected parties only, possible with a nondisclosure statement. Best practice data exchange: only the best practices for each particular measurement is public and is published anonymously. Aggregated data exchange: the measurement data are disseminated (anonymously) in an aggregated form. Full data exchange: all measurement data are shared among providers. It is recognised that practising QoS information exchange can have a positive influence on a provider s QoS assurance activities. On the other hand, negative aspects regarding feasibility and effort needed should also be taken into account. When recommendations for an appropriate policy for information exchange is considered, the following considerations should apply: The evaluation of how far the providers would wish to go should come from the providers themselves. The decisions are likely to be made at management levels that may have little experience with such measurements, so it would be difficult and time consuming to elicit this information to a sufficient level of precision, and certainly to formulate a well founded recommendation for an optimal level. The considerations on which criteria these decisions are based will probably evolve over time. This may result from the growing use of measurements and insight into how well they express the important aspects of the services, and with familiarity with the confidentiality aspects involved in their usage, and the emergence of ways of handling these aspects. 7

8 Due to these reasons, it is not generally feasible to define an optimal degree of use of information exchange that may be valid for a longer time period. Different information exchange models and corresponding procedures/actions should be evaluated. The generic principles include models of exchange of management information, measurements, controlling messages, trouble ticketing, performance reporting, etc. Additionally, both flow diagram and event diagram (scenario) should be attached to each process and related mode. In accordance with ONP issues, the information can be related to basic and service-specific aspects. In principle, the information exchange can be carried out: on-demand, implying that a user (or an information collector) is asking for the information each time; periodic, giving that the information is transferred at regular instants, or, event triggered, implying that an event (scheduled in advance, or occurred in past) is deciding when the information is to be exchanged. A combination of these is likely to be related to every specific user provider interface. 6. CONCLUDING REMARKS In this paper the ideas behind the EQoS framework are outlined. Some work has been undertaken to demonstrate how the EQoS framework relates to the existing QoS results presented by different forums, e.g. [8]. Due to its generic approach, the EQoS framework allows for adaptations of several of those results, which commonly are derived on more specific applications and objectives. Having elaborated this framework, some follow up activities could be to describe potential implementations for various areas, like marketing and operation. Still there are several issues that should be further studied, such as QoS consequence and relationships with tariffing. The generic framework presented would then allow for incorporating results from other areas of business in order to describe a sound base for managing QoS. Performance considering Customer Framework (working draft). Requirements. [4] ISO IEC JTC1-SC21: Quality of Service Framework (working draft). [5] TINA-C: Quality of Service framework, doc. no TR_MRK.001_1.0_94. [6] EURESCOM P603: Quality of Service: Measurement method selection. series/p603/p603.htm [7] EURESCOM P619: PNO Suppliers technical interfaces. p600-series/p619/p619.htm [8] EURESCOM P806-GI: A Common Framework for QoS/Network Performance in a Multi-Provider Environment; Projects/P800-series/P806/P806pr.htm [9] ITU-T Rec. X.641: Information Technology Quality of Service: Framework. [10] ITU-T Rec. I.350: General aspects of Network Performance and Quality of Service in Digital Networks, including ISDN. [11] ITU-T Rec. E.801: Framework for service quality agreement. [12] ITU-T Rec. I.380: Internet Protocol Data Communication Service IP Packet Transfer and Availability Performance Parameters [13] IETF RFC 2123: Traffic Flow Measurement: Experiences with NeTraMet. [14] IETF RFC 2330: Paxson, V., Almes, G., Mahdavi, J., Mathis, M.: Framework for IP Performance Metrics, May [15] IETF RFC 2498: Mahdavi, J., V. Paxson: IPPM Metrics for Measuring Connectivity, November [16] UUNet SLA Terms and Conditions: 7. Acknowledgements The EQoS framework is developed by EURESCOM. Although the material presented in this paper is solely the responsibility of the listed authors, discussions with other persons involved in EURESCOM P806-GI [8] are recognised. REFERENCES [1] ITU-T Rec. E.800: Terms and definitions related to Quality of Service and Network Performance including dependability. [2] ETSI ETR 003: Network aspects: general aspects of Quality of Service and Network Performance. [3] FITCE Study Commission: The study of Network 8