5 Mapping Service Requirements to Network Resources The ability to properly map services to network resources in a multi-service network is highly important both for making the initial configuration of a network domain, and also as a basis for performing network configuration optimization. The basic task in both cases is the same, although in the latter case there is an initial configuration to start with, as well as potentially a larger number of existing boundary conditions for the new configuration. Resource allocation is an optimization problem where the avail- able network resources, SLAs for different parties, and require- ments of service types are examples of boundary conditions. The SLA interfaces relevant to resource allocation are illustrated with an example configuration in Figure 5.1. The responsibility of end- to-end service quality can be thought to be by default with service providers, who use SLAs towards network transport providers to implement the service quality. Alternatively, an access network operator may provide a set of services from outsourced Applica- tion Service Providers (ASPs), such that the access network oper- ator is responsible for end-to-end service quality. There may be more than one service provider involved, for example, in using IP telephony services in such a way that the Implementing Service Quality in IP Networks Vilho R ¨ ais ¨ anen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X 134 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES SLA SLA SLA SLA SLA SLA Service subscriber Service operator Transport operator Service operator Transport operator Service subscriber Figure 5.1 SLA reference model for the present chapter caller and callee use different IP telephony service providers. In the general case, there may be also transit operators involved. As to services, both external service operator/transport operator and operator-internal service/transport interfaces are illustrated in Figure 5.1. In general, there is no need to have a one-to-one relationship between service and transport operators. Available network resources are the most limiting factor when service mapping in multi-service access networks is considered. This is true not only when the network infrastructure already exists, but also when a new network is being built. In backbone networks, on the other hand, more conservative network dimen- sioning is typically possible due to higher flow aggregation levels. The generic traffic engineering process described in the last chap- ter can be used to optimize the use of the available resources in both access and backbone networks, but the starting point for this optimization is the initial resource allocation. When traffic engi- neering process can be applied, requirements for the accuracy of the initial configuration become smaller. When the traffic volumes transported in the network domain are anticipated to grow with time, dimensioning of a new network infrastructure usually takes into account future growth in traffic volumes. Also in this case, the initial configuration is not as critical as for a fully loaded multi-service access network. The goal should nevertheless be as precise as possible a resource allocation, starting from the antici- pated shares of traffic types. SLAs for direct end user customers can provide flexibility for resource allocation, if SLAs include traffic types that can be used for this purpose. The SLAs for different customer segments and services may be different with respect to degree of details of service quality support provided. As discussed in Chapter 2, for services with stringent quality support requirements such as 5.1 SCOPE OF THIS CHAPTER 135 multimedia conferencing, absolute guarantees may be necessary. On the other hand, for data type services, statistical guarantees may be sufficient. A change of admission control policy to demand service quality types is a tool that can be used to control the resource allocation in access networks when the service quality invocation procedures allow for this. Towards the service and network providers, the SLAs are typi- cally more static. The resource allocation optimization and applica- tion of the traffic engineering process may result in a need to mod- ify the SLAs, but this typically takes place at longer timescales than one associated with resource management for the operator’s own end user services. Thus, it could be said that the traffic engineer- ing process should also yield an indication of its means becoming exhausted, being indicative of a need to modify SLAs or by other means restore the operational efficiency of traffic engineering. 5.1 SCOPE OF THIS CHAPTER Chapter 2 described the intrinsic requirements of services and their characterization. Chapters 3 and 4 described mechanisms for providing service quality support in the network. This chapter deals with the link between service requirements and IP network service quality support. The concepts in this chapter are used in discussing service management in the next chapter. Let us next define the reference model for this chapter. For the purposes of the present chapter, the end-to-end delivery path for service instances is assumed to consist of multiple trans- port operators, each capable of providing support for service quality for a set of services, either statistically on the level of behavioural aggregates or per flow (cf. Figure 5.1). It is further assumed that each transport operator is capable of providing multi-service sup- port. Each transport operator is assumed to be using a per-domain service quality support mechanisms independently of each other. The actual mechanisms can be circuit-switched guaranteed QoS for telephony, over-dimensioning, or DiffServ, to name but a few alternatives. The resource allocation discussion in this chapter per- tains to a multi-service DiffServ domain specifically, and thus is most directly related to access networks. Services are assumed to be managed by service operators by having Service Level Agreements (SLAs) with end users, with 136 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES transport operators and between each other, as necessary. A transport operator may also be a service operator, in which case the service operator/transport operator interface is an operator-internal one. Referring back to the client/server and connectivity/service paradigms used in Chapter 2, the model of Figure 5.1 is of latter type, allowing for signalled inter- operation of service providers for a single service instance. The client/server application of Figure 5.1 could only involve single service subscriber, single service operator, and one or more transport operators. For the service provider, service quality provision is at best related to the intrinsic quality requirements of individual service event types. Depending on the SLA type, the service provider may also need to understand service quality support mechanisms of the transport operators. For the transport operator, on the other hand, one part of the optimization problem is allocation of services to proper service quality support classes. This is a part that the ser- vice provider may need to understand, unless the SLA between the service provider and transport operator is sufficiently detailed for the service operator not to need worry about technical details of the service quality support details. A second aspect of the transport operator optimization relates to using resources effectively to implement multi-service SLAs for different parties involved. Efficient resource usage includes select- ing an optimal set of supported service quality aggregates, and using network resources to implement SLAs using the aggregates. Here, it is assumed that the service provider and the transport provider are able to negotiate the behavioural aggregate used for service quality support. In the discussion below, the SLAs for service providers are con- ceptually seen as boundary conditions for the resource allocation of the transport operators’ own end user services, the basic process and target of resource allocation being the same for both types of traffic aggregates. For operators’ own services, there is no need to take into account an external negotiation interface towards differ- ent business party, which is why they are used for simplicity in the discussion below. Next we shall review service quality support-related resource allocation models from ETSI EP TIPHON, Third Generation Partnership Project (3GPP), and QoS Forum. Two further DiffServ- related examples are provided due to their relation to policing, one 5.2 ETSI EP TIPHON REFERENCE MODEL 137 of them being draft ITU-T model. After that, the concept of utility- based resource allocation is reviewed. The TIPHON reference model is relevant to IP telephony, that of 3GPP to mobile services, while the QoS Forum and ITU-T models and utility-based resource allocation reference models are generic in nature. The concepts from these models are used in formulating a generic framework for resource allocation for multi-service IP network. 5.2 ETSI EP TIPHON REFERENCE MODEL The European Telecommunications Standardization (ETSI) is an organization making international telecommunications standards. The best-known ETSI standards are probably GSM and UMTS. During the latter half of the 1990’s, ETSI founded the IP telephony project TIPHON, which has devised a reference models for IP telephony, in which service providers can be separated from trans- port operators [TIPHON-3]. The model pertains to IP telephony specifically, but is sufficiently generic to be used here. While some- what abstract, it illustrates the logically necessary functions and interfaces of a separated service/transport paradigm. Particularly valuable for the present purposes, the ETSI TIPHON reference model also includes a QoS reference model. 5.2.1 Architecture The reference model consists of separated service and transport layers, and is illustrated in Figure 5.2. The two-tier model allows for telephony providers, using Session Initiation Protocol (SIP), for example, to operate without having to build own transport networks. When a VoIP call is set up between the communicating parties, the IP telephony service provider for the calling party sets up the call by communicating with the service provider of the called party, as necessary. The respective service operators at each end set up necessary transport resources. As a result of the resource set-up, the communicating hosts may be provided with a QoS tokens to authorize the access to appropriate transport resources [TIPHON-3]. 138 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES TRM TRMTRM Telephone Telephone Transport operator 1 Transport operator 2 Transport operator 3 Service provider 2 Service provider 1 Figure 5.2 ETSI EP TIPHON reference model Note : Solid lines denote the transport layer, dotted lines the service layer, and dashed lines the link between service and transport layers The reference model has been targeted to be “agnostic” with respect to QoS mechanism used on the transport layer, and should therefore work with ATM, IP QoS mechanisms including Diff- serv and IntServ, and over-provisioning, for example. End-to-end QoS requirements of services are dealt with by using QoS budgets, so that the end-to-end service quality requirements are known, broken down into per-service provider allocations and further to transport level allocations. For example, the service provider 1 in Figure 5.2 is supposed to be able to calculate how much delay and packet loss is allowable in transport operator 1’s domain. Service provider 1 would then communicate this requirement to Transport Resource Manager (TRM) within transport operator 1’s domain to check whether the necessary service quality support can be imple- mented by the transport operator. The per-domain allocation does not have to be statically allocated for a particular path, but can also be dynamically negotiated. The QoS resource allocation may be iterative and affect call routing. As has been seen in previous chapters, the properties of the terminals potentially affect end-to- end service quality. In the TIPHON work, this has been taken into account by classifying the terminals according to their impact to end-to-end service quality. There is no need to have one-to-one correspondence between service and transport operators in TIPHON’s model. In Figure 5.2, Service Provider 2 has service quality support signalling interface to two transport operators along the end-to-end path. In fact, there need not be QoS interface from a service operator to each transport operator at all, but service quality support signalling can take place between transport operators. The QoS reference model [TIPHON- 3] also contains exemplary signalling charts for different inter- working scenarios. One signalling mode shown therein performs 5.2 ETSI EP TIPHON REFERENCE MODEL 139 Table 5.1 Functional elements of the TIPHON QoS control model Element Layer Description QoS Service Manager (QoSM) Service layer Mediates requests for end-to-end QoS based on policies stored in QoSPEs, communicating with other QoSMs and TRMs. QoS Policy Element (QoSPE) Service layer Manages service QoS policies and authorization. Transport Resource Manager (TRM) Transport layer Applies set of policies and mechanisms to transport resources to provide QoS guarantees across the domain controlled by the TRM. Transport Policy Entity (TPE) Transport layer Functional entity maintaining the policies of a transport domain. Transport Function (TF) Transport layer Logical entity representing the transport resources in the domain. Interconnect Function (ICF) Transport layer Entity for interconnecting transport domains; typically AD boundary with optional flow authorization policies. the end-to-end resource allocation set-up signalling entirely on the transport layer, initiated by communication endpoints (terminals). All told, TIPHON’s QoS model includes the elements listed in Table 5.1. QoS Service Managers handle the end-to-end service quality including QoS budget negotiations and interfacing to the transport layer, based on service layer policies. Instantiation of ser- vice quality on transport layer is controlled by Transport Resource Manager, which can operate on aggregate level or flow level. When IntServ is used end-to-end, service quality signalling takes place between TRMs and terminals. In TIPHON’s QoS control model, the service and transport lay- ers are logically separated from each other. Due to this, they have sets of policies that operate on different conceptual levels. The 140 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES policies of the service domain relate to authorization of service instantiations, whereas the policies of transport domain pertain to authorization of flows to classes of resources. The TIPHON QoS reference model lists three ways of allocating QoS budgets across transport domains: • Dynamic signalling of transport QoS parameters during call set-up. • Static SLAs between service domains. • Aggregation of transport domain resources and caching infor- mation of QoS resource availability. Per-call signalling is akin to per-flow RSVP reservations, and has similar kinds of scalability concerns associated with it. Particularly in IP telephony, the delay due to resource set-up is also important. Static SLAs between different parties is the simplest model. An elaboration of this allowing for more flexibility is the third model, in which admission control is performed to available resources between operators. 5.2.2 QoS model The TIPHON QoS model is illustrated in Figure 5.3, consisting of QoS characterizations on the user layer, application layer, and TIPHON Voice QoS Class USER Codec, Frames per Packet, Frame Size, Jitter Buffer Delay, FEC (Redundancy), Overall One-Way Delay, Packet Loss APPLICATION TRANSPORT Packet Loss, Mean Delay, Delay Variation Figure 5.3 QoS characterization of user, application, and transport levels in the TIPHON reference model Source :From[TIPHON-3] 5.2 ETSI EP TIPHON REFERENCE MODEL 141 transport layer. QoS characterization on user layer consists of the TIPHON voice QoS class, having five possible values: wideband, narrowband high, narrowband medium, narrowband acceptable, and best effort. Subscribers can choose between these classes based on associated pricing and quality attributes. The voice QoS class can also be a part of the subscription profile. Mapping of user layer QoS characterization to application layer characterization is performed by interpreting the voice QoS class in technical terms. The actual parameters involved depend on the outcome of end-to-end codec negotiation. In SIP, this is performed using the Session Description Protocol (SDP) during call set-up. For example, the negotiated parameters could include the codec to be used (for example, AMR, GSM FR, G.723.1, G.711) and the bit rate for the codec (ranging from 4.75 to 12 kbit/s for AMR). QoS characterization on the transport layer, that is, the service quality support that a transport operator needs to be able to pro- vide, are derived from two sources: 1. Application quality characterization. 2. End-to-end QoS budget. The two are not independent, as the end-to-end QoS budget may be used in negotiating the application parameters (codec). The choice of codec and audio sample size affect the end-to-end delay. The relation between end-to-end delay and end user experience used by TIPHON is shown in Figure 5.8 in Section 5.7.4. 5.2.3 Summary In ETSI TIPHON IP telephony reference model, the end-to-end negotiation is performed under control of service layer operators, and involves one or more transport operators. The service operator performs the mapping from service quality to transport resource requirements. The TIPHON QoS model consists of a subscription, codec, and transport levels, addressing the different abstraction levels that can be used in telephony. The transport operator uses a logical transport resource management element to perform admis- sion control to available resources. The weakness of the original TIPHON QoS model is the amount of per-flow signalling associated in admission control of a new 142 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES flow: at least one of the service operators was supposed to signal to one or more transport operators to ensure appropriate service quality support for the flow. When more than one service provider is involved in the end-to-end set-up, handling all scenarios arising from each operator using service quality support signalling with the transport operator or operators, call set-up delay can quickly become prohibitively large in such cases. The concept of perform- ing admission control to traffic aggregates was incorporated into the TIPHON model as a further mode, having better scalability properties. We shall return to the topic of admission control to aggregates in Chapter 8. 5.3 QBONE Internet2 project is a partnership to develop inter-domain ser- vice quality support for the Internet, led by US universities and participated in by a number of corporations and other organi- zations [THD + 99]. Distance learning, remote instrument access and control, advanced scientific visualization and networked col- laboration are listed as potential uses for service quality support in the future Internet. Internet2 addresses the following areas: applications, middleware, advanced networks, engineering, and partnerships. QBone is the QoS testbed of Internet2 to address the needs such as those listed above, and has been attended to by a number of network service providers. To quote the Internet2 website (http://www.internet2.org): The goal of the QBone is to provide an inter-domain test bed for differentiated services (DiffServ), where the engineering, behaviour, and policy consequences of new IP services can be explored. The goal of QBone is to use IETF standards to implement inter- domain architecture. More precisely, each QBone node is required to support Virtual Leased Line (VLL) emulation using Expedited Forwarding (EF). This service support mode is called QBone Premium Service (QPS), and will be described in Section 5.3.1. Network elements are required to support the configuration that makes VLL service possible. Inter-domain interworking for DiffServ in QBone paradigm can be implemented by SLAs and Service Level Specifications (SLSs), [...]... using an API with service quality descriptors, or with predefined service quality support classes as in the TIPHON model Additionally, the TCP /IP implementation of the operating system of the end user IP host must support the service quality support signalling between the IP host and the network The signalling scheme can be, for example, RSVP, SIP/SDP parameters for IP telephony, UMTS terrestrial RAN (UTRAN)... be described in Chapter 8 The ETSI EP TIPHON approach to end-to-end service quality for IP telephony was described in Section 5.2 Taking delay as an example, part of the end-to-end delay quota in TIPHON model is assigned for the terminal, and the remaining part is divided among the transport domains TIPHON’s deliverable [TIPHON-7] provides a planning guide for IP telephony In the same kind of analysis... the properties of the PDP context is traffic class, being one of the following four types: Application User IP layer Radio tunnelling RAB Link Terminal GTP Radio tunnelling ATM RAB Link Link Base transceiver station & radio network controller GTP ATM Link GTP IP Link User IP layer User IP layer GTP IP Link Link Serving GPRS support node Figure 5.4 Release 99 UMTS architecture protocol stacks Note: The... http://pda.etsi.org/pda/ and http://www.etsi.org/eds/ Source: From [TIPHON-7] of TCP, too Reflecting this fact, delay is listed as a separate QoS characteristic – in addition to the R-value given by the E model – in ETSI TIPHON’s end-to-end model Figure 5.8 shows the relation between speech quality and end-to-end delay used by TIPHON for IP telephony Various sources of delay were already discussed in Chapter... appear in multiple locations This is because in certain cases, especially with prioritized traffic aggregates, service instantiation control is one of the few control means available for traffic aggregates with strict service quality requirements Another control means for prioritized traffic is the use of multiple routes for a single service quality support aggregate This tool can be used when multiple routes... the curves for CBR VoIP and WWW browsing – for example – could look like the example in Figure 5.5 Utility for CBR VoIP deteriorates quickly below a critical bandwidth limit, whereas the utility for browsing in theory is a smoother function of the available bandwidth From the curve, one can immediately see that it is no use to provide a bandwidth below the “step” threshold for a VoIP stream The utility... in Figure 5.4 Note that radio access bearer and IP bearer provide service quality support for user layer traffic (end user IP flows) “from below”, whereas service quality interworking towards external Internet takes logically place on user layer 5.4.1 QoS model The interested reader can find a longer account of 3GPP QoS model in [KP01], only a short description being given here Network architecture for... or the internal implementation of the TCP /IP stack ETSI TIPHON handles the effect of communication endpoint with a classification of the terminals according to their effects on end-to-end service quality Second, shared-segment type LANs or other network links of the same nature can give rise to delay variations which are drastic in timescales relevant to VoIP when loading levels are high [RR00] 166... well as packet-switched (PS) data traffic The communication between a GPRS terminal and another IPaddressable device (another mobile terminal or an Internet server, for example) takes place using a Packet Data Protocol (PDP) context, having QoS parameters associated with it From the point of view of end user IP communication, GPRS Gateway Support Node (GGSN) at the edge is the access router used by the... information to determine which instances within each service class need to be supported, and whether user class differentiation would bring value Map VoIP into the highest forwarding priority class (EF) 3 Are network resources everywhere sufficient for VoIP transport in the highest class for the most direct route? If not, service instances mapped to the highest class can be redistributed among different . latter half of the 1990’s, ETSI founded the IP telephony project TIPHON, which has devised a reference models for IP telephony, in which service providers. Protocol (SIP), for example, to operate without having to build own transport networks. When a VoIP call is set up between the communicating parties, the IP telephony