CHETTINAD COLLEGE OF ENGINEERING & TECHNOLOGY

Transcription

1 CHETTINAD COLLEGE OF ENGINEERING & TECHNOLOGY DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING Subject Name: High Speed Networks Faculty Name: D.Devilatha Year/Sem: IV/VII Regulation: 2008 UNIT IV QUALITY OF SERVICE AND TRAFFIC ENGINEERING Quality of Service- Traffic Parameters and Conformance Definitions- Classes of Service- Achieving Conformance- Checking Conformance- Ensuring conformance-delivering QoS- Congestion Control and Management- CONTENTS 4.1 QUALITY OF SERVICE (QOS) 4.2 REFERENCE MODELS Generic Allocation of Impairments Model ATM Equivalent Terminal Model Diffserv Per-Hop and Per-Domain Behavior Models 4.3 QUALITY OF SERVICE Application QoS Requirements ATM QoS Parameters IP Performance Metrics (IPPM) 4.4 TRAFFIC PARAMETERS AND CONFORMANCE DEFINITIONS ATM Traffic Descriptor IP Traffic Descriptor ATM Conformance Definitions IP Traffic Conformance Definitions 4.5 CLASSES OF SERVICE ATM Forum QoS Classes and Service Categories ITU-T ATM QoS Classes Mapping Between ATM Forum and ITU-T QoS definitions Diffserv Per-Hop Behaviors (PHBs)

2 4.5.5 MPLS Support for Diffserv 4.6 COMPARISON OF ATM AND IP QOS AND 4.7 ATM SERVICE CATEGORIES OPTIMIZED FOR Switch Modifications to Support GFR UBR with BSC and MDCR Use of Differentiated UBR to Support Diffserv U se of Differentiated UBR to Support IEEE 802.x UBR Service Category with Optional MDCR Parameter 4.8 CHECKING CONFORMANCE: 4.9 ENSURING CONFORMANCE: SHAPING 4.10 DELIVERING QoS: PRIORITIZATION,QUEUING, AND SCHEDULING: 4.11 CONGESTION CONTROL: A RANGE OF SOLUTIONS CATEGORIZATION OF CONGESTION CONTROL 4.12 CONGESTION MANAGEMENT CONGESTION AVOIDANCE CLOSED-LOOP FLOW CONTROL TECHNICAL TERMS 1.ABR Compliance / Conformance ABR (Available Bit Rate ) conformance or compliance refers to the behavior specified for ATM Available Bit Rate (ABR) destination and switches, but allows for delays between the source and the UNI (Unser to Network Interface), which may perturb the traffic flow. 2.ABC Compliance / Conformance ABR connection conformance or compliance refers to the behavior specified for ATM Available Bit Rate (ABR) destination and switches, but allows for delays between the source and the UNI [UNI3.1, UNI4.0], which may perturb the traffic flow. 3.ABR: Available Bit Rate Available Bit Rate (ABR) is a type of service or a QOS class defined by the ATM Forum for ATM networks.

3 4.ACR: Allowed Cell Rate Allowed Cell Rate (ACR) is an ABR service parameter, defined by the ATM Forum for ATM traffic management. 5.CAC: Connection Admission Control Connection Admission Control (CAC), also known as Call Admission Control, refers to the set of actions taken by the network during the call set-up phase (or during call re-negotiation phase) in order to determine whether a connection request can be accepted or should be rejected. 6.CDV: Cell Delay Variation Cell Delay Variation (CDV), also referred to as cell jitter, is the variation of cell transfer delay in an ATM network, the variation in cell delay through the network. 7.CDVT: Cell Delay Variation Tolerance Cell Delay Variation Tolerance (CDVT) is a QoS parameter in ATM network for managing traffic that is specified when a connection is set up. 8.Cell Payload Scrambling Cell Payload Scrambling is a technique using an ATM switch to maintain framing on some medium-speed edge and trunk interfaces. 9.CER: Cell Error Ratio Cell Error Ratio (CER), a term in the ATM network, is the ratio of transmitted cells that have errors to the total cells sent in a transmission for a specific period of time. 10.Congestion Congestion refers to the situation that the traffic in the network or part of the network is in excess of network capacity. When congestion happens, transmission will slow down and some packets may get dropped.

4 11.Congestion Avoidance Congestion Avoidance is a mechanism by which an ATM network controls the traffic entering the network to minimize delays. To use resources most efficiently, lower-priority traffic is discarded at the edge of the network if conditions indicate that it cannot be delivered. 12.Congestion Collapse Congestion Collapse refers to the condition in which the retransmission of frames in an ATM network results in little or no traffic successfully arriving at the destination. 13.CRF: Cell Relay Function Cell Relay Function (CRF) is the basic function that an ATM network performs in order to provide a cell relay service to ATM end-stations. 14.HEC: Header Error Control Header Error Control (HEC) is algorithm for checking and correcting an error in an ATM cell using the fifth octet in the ATM cell header. 15.Jitter In data networking, jitter is a measure of the variability over time of the latency across a network. 16.QoS: Quality of Service Quality of Service (QoS) refers to the ability of a network to provide higher priority services, including dedicated bandwidth, controlled jitter and latency (required by some real-time and interactive traffic), and improved loss characteristics, to selected network traffic over various WAN, LAN and MAN technologies. At the same time, making sure that providing priority for one class of traffic does not make other flows fail. QoS refers to a broad collection of networking technologies and techniques.

5 17.TC: Transmission Convergence Transmission Convergence(TC) is a sublayer of the ATM physical layer that transforms the flow of cells into a steady flow of bits for transmission over the physical medium. 18.TM: Traffic Management Traffic management includes subjects such as network bandwidth control and allocation, communication delay reduction and congestion minimization. 19.Traffic Policing Traffic Policing, used in ATM, Frame Relay, and other types of networks, is a process used to measure the actual traffic flow across a given connection and compare it to the total admissible traffic flow for that connection. 20.VBR: Variable Bit Rate Variable Bit Rate (VBR) is a QoS class defined by the ATM Forum for ATM networks. 4.1 QUALITY OF SERVICE (QOS) INTRODUCTION Quality of Service- Traffic Parameters and Conformance Definitions- Classes of Service- Achieving Conformance- Checking Conformance- Ensuring Conformance- Delivering QoS- Congestion Control and Management. This chapter explains about the formal concept of a traffic contract from ITU-T Recommendation I.371 and the ATM Forum version 4.1 traffic management specifications. It then generalizes this notion to that used in IP and MPLS networks. The philosophy and paradigms are defined by a specific set of terminology engineering to deliver QoS to a welldefined set of cells or packets (e.g., a class or flow) at a traffic level defined by a set of traffic parameters. Next, it explains the concept of QoS and details the ATM and IP networking standards designed to support QoS. Technical terms: Quality of Service (QoS), traffic parameters, and conformance checking.

6 THE TRAFFIC CONTRACT Within the ATM paradigm, a network establishes a separate traffic contract with the user of each ATM virtual path connection (VPC) or virtual channel connection (VCC). This traffic contract is an agreement between a user and a network at a specific user-network interface (UNI) regarding the following interrelated aspects of any VPC or VCC ATM cell flow: A set of QoS parameters for each direction of the connection A set of traffic parameters that specify characteristics of the cell flow The conformance-checking rule used to interpret the traffic parameters The network s definition of a compliant connection The definition of a compliant connection allows an ATM network some latitude in the realization of checking conformance of the user s cell flow. Unquestionably, a connection that conforms precisely to the traffic parameters is compliant. A network may treat a connection with some degree of nonconformance as compliant; however, this definition is up to the network. In this case, the QoS guarantee applies to only the conforming cells. Finally, the network need not guarantee QoS to noncompliant connections, even the conforming cells. The counterpart for the traffic contract in IP-QoS is the traffic profile. RFC 2475 defines this as A description of the temporal properties of a flow, such as a token bucket defined by a rate and a burst Size. The concept of a traffic contract also applies to an internal trunk connection that could be either ATM or MPLS. In this case, the parties of the contract are both in the network, but the user is a device that requires capacity between certain points while the network are the devices that provide the trunk connections. The generalized notion here is that the network delivers a certain level of quality for the trunk connection traffic that is less than or equal to a specified quantity. The next sections of this chapter define the reference configuration for the traffic contract, Quality of Service (QoS) parameters, traffic parameters, and the conformance checking requirements using either a leaky or token bucket. Next Chapter describes the details of the leaky and token bucket algorithms. 4.2 REFERENCE MODELS This section provides several ATM and MPLS reference models used in the standards to define a framework within which further details can be specified.

7 4.2.1 Generic Allocation of Impairments Model QoS on an end-to-end basis is the perspective most relevant to an end user. However, an end-to-end QoS reference model usually contains one or more intervening networks, each potentially with multiple nodes, as depicted in Figure 4-1. Each of these intervening networks may introduce delay, loss, or errors due to multiplexing and switching, thereby impacting QoS. Furthermore, statistical variations in the offered traffic may result in loss or excessive delay within congested network nodes. Of course, a network can also implement shaping between nodes, or between networks, to minimize the accumulation of delay variation and loss. In principle, the user should not need to know the details about the intervening networks and their characteristics, as long as the connection delivers the end-to-end QoS for traffic that conforms to the parameters of the traffic contract. As described later in this chapter, ITU-T Recommendation I.356 takes the approach of defining a worst-case concatenation of networks and devices for specifying QoS. In an analogous manner, the IETF Diffserv model defines the aspects of node and network QoS. Therefore, as long as connections across networks stay within these bounds, users experience a consistent level of QoS performance ATM Equivalent Terminal Model The basis of the ATM traffic contract is a reference configuration, which the standards call an equivalent terminal. Figure 4-2 illustrates the components and terminology of this reference configuration. Figure 4.1 END TO END QOS REFERENCE MODEL An equivalent terminal need not be a real device and indeed may be a collection of devices, such as an ATM workgroup, or an ATM-capable router, bridge, or hub. Inside the equivalent terminal, a number of traffic sources at the ATM layer for example, applications

8 running on a workstation with an ATM NIC generate cells as ATM protocol data unit (PDU) transmit requests to a specific VPC or VCC connection endpoint. The ATM layer inside the terminal multiplexes these sources together, for example using a switching backplane or fabric in a local ATM switch, router, or hub. Associated with the multiplexing function is a virtual traffic shaper that spaces out the cells from each connection to ensure that the cell stream emitted to the physical layer service access point (PHYSAP) conforms to the set of traffic parameters defined in the traffic contract with the network. After the shaper function, other functions within the terminal equipment (TE) may create variations in the spacing of cells actually transmitted over a physical private ATM UNI interface such that it no longer conforms to the traffic parameters. Standards call the change in cell spacing from that originally transmitted cell delay variation (CDV), a concept detailed in the next section. This ATM cell stream may then traverse other ATM devices in the private network, such as a collapsed ATM backbone, before arriving at the public ATMUNI, potentially accumulating even more CDV. Figure 4.2 EQUIVALENT TERMINAL REFERENCE MODEL The tolerance for this accumulated CDV in the traffic parameters, called cell delay variation tolerance (CDVT).Although these terms are similar, they mean different things: CDV specifies a variation in cell delay arrival times, while CDVT specifies a slack parameter for the peak

9 intercell spacing when the network polices the user s cell stream. These terms are frequently confused, so remember that CDV is a QoS parameter and CDVT is a traffic parameter Diffserv Per-Hop and Per-Domain Behavior Models The Differentiated Services (usually abbreviated as Diffserv) architecture defined in RFC 2475 defines some significant characteristics of packet transmission in one direction across a set of one or more nodes within a network. Therefore, Diffserv is inherently asymmetric. Characteristics can be statistically defined by throughput, delay, delay variation, as well as measures of loss, and of relative priority. The approach taken for Diffserv involves a component involved with forwarding data that is separate from that employed from control components, such as routing, policy administration, and configuration. As we saw in Part 2, many other protocols use this type of architecture that separates the data and control components, such as routing and signaling. The Diffserv (also abbreviated DS) architecture defines a unique set of terminology, illustrated in Figure 4-3.ADS-compliant node utilizes the Diffserv code point (DSCP), the Figure 4.3 DIFFSERV TERMINOLOGY AND REFERENCE MODEL first six bits of the Type of Service (TOS) byte in the IPv4 header or the traffic class byte in the IPv6 packet header (see Chapter 8 and RFC 2474), to determine which externally observable per-hop behaviors (PHBs) to apply to a packet. A DS domain is a set of contiguous nodes that

10 implement a common set of PHBs, provisioned in a common manner to deliver a per-domain behavior (PDB) [RFC 3086]. A DS region is a set of contiguous DS domains that offer differentiated services. A DS boundary node connects via a DS boundarylink to another DS domain or a non-ds-capable domain. With reference to a particular traffic flow, as shown in Figure 20-3, the DS domain that sends the flow is said to be upstream, while the DS domain that receives the flow is said to be downstream. The upstream DS domain boundary node that transmits traffic is called a DS egress node, while the downstream DS domain boundary node that receives traffic is called a DS ingress node. Typically, ingress, interior, and egress DS nodes perform different functions. These functions include a small set of forwarding per-hop behaviors (PHBs), packet classification, and traffic conditioning functions including metering, marking, shaping, and policing, which the next chapter describes. In fact, a fundamental tenet of the Diffserv architecture is that scalability is achieved by implementing complex multifield classification and traffic conditioning functions at the edge, and then applying the appropriate PHBs within the core solely on the basis of the Diffserv field. We now summarize some other Diffserv-specific terminology from RFC ADS behavior aggregate (BA) is a collection of packets with the same DSCP value crossing a link in a particular direction. A per-hop-behavior (PHB) is the externally observable forwarding behavior applied at a DS-compliant network device to a DS behavior aggregate. At the time of this writing, the IETF had defined 22 PHBs: 1 for expedited forwarding [RFC 2598]; 12 for assured forwarding composed as four classes, each with three drop precedence values [RFC 2597]; 8 that operate on a class selector [RFC 2474]; and one default or best effort [RFC 2474]. We describe the characteristics and DSCP code points for these PHBs later in this chapter. A PHB group is a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, for example, the drop priorities of the AF PHB. A per-domain behavior (PDB) is the expected treatment that an identifiable or target group of packets will receive from one edge to another of a DS domain [RFC 3086].Aparticular PHB (or, possibly, a set of PHBs) and traffic conditioning requirements are associated with each PDB. No PDBs have yet been standardized, but several have been proposed. These include an assured rate PDB based upon the AF PHB, as well as a virtual wire PDB based upon the EF PHB

11 that strives to replace dedicated circuits, and a bulkhandling PDB that is effectively a less than best effort class of service. An important distinction between the ATM reference model and the IP Diffserv architecture is that the ATM model strives to assign numerical values to QoS parameters, while, at the time of this writing, the objective of Diffserv is only to provide differentiated performance. Nonetheless, an IP service provider could assign numerical IP performance parameters to a DS domain, and the performance of a concatenation of such domains may be meaningful. At the time of this writing, the ITU had begun an attempt to quantify IP QoS along these lines, with the results planned for Recommendation Y QUALITY OF SERVICE What is Quality of Service (QoS)? Many definitions exist in the industry, and the concept continues to be refined in the Internet standards. SinceATMprecisely defines QoS, we focus primarily on this definition, introducing analogous concepts from IP standards along the way so that the reader can compare and contrast. ATM terminology defines QoS as the performance observed by an end user. For both ATM and IP, the principal QoS parameters are delay, delay variation, and loss. Since applications operate well only within certain performance limits, we begin with this generic view before detailing specific standards. The ATM Forum s traffic management 4.1 specification and ITU-T Recommendation I.356 define specific Quality of Service (QoS) performance parameters for cells conforming to the parameters of the traffic contract. The IETF has defined a set of IP performance metrics (IPPM) described later in this chapter that define precise means for measuring delay, delay variation, and loss in either a one-way or round-trip context Application QoS Requirements Before we take a detailed look at QoS performance parameters and metrics, it is important to recognize that selecting precise values for QoS parameters like loss, delay, and delay variation is not an easy task. Part of the difficulty arises from the subjective nature ofperceived quality [McDysan 00]. The approach employed by both ATM and IP is to group together applications with similar QoS requirements into classes, or service categories, with the appropriate QoS parameters. Figure 20-4 [Woodruff 90, Dziong 97, Onvural 97] illustrates several examples of application-level QoS requirements for the loss and delay variation QoS parameters. These are the principal parameters of interest to the majority of applications. The other major distinction is

12 that a real-time application requires delay bounded by the propagation speed of light over the transmission medium. The bubbles in this chart show a set of ranges that the indicated applications may be able to use. As described later in this chapter, ATM protocols allow applications to specify QoS in two ways: through the generic service categories (e.g., CBR and nrt-vbr) or through explicit enumeration of the QoS parameters in signaling messages. RSVP defines a means to request and confirm specific bounds on delay and delay variation for the guaranteed QoS integrated service, while the controlled load service implies a low level of loss, but no bounds on delay or delay variation. The current Internet standards assume that loss is always low for applications given preferred levels of quality. Indeed, RFC 1633 characterizes applications as real time (e.g., voice), predictive (e.g., broadcast video), or elastic (e.g., file transfer), depending upon the ability to handle variations in delay. Characteristics of the human body s nervous system and sensory perceptions drive many QoS requirements for delay, loss, and delay variation for voice and video applications. The blink of an eye is approximately one-fiftieth of a second, or 20 ms. Video broadcastand recording systems utilize frame rates of between 25 and 30 video frames per second. When frames are played back at this rate, in conjunction with the image persistence provided by television displays, the human eye-brain perceives this as continuous motion. When lost or errored cells disrupt a few frames in succession, the human

13 Figure:4.4 Example of Application specific QoS Requirement eye-brain detects the discontinuities in motion, which are subjectively objectionable. Video application requirements depend upon several factors, including the video coding algorithm, the degree of motion required in the image sequence, and the resolution required in the image. Combined video and audio is quite sensitive to differential delays.human perception is highly attuned to the correct correlation of audio and video, as isreadily apparent in some foreign-language dubbed films. On the other hand, broadcast video can tolerate much longer delays, since a largeplayback buffer compensates for variations in delay. However, the loss rate must besmall, since lost or distorted frames degrade playback quality. One way to compensate for loss is via error correction using AAL1, as described in Chapter 12.Agood benchmark for broadcast video transmission is the quality of cable television transmission systems. The human ear is also sensitive to such differences in delay on a similar time scale. This shows up in telephony, where the reception of a speaker s echo becomes objectionable within less than the blink of an eye; indeed, 50 ms is the round-trip delay where standardsrequire echo cancellation. Delay variation also affects the perception of audio and video. Audio is the most sensitive, since the human ear perceives even small delay variations aschanges in pitch. The human ear-brain combination is less sensitive to short dropouts in received speech, being able to accept loss rates on the order of a percent or so. Many data protocols respond to delay and loss through retransmission strategies to provide guaranteed delivery. One example is the transmission control protocol (TCP), which is widely used to flow control the transfer of World Wide Web text, image, sound, and video files. Data applications are extremely sensitive to loss because they respond by retransmitting information. A user perceives this as increased delay if, for example, retransmissions due to loss extend the time required to transfer large files carrying video or audio images. Since most data networks exhibit significant delay variation (especially over the Internet), applications insert a substantial delay before starting playback. This technique works fine for one-way communication but impedes two-way, interactive communication if the round-trip delay exceeds 300 ms. Satellite communications for a voice conversation illustrates the problem with long delays: since the listener can t tell whether the speaker has stopped or merely paused, and

14 simultaneous conversation frequently occurs. Most data communication protocols remain relatively insensitive to delay variations, unless the delay varies by values on the order of a large fraction of a second, which causes a retransmission time-out. Distributed computing and database applications are also sensitive to absolute delay loss, and variations in delay. The ideal for these types of applications is access to infinite capacity,together with delay near the speed of light in fiber. A more practical performance model is one comparable to a locally attached disk drive, or CD-ROM, with access times ranging from 10 to 100 ms. In other words, the goal of high-performance networking is to make the remote resource appear is if it were locally attached to the user s workstation ATM QoS Parameters This section details the ATM QoS parameters defined in references ATM Forum TM 4.1 and ITU-T I.356. Delay and Cell Delay Variation (CDV) Defined Two key components of ATM QoS are the cell transfer delay (CTD) and cell delay variation(cdv). Various components within ATM devices contribute to the statistics of delay within an ATM network, as illustrated in Figure 4-5. In general, fixed and variable delays occur on the sending and receiving sides of the end terminal, in intermediate ATM nodes, as well as on the transmission links connecting ATM nodes. Note that the internal structure of an ATM node need not be identical. Figure:4.5 ILLUSTRATION OF SOURCES OF DELAY The detailed delay components indicated in Figure 20-5 are T1 = Coding and decoding delay: T11 = Coding delay T12 = Decoding delay T2 = Segmentation and reassembly delay:

15 T21 = Sending-side AAL segmentation delay T22 = Receiving-side AAL reassembly/smoothing delay T3 = Cell transfer delay (end-to-end): T31 = Inter-ATM node transmission propagation delay T32 = Total ATM node processing delay (queuing, switching, routing, and so on.) The principal statistical fluctuations in delay occur due to the random component of queuing embodied in the T32 variable. Other terms contribute to a fixed delay, such as the terminal coding/decoding delays T11 and T12, along with the propagation delay T31. The interaction of the sources of random and fixed delay depicted in Figure 4-5 result in a probabilistic representation of the likelihood that a particular cell experiences a specific delay. Mathematicians call such a plot a probability density function. Figure 4-6 shows this generic function and also indicates the particular ATM Forum QoS parameters for delay and delay variation. Of course, no cells arrive sooner than the fixed delay component, but cells arriving after the peak-to-peak cell delay variation (peak-to-peak CDV) interval are considered late. The user may discard cells received later than this interval; hence, the cell loss ratio (CLR) QoS parameter bounds this area under the probability density curve. The maximum cell transfer delay (maxctd) is the sum of the fixed delay and peak-to-peak CDV delay components as indicated at the bottom of the figure. Figure 4.6 ILLUSTRATION OF SOURCES OF DELAY Recommendation I.356 and ATM Forum TM 4.1 cover details on computing CDV and its interpretation. Cell clumping is of concern because if too many cells arrive too closely together, then cell buffers may overflow. Cell dispersion occurs if the network creates toogreat of a gap between cells, in which case the playback buffer would underrun.

16 ATM Cell Transfer Outcomes Standards define ATM QoS on an end-to-end basis. An end user may be a workstation, a customer premises network, a private ATM UNI, or a public ATM UNI. The following cell transfer outcomes define the various QoS parameters: A transmitted cell by the originating user enters the network. A successfully transferred cell is delivered by the network to the destination user. Figure 4.7 TRANSFER DELAY PROBABILITY DENSITY MODEL A lost cell does not reach the destination user. An errored cell arrives at the destination but has errors in the payload. A misinserted cell arrives at the destination, but was not sent by the originator. This can occur due to an undetected cell header error or a configuration error. A severely errored cell block occurs when M or more lost, errored, or misinserted cells occur within a received block of N cells. ATM QoS Parameter Definitions Table 20-1 lists the ATM layer QoS parameters defined in this section along with their commonly used acronyms. The last column provides an indication of whether the ATM Forum s UNI 4.1 and PNNI 1.1 specifications define a means for the user to negotiate the QoS parameter with a network. Whether a network will support a desired set of QoS parameters depends on network and switch design, as well as the variation of the network load. Propagation delay dominates the fixed delay component in wide area networks, while queuing behavior contributes to delay variations in heavily loaded networks. The effects of the queuing strategy and buffer sizes dominate loss and delay variation performance in congested networks. A large single shared buffer results in lower loss, but greater average delay and delay variation.

17 The transmission network error rate defines a lower bound on loss. Transmission network characteristics are the leading cause for errors, and hence CER is a QoS parameter common to all QoS classes. Undetected errors in the cell header or configuration errors are the principal cause for misinserted cells. Bursts of errors or intermittent failures are the likely causes of errored blocks. For all applications, the CER and the CMR must be extremely small, on the order of one in a billion or less. Therefore, the principal QoS parameters are delay (CTD), Table4.1. QUALITY OF SERVICE (QOS) PARAMETER TERMINOLOGY in delay (CDV), and loss ratio (CLR). As discussed earlier, human sensory perceptions determine the acceptable values of these major QoS parameters, while data communication protocol dynamics define the rest. Table 4.1 lists the major causes of these QoS impairments [AF TM 4.1]. Note that the offered traffic load and functions performed by the switch primarily determine the delay, variation in delay, and loss parameters. Error statistics largely involve cell errors, but they also include misinsertion events when a cell header is corrupted by several errors so that the cell erroneously appears as valid. Of course, the more switching nodes a cell traverses,the more the quality degrades. All QoS parameters accrue in approximately a linear fashion except for delay variation, which grows at a rate no less than the square root of the number of nodes traversed. The following formulae define the CLR, CER, SECBR, and CMR in terms of the cell transfer outcomes defined earlier. Chapter defines the protocols defined to measure these QoS parameters.

18 Table 4.2 mapping of network impairments to atm qos parameters IP Performance Metrics (IPPM) ITU-T Recommendation I.380 describes a general methodology similar to that summarized in the preceeding section for measuring IP packet errors, loss, and availability. The IETF s IP performance metrics (IPPM) working group has precisely defined the following IP QoS metrics within a framework defined in RFC The general framework is similar to that described at the beginning of this chapter where the performance of an end-to-end application or any network segment is subject to measurement. Connectivity As defined in RFC 2678, Connectivity is the basic stuff from which the Internet is made. More precisely, it determines whether pairs of hosts are instantaneously reachable in either a one-way or bidirectional manner.

19 4.4 TRAFFIC PARAMETERS AND CONFORMANCE DEFINITIONS This section defines two more components of the traffic contract: the parameters composing the traffic descriptor and the definitions of conformance. Chapter 21 describes the conformance checking (e.g., policing) method, as well as means that a source can ensure conformance (e.g., shaping) ATM Traffic Descriptor The ATM traffic descriptor is a list of parameters that captures intrinsic source traffic characteristics. It must be understandable and enforceable. This section describes the following traffic parameters defined by the ATM Forum Traffic Management 4.1: A mandatory Peak Cell Rate (PCR) in cells/second in conjunction with a CDV tolerance (CDVT) in seconds An optional Sustainable Cell Rate (SCR) in cells/second (always less than or equal to PCR) in conjunction with a Maximum Burst Size (MBS) in cells The following statements summarize the ATM Forum s traffic parameter specification. Peak Cell Rate (PCR) = 1/T in units of cells/second, where T is the minimum intercell spacing in seconds (i.e., the time interval from the first bit of one cell to the first bit of the next cell). Cell Delay Variation Tolerance (CDVT) = _ in seconds. This traffic parameter normally cannot be specified by the user but is set instead by the network. The number of cells that can be sent back-to-back at the physical interface rate R = _ 1 (in units of cells/second) is _/(T _) + 1, for T > _. Sustainable Cell Rate (SCR) = 1/Ts is the rate that a bursty, on-off traffic source can send. The worst case is a source sending MBS cells at the peak rate for the burst duration Tb as depicted in Figure. Maximum Burst Size (MBS) is the maximum number of consecutive cells that a source can send at the peak rate. A Burst Tolerance (BT) parameter, formally called _s (in units of seconds), defines MBS in conjunction with the PCR and SCR cell rate parameters, as detailed in Chapter. These definitions are intended only to helpthe reader in understanding the traffic

20 Figure 4.8 PRINCIPAL ATM TRAFFIC PARAMETERS Traffic Descriptors and Tolerances ITU-T Recommendation I.371 and the ATM Forum TM 4.1 specification formally define the Peak Cell Rate (PCR) and Sustainable Cell Rate (SCR) traffic parameters in terms of a virtual scheduling algorithm and the equivalent leaky bucket algorithm representation detailed in the next chapter. The user specifies these traffic parameters either in a signaling message or at PVC subscription time, or else the network implicitly defines these parameters according to default rules. The Peak Cell Rate (PCR) is modeled as a leaky bucket drain rate, and the Cell Delay Variation Tolerance (CDVT) defines the bucket depth as CDVT + T for peak rate conformance checking on either the CLP = 0 or the combined CLP = flows. CLP = 1, or CLP = flows. with the peak rate for the SCR conformance definition. The burst toleranwce defines the SCR bucket depth by the following formula from Appendix B of the ATM Forum TM 4.1 specification:

21 The burst tolerance, or bucket depth, for the SCR is not simply the MBS because the sustainable rate bucket drains at the rate SCR. The bucket depth allows for MBS cells to arrive at a rate equal to PCR. Allocation of Tolerances There are several considerations involved in setting the leaky bucket depths (i.e., traffic parameter tolerances). These differ for the peak rate and the sustainable rate. For the peak rate, the bucket depth should not be much greater than that of a few cells; otherwise, cells may arrive too closely together. Recommendation I.371 defines the minimum CDVT at a public UNI. For a single bucket depth of CDVT seconds and a nominal cell interarrival spacing T, note that approximately CDVT/T cells can arrive back-to-back. For the sustainable rate, the burst tolerance (or equivalent MBS) should be set to a value greater than the longest burst generated by the user. Of course, the source should shape its traffic to this parameter. The burst length is at least as long as the number of cells corresponding to the longest higher layer Protocol Data Unit (PDU) originated by the user. Furthermore, some transport protocols, such as TCP, may generate bursts that are many PDUs in length; however, the network may not guarantee transfer of extremely large bursts. Chapter 24 describes the relationship between burst length and loss for statistically multiplexed sources. Also, some additional tolerance should be added to allow for the effect of multiplexing and intermediate networks prior to the point that checks traffic conformance IP Traffic Descriptor As described in Chapter, since MPLS can use RSVP-derived signaling, the traffic descriptors from RSVP are relevant [RFC 2211, RFC 2212, RFC 2215]. RSVP uses the token bucket algorithm to describe traffic parameters corresponding to a specific flow of IP packets. They exclude the link-level header size. The minimum-policed unit requires that the device remove at least mtoken bytes for each conforming packet. The parameter also allows a device to compute the peak packet-processing rate as b/m. It also lower bounds the link-level efficiency by H/(H + m) for a link-level header of H bytes. Figure illustrates the preceding concepts. The worst-case conforming burst is one that begins with a bucket full of tokens and continues with back-to-back packets arriving at the line rate R, and continuing for T = b/(r r) seconds.

22 Figure 4.9. PACKET-ORIENTED TRAFFIC PARAMETERS After a period of transmission at the line rate for approximately 0.5 seconds, the burst of packets has emptied to token bucket so that any subsequent packets would be considered nonconforming. After an idle interval of approximately 2 seconds, the bucket is completely replenished with tokens, and another burst of packets at the line rate of approximately 0.5 seconds in duration would be considered conforming. As in the ATM case, this is the worst-case alternating on-off arrival pattern ATM Conformance Definitions The ATM Forum TM 4.1 specification defines conformance definitions for combinations of leaky buckets. This specification defines the associated traffic parameters; use of the Cell Loss Priority (CLP) bit for tagging non-conforming cells; and as a declaration of the cell flow to which the Cell Loss Ratio (CLR) QoS parameter applies. As noted previously, the terminology of 0 means that the parameter applies to only the CLP = 0 flow, while the terminology means that the parameter applies to the combined CLP = flow IP Traffic Conformance Definitions In a manner similar to ATM s combinations of leaky buckets, a few information IETF RFCs have defined combinations of token buckets. RFC 2697 describes two token bucket, both with the same committed information rate (CIR) in bytes per second. The two token buckets have different depths, one has a depth defined by a committed burst size (CBS) and the second defined by an excess burst size (EBS), both parameters defined in bytes.

23 There are two modes of operation: color-blind and color-aware. In the color-blind mode, the meter assumes that arriving packets are uncolored. In color-blind mode, the marker colors an arriving packet of B bytes as follows: it is colored green if B bytes can be removed from the CBS bucket, otherwise it is colored yellow if B bytes of tokens can be removed from the EBS bucket, otherwise it is colored red. In the color-aware mode, the meter assumes that the arriving packets were previously colored as either green, yellow, or red. In color-aware mode, green-colored packets are checked against the CBS and EBS buckets and it remains green if it does not exceed CBS, but are colored yellow if they exceed the CBS, but not the EBS, and red otherwise. 4.5 CLASSES OF SERVICE Both ATM and IP standards have employed the notion of a relatively small number of QoS classes. In ATM these are called service categories or transfer capabilities, while in IP Diffserv, these are called per-hop and per-domain behaviors (PHBs and PDBs). The remainder of this section discusses and summarizes these approaches. The coverage onatm concentrates on the current ATM Forum TM 4.1 and ITU-T I.356 specifications, while the standards for IP and MPLS are based upon the Diffserv standards introduced earlier ATM Forum QoS Classes and Service Categories In order to make things simpler on users, the ATM Forum UNI 3.1 specification defined QoS classes. Each network specified particular values for the QoS parameters for each class, and optionally, an implementation could support individually negotiated QoS parameters on a per connection basis. The ITU-T I.356 still specifies QoS classes, whereas in theatmforum UNI 4.1 andtm4.1 specifications QoS classes are retained only for backward descriptive compatibility, and individual QoS parameters are specified instead ITU-T ATM QoS Classes An ATM connection (a VCC or a VPC) is provided with one Quality of Service class (in the ITU-T terminology). A VPC could carry virtual channel links with various specified QoS parameters, and the QoS of the VPC must then meet the most demanding QoS of the virtual channel links carried [ITU-T I.150]. A QoS class can have specified performance parameters (a specified QoS class) or no specified performance parameters (an unspecified QoS class).

24 Table 4.3. atm service category attributes begin table footnotes Unspecified QoS Class In the unspecified QoS class, no objective is specified for the performance parameters. Therefore, for the unspecified QoS class, there is no explicitly specified QoS commitment on either the CLP = 0 or the CLP = 1 cell flow. Services using the unspecified QoS class may, however, explicitly specify traffic parameters. QoS in International ATM Networks These are provisional values and not firm requirements, since operational experience may indicate that better ITUT Recommendation I.356 defines QoS objectives for a reference configuration spanningmultiple carrier networks in a related, yet different set of QoS classes. The reference configuration considers transmission distances of up to 27,500 km, which creates a propagationdelay of approximately 170 ms.

25 4.5.3 Mapping Between ATM Forum and ITU-T QoS definitions The service categories of theatmforum can be mapped to many of theatmtransfer capabilities in I.371. Some of the ATM service categories of the ATM Forum are equivalent to some of the ATM transfer capabilities in I.371 but have different names: Table 4.4 recommendation i.356 qos class objectives The fourth column lists characteristics of a typical application of the category, or capability. Although these groups chose different names, the close relationships established between the groups resulted in compatible definitions in most major areas. Although the most recent definitions in the ITU-T s Recommendation I.371 and the ATM Forum s TM 4.1 are closely aligned in many areas, they also have important differences, as shown in the table.

26 Table 4.5 plausible association of atmf service categories and itu qos class In general, a mapping between the ATM Forum service categories and the ATM transfer capabilities can be made according to Table 20-6, with some discrepancies:the ATM Forum distinguishes between real-time VBR.1, VBR.2, and VBR.3 and non-real-time VBR.1, VBR.2, and VBR.3, while I.371 specifies non-real-time SBR.1, SBR.2, and SBR.3 and real-time SBR.1 only. TheATMForum has a unspecified bit rate (UBR) service category that has no equivalentatmtransfer capability in I.371. I.371 partially specifies an ATM block transfer (ABT) transfer capability that has no equivalent in TM 4.1. An ATM service category or, interchangeably, ATM-layer transfer capability, represents a class of ATM connections with similar characteristics. Resource allocation defines how much bandwidth a network must allocate to the service category/capability. Possible strategies are assignment of a fixed amount to each connection; statistical multiplexing of connections; or a dynamic, also called elastic, allocation based upon the current state of network utilization.

27 4.5.4 Diffserv Per-Hop Behaviors (PHBs) This section summarizes the IETF standardized Diffserv PHBs, their code points, and important service attributes. Table 20-8 illustrates the mapping of the Diffserv PHB to the DSCP in the IP packet header, as detailed in Chapter 6. The remainder of this section now briefly describes eachphbin Table 20-8 with reference to RFCs that provide further details. Table 4.6 diffserv per-hop behavior (phb) and code point (dscp) mapping The set of eight Class Selector (CS) PHBs [RFC 2474] must yield at least two relative forwarding priorities. A PHB selected by a CS DSCP should give packets a probability of timely forwarding that is not lower than that given to packets marked with a CS DSCP of lower value, under reasonable operating conditions and traffic loads. PHBs selected by DSCPs 11x000 must give packets a preferential forwarding treatment over packets receiving the default PHB to preserve the common usage of IP Precedence values 110 and 111 for routing traffic. In addition, the CS PHB requirements on DSCP are compatible with those listed for the default PHB MPLS Support for Diffserv The L-LSP example of Figure shows separate LSPs from node A to node C. The LSP for highpriority traffic traverses the path A-B-C and uses the high-priority queue, as shown by shading in the figure. The LSP for low-priority traffic traverses the path A-D-E-F-C and uses the lowpriority queue. In the E-LSP example of Figure 4-10b, a single LSP traversing the path A-B-C carries both high and low priority traffic. Node A maps the DSCPs to the EXP bits and performs

28 queuing based upon the EXP field. In a similar manner, node B also performs queuing based upon the EXP field, shown in the figure by the dark black circle. Note that L-LSP allows a network operator the flexibility to route different traffic over different paths, for example, to meet different latency objectives and balance load in a more granular manner as compared with E-LSP. An advantage of E-LSP is that a smaller number of LSPs is required to support Diffserv. Fig 4.10 EXP FIELD BASED (E-LSP) SUPPORT OF DIFFSERV 4.6 COMPARISON OF ATM AND IP QOS AND TRAFFIC PARAMETERS So, if the IETF s token bucket and ATM s leaky bucket algorithms are simply different ways of expressing a deterministic description of a traffic flow, can they interoperate? The answer is yes, they can, as defined in IETF RFC This specification defines the mapping of the variou Parameters and Protocol Interworking Between IP s RSVP and ATM of the signaling protocols, algorithms, and parameters. As seen from the table, most parameters have a one-toone correspondence. The next chapter details the topics of QoS parameters, service classes, and conformance checking against the traffic parameters.

29 Table 4.6 parameter protocol 4.7 ATM SERVICE CATEGORIES OPTIMIZED FOR PACKET SWITCHING The ATM Forum has defined two service categories optimized for the support of packet switching applications, for example, IP and Ethernet.Weintroduced these categories earlier as Guaranteed Frame Rate (GFR) and Unspecified Bit Rate (UBR) Guaranteed Frame Rate (GFR) GFR was envisioned as providing a service that is aware of theatm AAL5 frame boundaries in order to efficiently support TCP/IP traffic. In general, UBR is already a good match for handling TCP/IP traffic, but it is only suitable for networks where congestion is handled by an upper-layer protocol; otherwise, there is a risk of congestion collapse, as described in Chapter. Peak cell rate (PCR) The pcr has the same meaning as in ubr: the maximum rate at which an end system is allowed to transmit. It can be expected that the pcr will often be set at the line rate of the atm adapter. Minimum cell rate (MCR) The MCR, expressed in cells per second, corresponds to the longterm average bandwidth reserved for the VC inside the network. It is similar to the sustainable cell rate (SCR) in VBR, modified to provide guaranteed bandwidth for AAL5 frames.

30 Maximum frame size (MFS) The MFS is the largest size of AAL5 frame the end systems can send. Maximum burst size (MBS) The MBS places an upper bound on the burstiness of the traffic to which the minimum guaranteed bandwidth applies. This parameter must always be at least equal to 1 + [(MFS PCR)/(PCR MCR)] In the GFR setup signaling messages, two additional parameters are defined: Burst Cell Tolerance(BCT) A burst cell tolerance (BCT) is to provide a measure on the maximum number of cells eligible for the service guarantee when the connection is served at a rate of MCR cells/s. Acceptable Burst Cell Tolerance (AccBCT) The AccBCT is the largest Acceptable Burst Cell Tolerance for GFR connections and is a required routing topology attribute. The algorithm used to determine a significant change for AccBCT on a specific network link, and thereby forcing the new calculated value to be advertised in the topology update messages, is identical to the one used for maxctd [AF GFR1.0]. GFR.1 With GFR.1, the network is not allowed to modify the CLP bit of the frames sent by the end systems. The end systems can send CLP = 0 frames in excess of the minimum guaranteed bandwidth; this may include MCR-ineligible frames as well. Therefore, no distinction between an eligible and an ineligible AAL5 frame can be made inside the network; eachatmswitch individually must determine which CLP = 0 frames should be transmitted to fulfill the MCR, and what is excess traffic that can be discarded during congestion. Note that GFR does not require that all the frames admitted at the ingress of the network are exactly those that must be delivered to the destination in providing the MCR. Table 4.7 GFR Service Parameters

31 Fig 4.11 classification of frames A subset of QoS-eligible frames is built by intersecting passed and conforming subsets. All cells in nonconforming frames whose first cell has CLP = 0 are counted by the F- GCRA(T,L) algorithm. These frames count against the MCR, but since they are nonconforming frames, the network may, but is not obliged to, deliver them. The GFR service guarantee is to deliver, with high probability, a number of cells in complete unmarked frames at least equal to the number of cells in conforming frames that pass the F-GCRA(T,L) with parameters T = 1/MCR and L = BT + CDVT Switch Modifications to Support GFR Tagging Tagging frames at the ingress of the network can be used as a means of reducing the priority of frames that are not eligible for the QoS guarantee before they enter the network. Perconnection network-based tagging requires some per-connection state information to be maintained. This tagging isolates QoS-eligible and non-qos-eligible traffic of individual connections tagging that other rate-enforcing mechanisms can use in the preferential treatment of QoS-eligible traffic. This would allow buffer thresholds to be used to discard tagged frames and allowing a greater proportion of QoS-eligible frames to enter the network at impending congestion.