Thực hiện chất lượng dịch vụ trong các mạng IP (P3)

3 Network Mechanisms for Multi-service Quality Support This chapter deals with service quality support mechanisms in the network. Of particular interest are mechanisms inside an Inter- net Protocol domain, including edge treatment and service qual- ity support mechanisms in the network core. Requirements for signalling between the endpoint and the network edge will be discussed in Chapter 5. The Internet today is based on the Best Effort (BE) service para- digm in which all IP traffic on a network link is treated alike, or in other words, no service quality support is provided when momentary traffic volume exceeds link capacity. Subsequently, to offer true multi-service support for critical traffic types such as VoIP in an IP-based network, the technical tasks to be carried out by an IP service provider seem challenging at first sight. Not only must mechanisms be provided for implementing the network sup- port for different service types, but also mechanisms are needed to map service requirements onto network resources. To make best use of network resources, the service mapping scheme may need to be revisited when resources or distribution of services change. The whole service quality support system should be manageable in a scalable way. Implementing Service Quality in IP Networks Vilho R ¨ ais ¨ anen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X 54 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT It turns out that implementation of multi-service quality support in an IP domain is possible and manageable. Moreover, this sup- port can be provided with a mechanism allowing the network element in the core of the network to be kept simple. Despite technical feasibility, multi-service support in IP network is not likely to be immediately adopted by all ISPs and other net- work operators. However, the ability to provide better-than-best effort service will become an important business proposition due to the progress of content digitalization to include also non-data type services. In implementating such support cost-efficiently, IP- based service quality support mechanisms are a viable alternative, as we shall see. In what follows, we shall discuss the basic multi- service quality support mechanisms and ways of implementing them with present-day technology in a cost-efficient way. Further, service level description mechanisms needed at the boundaries of operators’ domains are accounted for in this and subsequent chapters. In this chapter, we shall first briefly review issues relevant to network multi-service quality support, and discuss policing at the edge of the network and the effect of different protocol layers to service quality. Next, the generic ways of supporting service quality are reviewed, followed by a summary of service quality support means in ATM and IP. Routing control in IP networks and link layer service quality issues are discussed next, and the present chapter concludes with a summary. This chapter attempts to demonstrate that the building blocks for service quality support mostly exists already today without ATM. ATM-based service quality support is used as a point of reference in this chapter. Management of IP-based service quality will be discussed further in the next chapter, and the provision of network resources in Chapter 5. Routing control beyond the basic operation of IP routing protocols will be discussed in this chapter, and further in next chapter. 3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT The adoption of dedicated multi-service quality support mecha- nisms in the network is only necessary when the following two conditions are met: 3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT 55 1. Over-dimensioning of the network is not a feasible solution. 2. Providing of engineered service quality level for some service traffic types transported in the multi-service network such as low delay and/or packet loss rate is desirable. Above, over-dimensioning means designing the network in such a way that the network is at all times capable of transmitting the momentary traffic volumes so that the service quality require- ments of transported streams are satisfied. The latter condition amounts to delay requirement of all traffic being determined by the most delay-critical and loss-intolerant service type. An application example is in a corporate access network carry- ing Voice over IP, sharing the access network capacity with bursty HTTP traffic and Simple Mail Transfer Protocol (SMTP) traffic. It may not be economically feasible to dimension the network to handle the largest possible bandwidth bursts. This would neces- sitate providing the same delay to transport of HTTP and SMTP than VoIP. If over-provisioning is not a feasible alternative, either a sepa- rate capacity is provided for VoIP, or a prioritization mechanism needs to be built into the actual network transport to provide differentiated handling for distinct service quality classes. These main alternatives benefit from further support mechanisms, the most important of which are discussed below. Before that, how- ever, let us note that service quality support may be needed even with a single service quality type. An example of this could be providing pre-defined performance for browsing traffic. In such a case, a suitable subset of the service quality support machinery reviewed below could be used. Let us now discuss service quality support on a more general level. Discussing the bandwidth of a single link for concreteness, there are basically two alternatives to over-dimensioning in pro- viding service quality support in the presence of multiple service types: capacity reservation and differentiated treatment. Capac- ity reservation means that a part of the total capacity of a link is reserved solely for one or more traffic types. The remaining capac- ity can be used for implementing other reservations, or be shared by services on a best effort basis. Differentiated treatment, on the other hand, means not reserving any fixed capacity, but priori- tizing service types with respect to each other when momentary 56 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT 0 1 2 3 4 5 6 1 6 11 16 21 26 31 36 41 46 Capacity Differentiation Sum Reservation Non-urgent traffic Urgent traffic Time Figure 3.1 The benefits of prioritization Note : Unit in the vertical axis is the maximum required capacity of urgent traffic offered traffic exceeds link capacity. In the prioritization approach, less traffic can be displaced in time to make room for momentary variations in the volume of more urgent traffic. Let us next compare the over-dimensioning approach against capacity reservation and differentiated treatment using a case study. Figure 3.1 below shows a case in which the average volume of non-urgent traffic is fivefold as compared to the volume of urgent traffic. Over-dimensioning according to the peak value would require capacity C of 6 units. Capacity reservation for urgent traffic would mean putting aside 1 unit of capacity, and dimensioning separate capacity according to the average volume of non-urgent traffic, leading to total capacity requirement C of 1 + 2.5 = 3.5 units. Finally, implementing prioritization mechanism in the network leads to dimensioning being based on the average volume of all traffic, i.e., approximately capacity of 3 units. In this case, differentiation based on urgency brings capacity-saving benefits of 50% compared to over-dimensioning, and more than 14% based on capacity reservation for non-urgent traffic. This requires that non-urgent traffic can be delayed. The above simple calculation was based on a “fluid flow” approximation, not taking into account discreteness of data. An exact analysis of the process requires application of queueing theory, potentially yielding corrections to the simple case when the size of largest packets is not insignificant with respect to total link capacity. The fact that packet length can vary gives rise to variation in the service time of a packet, causing variable amount of delay to the subsequent packets. 3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT 57 A further advantage of multiplexing is that the relative burst- iness of a traffic aggregates is considered to decrease with the num- ber of flows, reducing the effects due to fractal traffic phenomena, for example [CCL + 02]. As will be discussed in Section 3.2, engi- neering of network for bursty flows benefits from edge mecha- nisms. In general, the saving calculation figures will depend on the percentage of traffic types, which need priority treatment. If all of the traffic needs priority treatment and is delay-sensitive, over- dimensioning is the only alternative. As mentioned above, appli- cation of some service quality control means may be beneficial also in this case from the point of view of end user experienced qual- ity. At the other end of the spectrum, when priority traffic with variable bandwidth is sharing the link with bursty non-urgent traffic and the maximum volume of priority traffic is less than half of the link capacity, savings can be considerable. In what fol- lows, it is assumed that when service quality support is feasible, purely prioritization-based service quality support scheme is used to maximize utilization of installed capacity. The dimensioning of capacity reservations is a well-established discipline, and more information about that can be found in [McD00], for example. The above analysis calls our attention to the following important issues in considering the usefulness of differentiated treatment in the network: • Are savings from implementation of differentiated treatment high enough? Implementing support for differentiated treatment in the network makes the elements more complex and poses requirements for management system. • Can differences in service delivery time requirements be leveraged to implement differentiation? If the delay requirements of traffic aggregates are too close to each other, delay differentiation may not be practical. • Are relative volume shares of services known? Traffic volumes need to be known or limits need to be imposed to maintain per-node differentiation. It should be noted that relative volumes need to be computable in all routers which implement prioritization. • Are absolute volumes of traffic aggregates predictable? Even with differentiation, range of variation of different traffic types needs to be known. 58 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT Mathematically, feasibility of prioritization-based multiplexing in a multi-service network is determined by whether service require- ment specification for a service allows for service instantiations of that type to be displaced in time, or their total throughput limited. Some analysis techniques for this will be discussed in Chapter 5. What has been discussed above are de facto preconditions for using differentiation. More generally, the reasons for choosing prioritization-based mechanisms over other alternatives may not be related solely to the mathematics of dimensioning. The multi- service multiplexing paradigm based on service differentiation in the network has the following benefits according to Kilkki [Kil99]: • fairness; • robustness; • versatility; • cost efficiency. A detailed analysis of these factors is beyond the scope of this book, and the interested reader is referred to Kilkki’s book. Suffice it to say here by way of an example that fairness can be thought to relate to the end user’s perception of the value for the price the user has paid for the service, taking into account other users’ investments into same service. Robustness refers to the sensitivity of service quality support mechanism towards actions of malev- olent users, and versatility relates to the selection of tools at the network provider’s disposal in providing service quality support for a multiplicity of needs. Cost efficiency is a measure of the required monetary investment for implementing the service qual- ity goals. A related topic, we shall discuss utility-based service allocation in Chapter 5. 3.2 POLICING OF TRAFFIC AT INGRESS To put the service quality management methods presented later in a general context, the reference model shown in Figure 3.2 is used for this chapter. On the network side, a service instantiation can be thought of as being conceptually associated with a ser- vice quality support instance. The service quality support instance defines the quality support provided to the service instance by the network domain. 3.2 POLICING OF TRAFFIC AT INGRESS 59 Network NE NE NE NE NE Client Client or server Service instance Quality requirements: - xxx - yyy NE Figure 3.2 Reference model for this section Note : A service instance is invoked between two hosts, routed through a number of network elements (NE) and having a set of quality requirements Capacity Time NBR PBR Figure 3.3 An illustration of NBR and PBR Further, it is assumed that a NBR and a Peak Bit Rate (PBR) can be defined for service events, for example by using TSpec-type traffic descriptor. The significance of these characteristics is that a service instance needs capacity of NBR to function properly, and may at times benefit from a capacity of PBR (see Figure 3.3). Fur- ther, a Maximum Burst Size (MBS) is assumed to be known, spec- ifying the maximum allowed amount of data in a burst. A burst here means a period during which the momentary bit rate exceeds MBR. In ATM, Sustainable Cell Rate (SCR) roughly corresponds to NBR and Peak Cell Rate (PCR) to PBR. The flow descriptor param- eters are assumed to be specified as a part of a SLA between the client and the network operator, more or less explicitly. For networks with appropriate function in place, the confor- mance of service instance to a traffic descriptor – for example, the triplet (NBR, PBR, MBS) – can be verified and imposed by policing the service flows at network ingress point. Performing policing at 60 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT ingress is beneficial, as accumulation of burstiness in the network is best prevented by applying the “traffic contract” between oper- ator and end user as soon as possible. The traffic contract can be considered to be a form of a SLA. If ignored, accumulation of burstiness would make service quality support management in network core difficult. Performing policing at the network edge instead of network core elements is useful due to traffic volumes being smaller at the network edge than in network core and sub- sequently less processing is needed. Depending on service types, traffic conditioning can be of help in all service quality support mechanism scenarios described above. Specifically, applying traf- fic conditioning to non-urgent traffic in the scenario of Figure 3.1 reduces the need for maximum bandwidth in over-provisioning scenario. This is also true when there is only non-urgent traffic in the network. Also in a differentiation-based scenario, traffic condi- tioning is useful through a smoothing effect in the core network. The SLA, in general, can be defined per service event type, or by having parts addressing different service event types. The applica- ble service type is assumed to be detected either based on signalled state, or on protocol data such as IP address and/or port number. When signalled instalment of policing is used, for example, RSVP can be used for that purpose. Protocol data filter can be a fixed one, or vary with operator-defined conditions. A single service instance consisting of service events of different types may map to multi- ple SLA service type components. For example, a teleconferencing service instance could include VoIP service event type with strin- gent service quality, and a data application sharing service event type with different SLA service quality profile. A practical device for verifying conformance to SLA is typically either leaky bucket or token bucket regulator controlling regulator function. The conformance check can be assumed to be of leaky bucket type for ATM and token bucket for IP traffic. After confor- mance of a flow or aggregate to traffic descriptor has been checked, a controlling means is usually applied for limiting out-of-profile burstiness of traffic at network ingress. In ATM parlance, policing is typically an operation applied in the User-Network Interface (UNI), or upon user flows entering the network. It is also possi- ble that the user performs policing prior to sending traffic to the network. In addition to being better able to control the quality of one’s own services, policing one’s own outgoing traffic allows the user to better understand the properties of one’s own traffic. 3.3 ABOUT LAYERS 61 In general, the following actions can be applied to out-of-profile traffic: • Traffic shaping. Burstiness is smoothened out by buffering out- of-profile traffic. Due to finite buffer size or maximum allowable delay per network element, traffic shaping may need to be com- bined with the following method. • Discard out-of-profile traffic. • Assign out-of-profile traffic to a lower treatment class.Thismethod allows the out-of-profile traffic to utilize unused capacity in the network. • Do nothing. Statistics of out-of-profile traffic volumes may still be recorded. Means of configuring policing will be discussed in the next chap- ter. The importance of conditioning will be referred to later in the context of end-to-end service quality dimensioning in Chapter 5. Here, suffice it to say that conditioning at the network edge alle- viates the possibility of worst-case effects of slow convergence to Gaussian (well-behaved) aggregates with the number of flows in the network core [NZA99]. Such problems may arise due to bursty end-user traffic flows, technically described as being fractal or hav- ing long-range correlations. A classic example of this is fractality in Ethernet-based LAN [LTW + 94]. With increasing flow aggregation level, the arrival process on a link tends towards Poisson process, and the adverse effects of burstiness are reduced [CCL + 02]. 3.3 ABOUT LAYERS The ISO/OSI reference model enumerates no less than seven lay- ers of interconnectivity. The lowest three or four of these layers are often referred to in practical engineering. A well-known generic property of layered reference models, fitting of real-world pro- tocols neatly exactly within one OSI protocol layer is often prob- lematic. TCP and UDP can be accommodated relatively nicely into Transport Layer (layer four) of OSI model, but ATM and MPLS are both partly layer 2 and partly layer 3. This is because they include routing functions like layer 3 protocols, but are still “link layer” protocols from the viewpoint of IP applications. For the purposes of concreteness, the four lowest layers of OSI reference models are 62 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT 802.3 IP AT M AAL MPLS AAL IP UDPTCP Link layer Physical layer Network layer Transport layer Figure 3.4 An illustration of mismatch of protocols with respect to ISO/OSI protocol reference model using example protocol stacks nevertheless often used. Figure 3.4 shows examples of approxi- mate relations of often-used Internet protocol stacks with respect to ISO/OSI model. The link layer also includes the Medium Access Control (MAC) layer in Figure 3.4. The protocols used in the layered structure can be of importance to service quality support in IP networks, depending on what kind of service quality support there is on each layer. The significance of TCP and UDP for service quality has been discussed in the previ- ous chapter, being an issue the endpoint application can partially affect by choosing either TCP or UDP when instantiating a service. On the network side, the overall service quality support capabil- ity is affected also by link layer service quality support and the physical set-up of the network, for example. These issues will be elaborated in Section 3.8 and in Chapter 5. An issue of practical importance is the amount of configura- tion and operations support required on different network layers. Performing service quality support configuration on as few net- work layers as possible and in as automated a way as possible is perceivedtobeanimportantgoal.Suchanapproachcanbring considerable benefits to the network operator, in the form of low- ered operability costs, and also to the end user, in the form of increased network reliability. This is one of the drivers in studying light protocol stacks such as IP/MPLS over WDM. 3.4 TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY The ITU-T draft recommendation [Y.1541] lists the network service quality support mechanisms for different QoS classes in Table 3.1. [...]... a necessity for managing the IPv4 address spaces in individual network domains Due to NATs and uneven geopolitical allocation of IPv4 address space, the IPv4 address space is not optimally coupled to the anticipated number of IPv4 addresses in different parts of the world It is expected that the need for IP addresses in emerging markets such as Asia will make the use of IPv4/NAT combination impossible... allocation according to geography The delivery IPv6 packets require IPv6-capable routers using routing protocols, which can handle IPv6 It is obvious that the whole Internet will not be upgraded into IPv6 overnight Subsequently, IPv4/IPv6 transition strategies have been developed within the Next Generation Transition (NGTRANS) working group of IETF The transition to IPv6 is an issue, the details of which are... working on transition mechanisms such as routers with dual IP stacks, IP- in -IP tunnelling, and Network Address Translator/Protocol Translator (NAT-PT) Further details can be found in [NGTRANS] IPv6 also opens up new scenarios that have not been possible with IPv4 These will be briefly mentioned in Chapter 11 3.7.2 IP routing protocol-based methods IP routing uses shortest path routing between source and... increased dramatically The IP address shortage is not limited to emerging markets only: the problem will be made worse by the ever-increasing number of IP- addressable devices My GPRS phone has an IP address – what will happen when there are hundreds of millions or billions of such devices in use? An evolution version of IPv4, IPv6 has a larger address space, but is not yet widely deployed IPv6-based research... directly to IP is possible Accessing of raw sockets is typically limited to system administrators, and the programs of normal users can only open multiplexed L4 sockets This is the case in Linux, for example IPv6 brings with it the possibility of identifying a flow using the flow label field in the IPv6 header [RFC2460] According to the latest proposal, an IPv6 flow is uniquely identified by the triplet (source... differentiation Depends on service model 3.6 SERVICE SUPPORT MODELS IN INTERNET PROTOCOL With in reference to OSI model, IP operates on layer 3, providing per-packet routing for PDUs – IP packets – based on IP destination address Two versions of IP exist, IPv4 having 32-bit address fields and IPv6 having 128-bit address fields Application typically interfaces to Internet Protocol on “layer 4” using the abstraction... Mobile IPv6 working group under Internet area standardizes mobility-optimized version of IPv6 (Mobile IPv6) that can be used with a permanent infrastructure but with mobile hosts Mobile IPv6 traffic can be routed in the permanent network using the same routing protocols as normal IPv6 traffic 3.7.3 ATM overlays Due to common deployment of ATM in backbone networks, the solution to transporting IP over... in IPv4 and IPv6 is the Berkeley System Distribution (BSD) socket interface, providing communication services through a data structure reminiscent of a UNIX file 72 NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT descriptor [St98] Blocking, non-blocking, and signal-based communication through the socket interface are possible In addition to setting the DiffServ Code Point (DSCP) in IPv4 and IPv6... by marking of the corresponding DiffServ Code Point (DSCP) into a six-bit field in IP packet header called the DS field DS field is present in both IPv4 and in IPv6 headers, superseding the previously reserved IP header field of Type-of-Service (TOS) octet and Traffic Class octet, respectively [RFC2475] The structure of the IPv6 header and the embedded DS field is shown by way of an example in Figure 3.5... network 6Bone has been operating for many years now, and IPv6 has also been 3.7 ROUTING IN IP NETWORKS 87 taken into production use in Japan The European Union has expressed support for IPv6, the consequences of the statement to be seen IPv6 is supported in 3GPP mobile networks (GPRS and UMTS), being one of the first large-scale networks with IPv6 capability From a routing point of view, the larger . model, IP operates on layer 3, providing per-packet routing for PDUs – IP packets – based on IP destina- tion address. Two versions of IP exist, IPv4 having. services. Suitable for transport- ing TCP /IP. Thus, IP- based services can interface to ATM using suitable AALs, or can use TCP /IP over AAL5. The latter has been