Delivering QoS in the next generation network — a standards perspective D Mustill and P J Willis
The next generation network (NGN) is envisaged as being an IP-based network which supports a wide variety of applications in an increasingly converged fixed-mobile environment. This paper looks at the key standards which are available as enablers to the building and operating of an NGN that delivers appropriate levels of quality of service for enduser applications. The paper starts by looking at a general framework for quality of service (QoS) standards, including the necessary terminology to distinguish between the performance of the network and the requirements of applications. It goes on to look at the key standards that address the application requirements, the performance of the IP layer and the behaviour of its bearer. In addition the paper discusses several concepts designed to allow the control of QoS levels in IP-based networks. Although it also discusses published standards, there is much ongoing standardisation activity in the technical areas of QoS and network performance that is outside the scope of this paper.
1.
Introduction — a framework for QoS standards
The term QoS is widely used, and misused, in the telecommunications world. The ITU1 has a longstanding definition in Recommendation E.800 [1] which tries to encapsulate all the aspects of a service which determine the degree of satisfaction of a user of that service. In the IP world the term QoS (pronounced kwoz) is generally used in a very limited sense of guaranteed bandwidth. Engineers talk about QoS-enabled networks, whereas, in common with any product which is built or service which is provided, all networks and services, including a best-effort IP service, have a quality of service which can be measured. Aware of the confusion that prevails, ITU-T Study group 12 (SG12) set about writing a new Recommendation with the intention of setting a well-defined and customer-oriented approach to QoS. New Recommendation G.1000 ‘Communications Quality of Service: 1 The International Telecommunications Union is a body of the United Nations responsible for aspects of telecommunications. It has three sectors — radiocommunication (ITU-R), telecommunication development (ITU-D) and telecommunication standardisation (ITU-T). The ITU-T sector is responsible for the creation of telecommunications standards, which are published as ITU-T Recommendations. Recommendations are developed by technical groups known as study groups, each of which is responsible for a specific technical area, e.g. ITU-T Study Group 12 is the lead study group for work on performance and QoS. For more information on the ITU and ITU-T, see www.itu.int and www.itu.int/ITU-T.
48
BT Technology Journal • Vol 23 No 2 • April 2005
A Framework and Definitions’ [2] was approved in November 2001. The scope of G.1000 makes mention of the need for improved consistency in the use of QoS-related terminology in the communications industry and highlights a particular need for this consistency to be applied in IP-related areas. The Recommendation is intended to set out a ‘topdown’ approach from a general definition of quality, through definitions of QoS and network performance, to a functional breakdown of the components of QoS in terms of service management, communication quality, billing and the customer’s ability to manage the service or network. The key terms defined in G.1000 are:
•
quality — the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs,
•
QoS — the collective effect of service performances, which determine the degree of satisfaction of a user of the service,
•
QoS requirements of user/customer — a statement of the level of quality required by the applications of customers/users of a service, which may be expressed non-technically,
Delivering QoS in the next generation network — a standards perspective
•
QoS offered/planned by provider — a statement of the level of quality expected to be offered to the customer by the service provider,
•
QoS delivered/achieved by provider — a statement of the level of the actual quality achieved and delivered to the customer,
•
QoS perceived by user/customer — a statement expressing the level of quality that customers believe they have experienced.
The definition of quality is taken from ISO 8402 [3] and the definition of quality of service is the longstanding E.800 definition. The authors of E.800 are careful to point out that in contrast to network performance, which can be defined and measured in technical terms such as packet loss, transmission delay, bit error ratios or call set-up times, QoS should be expressed in terms which are meaningful to a customer. The Recommendation advises that QoS should be described by parameters which:
•
focus not on the causes of events in the network, but on their effect as perceived by the customer,
•
make no assumptions about the internal design of the network,
•
take into account all aspects of the service from the customer’s point of view,
•
can be assured to a user by service providers,
•
are described in network-independent terms which create a common language understandable by both the user and the service provider.
The intention of G.1000 is to encourage a consistent use of QoS-related terminology across the communications industry. The Recommendation draws attention to the need for proven, robust and scalable standardised mechanisms that will allow provision of appropriate levels of QoS in IP-based networks. If such mechanisms are to be made available in a timely fashion, the authors of G.1000 believe that an industrywide consistent approach to QoS is clearly helpful. One matter not covered by G.1000 is the concept of there being relative QoS and absolute QoS. The concept of relative QoS is exemplified by standards which describe packet scheduling mechanisms designed to give priority to certain information flows or types of application. DiffServ [4], which is discussed briefly later, is one mechanism by which relative levels of QoS can be provided; it does not specify what levels of QoS will be given, but it can be used to ensure that flows of type A receive a higher level of network performance, and
hence of QoS, than flows of type B. When talking about degrees of QoS offered by such mechanisms, relative terms such as Gold, Silver and Bronze are frequently used. DiffServ may also be used to offer qualitatively different QoS for different classes of traffic, e.g. as network traffic increases one class may continue to experience low delay at the cost of higher packet loss, and another class may suffer higher delay but retain a low level of packet loss. The IETF2 has defined several concepts which are designed to allow the control of QoS levels in IP-based networks. The key concepts are:
•
resource reservation protocol (RSVP) [5],
•
integrated services (IntServ) [6],
•
differentiated services (DiffServ) [4],
•
multi-protocol label switching (MPLS) [7].
The general principles of each of these, along with some of their key advantages and disadvantages, are described briefly later in this paper. Standards dealing with absolute QoS focus on numeric objectives for specific performance parameters which are normally specified at a level which will ensure adequate QoS for a specific application or range of applications. The ITU-T Recommendation Y.1541 [8], which is also discussed later, is one standard which addresses absolute QoS, in this case for classes of applications being supported on IPv4-based networks. Unlike standards which deal with relative QoS, standards dealing with absolute QoS tend not to specify the way in which the appropriate absolute levels for a given application or set of applications can be achieved, but rather suggest relative QoS mechanisms which could be used to engineer a network to meet the recommended absolute levels of QoS. The term QoS-enabled is frequently applied to networks. This should be read as meaning a network in which QoS control mechanisms are employed to provide levels of relative or absolute QoS to certain applications or sets of applications. Two frequently used terms are guaranteed QoS and assured QoS (or QoS-guaranteed and QoS-assured). Given the statistical nature of packet switching 2
The Internet Engineering Task Force (IETF) describes itself as ‘a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual’. The IETF and its working groups meet three times a year, although much of the work is progressed through e-mail discussion. Most of the technical output of the IETF is in the form of request for comment documents (RFCs). For more information on the IETF, see www.ietf.org.
BT Technology Journal • Vol 23 No 2 • April 2005
49
Delivering QoS in the next generation network — a standards perspective
employed in IP-based networks, including NGNs and 3G mobile networks, the notions of guarantee and assurance need some consideration. At the ETSI3 STQ4 and TISPAN 5 joint workshop on QoS aspects of NGN in April 2004, it was concluded that at least three types of guarantee, or assurance, could be distinguished:
•
individual guarantee — a guarantee scheme in which a minimum level of performance should always be achieved, and some alternative special course of action will be taken if the level of performance is not met on certain occasions (e.g. a connection will be denied or charges could be waived),
•
statistical guarantee — a guarantee scheme in which a minimum level of performance should be achieved in most circumstances, with analysis of past performance measurements indicating the probability that the minimum level will not be achieved,
•
design guarantee — a guarantee scheme in which the network resources (e.g. bandwidth) are designed so that a minimum level of performance should be achieved in most instances but the probability that it will not be achieved cannot be predicted with confidence.
The concept of guarantees leads on to the notion of a scheme in which there are no guarantees — as in the best-effort service provided by the Internet. In such a scheme the available network capacity is shared among the users in a way such that all information flows benefit when the network is lightly loaded and all flows suffer the consequences of high network loads (e.g. increased transfer delays or packet loss). It is important to note that the term best-effort is a misnomer, as no specific network actions are taken to ensure the QoS of this type of service.
2.
Overview of IntServ
The Internet community started to look at QoS in the early 1990s and in 1992 a paper on Integrated Services 3 The European Telecommunications Standards Institute (ETSI) is an independent, non-profit organisation, whose mission is to produce telecommunications standards for today and for the future. ETSI is officially responsible for standardisation of information and communication technologies (ICT) within Europe. These technologies include telecommunications, broadcasting and related areas such as intelligent transportation and medical electronics. For further information see www.etsi.org. ETSI produces a range of technical documents from Technical Reports to European Norms. 4 STQ is ETSI’s technical body for standardisation in the areas of speech, transmission planning and quality of service. 5 TISPAN (Telcoms and Internet Converged Services and Protocols for Advanced Networks) is the main ETSI technical body dealing with standardisation for fixed networks and for migration from switched circuit networks to packet-based networks with an architecture that can serve in both. TISPAN is the key technical body in ETSI for NGN standardisation matters.
50
BT Technology Journal • Vol 23 No 2 • April 2005
(IntServ) was published which paralleled the development and methods of ATM for integrated services [9]. In 1994 RFC1633 ‘Integrated Services in the Internet Architecture: An Overview’ [6] was published. The first assumption of IntServ is that resources (e.g. bandwidth) must be explicitly managed in order to meet application requirements. This implies that resource reservation and admission control are key building blocks of the service. Resource reservation is where the application indicates to the network how much resource, e.g. bandwidth, it requires and the network reserves that resource for that application. Admission control ensures that applications that have not reserved resources do not interfere with those applications that have reserved resources. RFC1633 is focused on enabling real-time services by meeting their requirements for service guarantees, and it argues that guarantees cannot be achieved without reservations. The operation of resource reservations and admission control can be compared to the telephone network. When a number is dialled on the telephone network and the ringing tone is heard, this guarantees that sufficient capacity has been reserved across the network for that call. When the call is answered the quality of the call is guaranteed for the length of the call. If there is insufficient capacity in the network, the user will receive an equipment busy tone to tell them this. IntServ is significantly more complex than the telephone network, where the amount of bandwidth required by each telephone call is the same, whereas IntServ has a complex model for the bandwidth required per flow (a flow in IntServ being equivalent to a telephone call on the telephone network) which includes token bucket rate, token bucket size, peak data rate, minimum policed unit and maximum packet size. It is this complexity that condemned IntServ and in the 1990s, when PC CPUs went at sub-100 MHz rates, IntServ was technically written off as unscalable [10]. The other reason IntServ was not adopted was the lack of business drivers and commercial models for QoS on the Internet. IntServ does not strictly imply the use of RSVP (see below), but RSVP has been the only protocol widely accepted as being able to implement IntServ — indeed it is common practice to use the terms RSVP and IntServ interchangeably. Integrated services (IntServ) allows the prior establishment of an end-to-end path with the attributes that supply an appropriate degree of QoS. The three key service classes in IntServ are:
•
guaranteed service — which places an upper limit on the fixed packet transfer delay,
Delivering QoS in the next generation network — a standards perspective
•
controlled load — which limits the probabilistic transfer delay,
•
best effort — for which no QoS specific actions are taken.
IntServ uses RSVP to request adequate resources from the network for the guaranteed service and the controlled load service on a per-flow basis, but it has no mechanisms to ensure that the necessary conditions to support these resources exist in the network. For IntServ to work in a network all routers must implement RSVP, flow classification, admission control and packet scheduling.
3.
Overview of RSVP
The resource reservation protocol (RSVP) [5] is not a QoS protocol in itself, but it is used by other QoS mechanisms, notably IntServ and MPLS, to reserve the bandwidth necessary for delivery of appropriate levels of QoS. RSVP provides the mechanism for requesting, transferring and storing bandwidth requests. RSVP does not transfer the actual media requiring the QoS treatment. RSVP was designed for an ‘integrated services Internet’. RFC2205 claims ‘... RSVP provides receiver-initiated set-up of resource reservations for multicast or unicast data flows, with good scaling and robustness properties’. RSVP has become a general purpose IETF signalling protocol, which has had significant modifications from its original specification, its most notable non-QoS application being its use in the generalised multi-protocol label switching (GMPLS) architecture [11]. RSVP is a peculiar protocol because of its history; it started life being used on an integrated services Internet, signalling QoS requirements for realtime multicast applications, which endowed it with specific properties (which are discussed later), and it developed into a general-purpose signalling protocol, having contradictory requirements to its original application.
4.
RSVP features
RSVP is receiver initiated. This means that the application that is to receive a flow is responsible for signalling to the network the reservation that the flow requires. Receiver initiation is a confusing term since an RSVP session is initiated by the sender sending a PATH message to the receiver(s), but the reservation of actual resources in the network is initiated by the receiver. In a multicast application scenario typically there are many receivers and only one sender. Typically receivers will join and leave the multicast session, so it is the responsibility of the receiver to reserve the resources for the connection. To make efficient use of bandwidth, requests from several receivers for the same flow can be merged together (in multicast applications all receivers receive identical flows). RSVP has options to allow the
reservation to be shared or not with other receivers. Fortunately the receiver initiation model works for setting up MPLS label switched paths (LSPs), where it is the receiver (the egress of the LSP) that is responsible for assigning the label to be used. However, one can observe that the practice of making the receiver responsible for reserving resources can lead to inefficiencies when a sender (LSP ingress in MPLS) tries to establish several flows at the same time (it sends many PATH messages to different destinations), some of which are likely to fail. In real networks, this scenario will occur when a router reboots (either because of a fault or planned maintenance). The flavour of RSVP used for MPLS traffic engineering, where an MPLS LSP is set up with a specific bandwidth, is called RSVP-TE and is specified in RFC3209 [12]. When using RSVP, the traffic flow source sends a PATH message containing the appropriate service attributes to the receiver. The PATH message leaves backward pointers at the routers it passes through to indicate the route it took through the network. The receiver then sends a RESV message back to the source. In RSVP-TE the RESV message includes the MPLS label to be used. Intermediate RSVP-enabled routers can accept or reject the RESV message — routers which accept the message reserve the required bandwidth and buffer space and create a flow record. For typical RSVPTE implementations the routers will simply make a note of the bandwidth used but will not adjust the buffer space or scheduling in the router. RSVP is simplex, i.e. it requests resources in one direction only. Again this reflects the nature of the multicast applications where the source sends data to many receivers and receivers only listen. Intuitively one would expect real-time applications, e.g. people communicating, to require full duplex paths as people talk as well as listen. RSVP has been enhanced to support full-duplex paths for GMPLS [13] by including label information in the PATH message. RSVP is ‘soft’ state, i.e. RSVP sends periodic refresh messages to maintain the state of the reservations along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. This is because the membership of a large multicast group and the resulting multicast tree topology are likely to change with time; the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. Unfortunately soft state protocols are not suitable for general-purpose signalling mechanisms; in general it is not desirable for connections to be removed from the network because of a fault or planned maintenance of the control plane signalling protocol (e.g. a software upgrade of a router would lead to the connections or flows through that router being BT Technology Journal • Vol 23 No 2 • April 2005
51
Delivering QoS in the next generation network — a standards perspective
disconnected). Soft state can lead to scaling problems because of the constant refreshing of state information (reservations). RSVP has been enhanced to make its behaviour less soft state [14], and more reliable [13].
5.
Overview of DiffServ
In 1998 the DiffServ Internet draft was published [15]. DiffServ was a different approach to QoS from IntServ and ATM. DiffServ was an obvious evolution of the ideas on precedence published in 1993 [16] to manage service on the Internet when the Internet was under threat of collapse from congestion. DiffServ was designed to be very scalable, it worked by having only a few class of service (CoS) queues in the network, an application would be assigned to one of these CoS queues dependent upon the QoS required. The DiffServ architecture is specified in RFC2475 [4]. RFC2475 states: ‘This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behaviour on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.’ DiffServ is simple in concept but has been made difficult to understand due to the language used in the IETF RFCs to specify it. Willis [17] in his introductory paper describes the DiffServ architecture via a postal analogy. The IETF has reallocated six of the eight bits of the IPv4 type of service (TOS) field to the DiffServ codepoint (DSCP). These six bits give a possible 64 traffic behaviours that routers can apply on a per-hop basis. A ‘per-hop traffic behaviour’ is the forwarding behaviour of a router for traffic marked with the same DSCP on the same link; typically several per-hop traffic behaviours may share the same queue. It is usual that traffic flows in the same queue have the same delay and jitter requirements but may differ in their drop probability — the drop probability being the probability that a packet will get dropped if congestion is experienced. The drop probability may reflect whether the traffic is in or out of contract (if the traffic is out of contract it should be dropped if congestion is experienced) or it may be a rough indication of the importance of that traffic (but, as explained by Willis [17], its importance is only relative to traffic in the same queue). 52
BT Technology Journal • Vol 23 No 2 • April 2005
Different network operators can define their own QoS classes using appropriate choices of policing, traffic shaping and queue management. Such sets of classes need to be mapped between different operators’ interpretations at the points that different network operators connect. Some classes are predefined by the IETF:
•
assured forwarding (AF) — which uses twelve DSCPs to establish a set of four graded classes, each with three possible drop priorities [18],
•
expedited forwarding (EF) — which is intended for use by applications which have stringent transfer delay requirements [19],
•
best effort (BE) — which is intended for use with traditional Internet applications.
The reliability of the QoS offered by DiffServ is only as good as the reliability of network capacity planning. The loading limits of each CoS, the size of each CoS queue and the amount of scheduling for each queue must be predetermined based on predicted network loads. Network operators err on the side of caution by assigning more resources than required to each class (except for the best-effort class), and falling back on allowing unused bandwidth in one class to be used by another class. However, if network operators misjudge their network capacity planning, which with DiffServ includes planning resource per class, then the end result will be a lack of QoS, i.e. DiffServ does not compensate for bad network capacity planning. Maintaining the low latency and jitter of the EF class (for real-time applications like voice over Internet protocol (VoIP)) requires the total amount of EF traffic to be kept to a minority of the total link bandwidth. DiffServ is currently the most widely implemented mechanism for controlling QoS in IP-based networks.
6.
Overview of MPLS
MPLS is too vast a subject to do it justice here, and therefore this section will only give a brief overview of MPLS, in particular discussing MPLS in relation to QoS. 1997 saw the creation of a new set of technologies intended to accelerate IP routers (whose hardware was struggling to match Internet growth rates) — these technologies were Ipsilon’s IP switching, ARIS IBM switching, Toshiba switching and Cisco tag switching. They all worked by fundamentally changing the way routers operated — instead of doing a full IP address look-up at every router, they only did the look-up once, on ingress to the network, and then the other routers switched the packet across a path over the network based on a label smaller than the IP address space. To prevent a diversity of IP switching technologies the IETF
Delivering QoS in the next generation network — a standards perspective
formed the MPLS Working Group. MPLS became a key technology for delivering virtual private networks (VPNs) and QoS. The MPLS architecture is specified in RFC3031 [7]. MPLS is an important IP technology but it has been widely misunderstood. Firstly, MPLS is not a single protocol but a suite of protocols and the behaviour of the MPLS system changes significantly according to the choice made from this suite. People, including world leading experts on MPLS, still debate whether MPLS is an OSI layer 2 or an OSI layer 3 protocol and many people describe MPLS as layer two and a half. What OSI layer an IETF protocol belongs to is academic and so only the following limited observations on this matter are made:
•
MPLS data encapsulation (also known as the ‘shim header’) does not provide all the functions of a layer 2 protocol,
•
as the MPLS control plane is intrinsically bound to the routing of the IP network, it is not possible to consider MPLS as forming a separate layer network from the IP network.
The other highly debated subject is whether MPLS is a connection-oriented packet-switching technology (like ATM and Frame Relay) or whether MPLS is a connectionless packet switching technology like IP. It is clear that MPLS data encapsulation is connectionoriented because it employs the use of a label that only has significance on the link it is used on. However, some flavours of MPLS (e.g. using the label distribution protocol control plane) can be made to offer a connectionless service, which is reasonable considering MPLS was developed as a ‘booster rocket’ technology to make IP routers go faster. A common misconception is that MPLS replaces ATM. MPLS is a suite of protocols to use in an IP infrastructure and is not a service that is offered to customers. Furthermore MPLS is functionally very closely coupled to the IP network whereas an ATM network is a stand-alone network in its own right (i.e. MPLS can not form a stand-alone network in its own right). To understand this, let’s look at the postal analogy presented by Willis [17]. MPLS can be considered part of the IP network infrastructure in the same way the vans used by the postal service form part of the postal network infrastructure. The postal service does not rent out vans to its customers just because they use vans to deliver letters. Similarly an IP network does not offer MPLS services to its customers just because the IP network uses MPLS to deliver IP packets. The GMPLS architecture is specified in RFC3945 [11] and, although it is an evolution of MPLS protocols,
the terms GMPLS and MPLS cannot be used interchangeably. GMPLS was originally developed to control the provisioning of circuits or wavelengths on SDH/SONET and optical networks.
7.
The role of MPLS in providing QoS
The most common application of MPLS today is the provision of IP-based VPN services, as described in RFC2547 [20]. MPLS in this application provides an IP address extension mechanism to make the customer’s overlapping private address spaces unique. MPLS in this application does not typically provide any specific QoS advantages. MPLS does, however, have an impact on how QoS is implemented in IP VPNs because the MPLS shim header has only 3 bits (called the EXP bits) to represent the DSCP (which is 6 bits in the IP packet). Generally this is not a problem since MPLS is only used in the core network which is usually of much higher bandwidth than the access lines to the customer, and therefore many of the DSCPs can be mapped into the same EXP values (more classes of service can be mapped into the same queues in the core because of the size and dimensioning of the core network). The main QoS benefits from MPLS come about when MPLS traffic engineering, using the RSVP-TE protocol, is used. This allows MPLS LSPs (or trunks) to be explicitly routed across the network and to have a guarantee that the bandwidth is available in the network to support that trunk. In a traditional IP network the lack of ability to constrain traffic to specific paths makes the QoS guarantees given statistical in nature, and yet by adding MPLS using RSVP-TE we can constrain the traffic path and have guaranteed QoS across the network. MPLS TE is similar to IntServ but with very large aggregates of flows (hence the term trunk is used) instead of individual customer flows. The benefits obtained from deploying MPLS-TE depend very much on the topology of the network — MPLS-TE would benefit a sparsely meshed network much more than a fully meshed network.
8.
Multimedia QoS requirements
In November 2001 ITU-T SG12 approved Recommendation G.1010 ‘End-user Multimedia QoS Categories’ [21]. This Recommendation follows the topdown approach recommended in G.1000 and sets out to define a broad classification of user-centric QoS categories for a range of services and applications. The intention behind this categorisation is to aid in the derivation of a set of realistic QoS classes and QoS control mechanisms for underlying transport networks. Appendix I of G.1010 gives the delay and information loss performance requirements for a range of audio, video and data applications based on published BT Technology Journal • Vol 23 No 2 • April 2005
53
Delivering QoS in the next generation network — a standards perspective
research on user requirements. The range of delay and loss sensitivities is then formalised into eight categories as illustrated in Table 1. Table 1
The G.1010 model for user-centric QoS categories [23]. Error tolerant
Error intolerant
Interactive (delay <1 sec)
Conversational voice and video
Command/control (e.g. Telnet, interactive games)
Responsive (delay ~2 sec)
Voice and video messaging
Transactions (e.g. eCommerce, Web browsing, e-mail access)
Timely (delay ~10 sec)
Streaming audio and video
Messaging and downloads (e.g. FTP, still images)
Non-critical (delay >10 sec)
Fax
Background (e.g. Usenet)
Some key points to note about this model of categorisation are that:
• •
• •
as it is based on user perception, it is suitable for use with any underlying transmission technology, it provides upper and lower bounds for delay and loss — providing poorer quality for a given set of applications is likely to result in user dissatisfaction and providing higher quality may mean that network resources are being wasted, it provides a simple way to assess the suitability of a given bearer channel for supporting particular applications, it shows how QoS classes for differentiating service performance can be appropriately grouped without implying that one class is better than another.
By grouping sets of applications in this way it is possible to see that a small set of underlying bearer behaviours, in terms of loss and delay, could be defined which support a wide variety of end-user applications. A small set of bearer behaviours makes network management easier and breaks the link between service or application and the network that supports it. This separation of service from network technology is one of the key enablers for the provision of new services in NGNs.
9.
End-to-end performance of the IP layer
Recommendation Y.1541 ‘Network performance objectives for IP-based services’ [8] was approved by ITU-T SG13 in May 2002. It specifies IP performance objectives for international end-to-end IP network paths. The Recommendation defines six provisional network QoS classes, which are intended to form the basis of agreements between end users and network 54
BT Technology Journal • Vol 23 No 2 • April 2005
service providers, and between different service providers. It is intended that classes should continue to be used when static performance agreements are replaced by dynamic QoS requests supported by future protocols (whereby network resources are negotiated on a per session basis). Y.1541 is currently only applicable where IPv4 is used. Its applicability to or extension to cover IPv66 remains a matter for further study. The limited number of QoS classes defined in Y.1541 are intended support a wide range of user applications. It is possible that some existing or future applications will have performance requirements which are more stringent than can be met by the existing six classes and the Recommendation acknowledges the fact that these classes may require revision or new classes may need to be added. The Recommendation warns that any perceived requirement for further classes must be balanced against the feasibility of implementation, particularly the need for implementations to scale in global networks. Y.1541 defines these classes by means of performance objectives associated with the following four Y.1540 [22] parameters:
•
IP packet transfer delay (IPTD),
•
IP packet delay variation (IPDV) (which is often referred to as jitter),
•
IP packet loss ratio (IPLR),
•
IP packet error ratio (IPER). The four classes are illustrated in Table 2.
There are some subtleties in the definitions of these objectives. For instance, IPTD is the upper bound on the underlying mean IPTD for the flow, with IPDV being the upper bound of the 1 × 10−3 percentile of the spread of IP packet transfer delays about the mean. This differs from the similar parameters defined in the IETF’s IP performance metrics [23] where transfer delay is the value of the minimum fixed delay and delay variation is the limit of the transfer delay variation above the fixed delay (see Y.1541 [8], Y.1540 [22] and RFC2330 [23] for more information on the ITU-T and IETF definitions of IP performance parameters). Recommendation M.2301 [24] goes some way to apportioning the end-to6
IPv6 was specified by the IETF as a basic protocol in 1995, although some aspects still remain under development. Most of the enhancements proposed for IPv6 have now been added to IPv4 (the version of the Internet protocol which is dominant). The major advantage that IPv6 still has over IPv4 is the number of addressable devices — IPv4 uses 32 bits for addressing whereas IPv6 uses 128 bits.
Delivering QoS in the next generation network — a standards perspective
Table 2
Y.1541 provisional IP network QoS class definitions and network performance objectives [8]. QoS classes Network performance parameter
Class 0
Class 1
Class 2
Class 3
Class 4
Class 5 Unspecified
IPTD
100 ms
400 ms
100 ms
400 ms
1s
U
IPDV
50 ms
50 ms
U
U
U
U
IPLR IPER
1
× 10−3
1
× 10−4
1
× 10−3
1
× 10−4
1
× 10−3
1
× 10−4
1
× 10−4
1
× 10−3
U
1
× 10−4
U
— separate queue with preferential servicing and traffic grooming at network nodes,
end path objectives of Y.1541 to individual operator domains. It is worth noting that the terminology of Y.1541 is not entirely consistent with that of G.1000, even though G.1000 was approved six months earlier. This is partly due to the fact that the two Recommendations were developed in parallel by different Study Groups with overlapping periods in the approval process and partly due to the fact that Y.1541 follows closely Recommendation I.356 [25] on ATM performance, first approved in 1996, in which the term network QoS classes is used. Y.1541 and I.356 both describe technology-specific, technical performance objectives applicable between the network boundaries, i.e. between a pair of user-network interfaces (UNIs). Neither Recommendation uses parameters which are user-focused and should really be regarded as defining classes of network performance. Y.1541 does, however, fit into the general framework for defining quality of communication services in G.1000, and with the enduser multimedia QoS categories needed to support user applications given in G.1010.
1
× 10−3
— less constrained routing and distances8, — DiffServ PDBs based on expedited forwarding.
•
Class 2 — highly interactive data transactions such as signalling, — separate queue with drop priority at network nodes, — constrained routing and distance, — DiffServ PDBs based on assured forwarding.
•
Class 3 — interactive data transactions (no example given), — separate queue with drop priority at network nodes, — less constrained routing and distance, — DiffServ PDBs based on assured forwarding.
Y.1541 gives some examples of the use of each of the QoS classes for supporting specific applications, and relates them to a particular per-domain behaviour (PDB) in individual DiffServ domains.
•
Class 4 — applications requiring low loss with no delay requirement, such as bulk data or video streaming, — long queue with drop priority at network nodes,
Class 0 — real-time, jitter-sensitive, applications such as VoIP,
highly
— any route or path,
interactive
— separate queue with preferential servicing and traffic grooming at network nodes7, — constrained routing and distance, — DiffServ PDBs based on expedited forwarding.
•
•
Class 1 — real-time, jitter sensitive, highly interactive applications such as VoIP,
7 Traffic grooming is the process of sorting telecommunications traffic into the most efficient arrangement, based on such considerations as network topology, routing choices and network load.
— DiffServ PDBs based on assured forwarding.
•
Class 5 —traditional IP network applications requiring only a ‘best-effort’ service, — separate queue (lowest priority), — any route or path, — best-effort PDB.
8 The physical propagation time of electronic and optical signals means that the delay objectives for Class 0 cannot be met for very long paths or paths using satellite hops.
BT Technology Journal • Vol 23 No 2 • April 2005
55
Delivering QoS in the next generation network — a standards perspective
10.
QoS in 3G networks
be possible to simultaneously have a short transfer delay and a low SDU error ratio.
(3GPP)9
The third generation partnership project has specified a series of QoS classes, which are also referred to as traffic classes, for its Universal Mobile Telecommunications System (UMTS) in TS 23-107 [26]. Four classes are defined, which are chiefly distinguished by the delay sensitivity of the traffic they are intended to support. The four classes — conversational, streaming, interactive and background — are defined in terms of the applicability of the set of UMTS bearer attributes to each class. Three of the attributes relate to the performance of the UMTS bearer:
•
transfer delay,
•
service data unit (SDU) error ratio,
•
residual bit error ratio.
The conversational class is intended to support delay-sensitive real-time applications where the information flow is bi-directional, as in a telephone conversation or videoconference. The streaming class is also intended to support delay-sensitive real-time applications, but those that that have information flows which are primarily uni-directional, such as video-ondemand. These uni-directional applications are generally less delay sensitive than conversational flows, hence the less stringent delay objective. The interactive and background classes are intended to be used by traditional Internet applications, such as e-mail, Web browsing and FTP downloads. As these applications are significantly less delay sensitive than conversational or streaming applications, better SDU error ratio and residual bit error ratios can be achieved, at the expense of delay, by appropriate channel coding and retransmission in the UTRAN. The interactive class is intended for use by applications where there is a request and response nature to the information flow, such as in interactive Web browsing. (TS 29-207 [27] further divides the interactive class into three subclasses, which are distinguished by three traffic handling priorities.)
The fundamental characteristics of the four classes, along with the values that can be associated with their performance-related bearer attributes are shown in Table 3. It should be noted that the performance limits shown in Table 3 are not end-to-end across the network as in Y.1541. Rather, they apply to the mobile access part of a 3G path (i.e. they are applicable to the UMTS terrestrial radio access network (UTRAN)). Certain combinations of parameter values may not be possible under some network conditions, e.g. it may not always
The background class is intended for background traffic, such as the background download of e-mail or other files. In order to ensure that the interactive applications do not suffer excessive delays, TS 23-107 recommends that the interactive and background flows be separated by giving interactive traffic a higher priority in scheduling than background traffic, with background applications only using transmission resources when interactive applications do not need
9
The 3rd Generation Partnership Project (3GPP) is a collaboration of a number of telecommunications standards bodies — ARIB, CCSA, ETSI, ATIS, TTA and TTC. The original scope of 3GPP was to produce globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile System based on evolved GSM core networks and the radio access technologies that they support. The scope was subsequently amended to include the maintenance and development of the Global System for Mobile Communication (GSM) Technical Specifications and Technical Reports including evolved radio access technologies.
Table 3
3GPP UMTS QoS classes [26]. QoS class (or traffic class)
Conversational class
Streaming class
Interactive class
Background class
Intended for:
Real-time conversation
Real-time stream
Interactive best effort
Background best effort
Fundamental characteristics
Preserves time relation and variation between information entities of the stream
Preserves time relation and variation between information entities of the stream
Traffic follows a request/ response pattern
Destination is not expecting data within a given time
Preserves payload content
Preserves payload content
Traffic follows a conversational pattern and has stringent delay requirements Example applications supported Transfer delay SDU error ratio Residual bit error ratio
56
Speech
Streaming video
maximum 100 ms 10−2
−3
−3
, 7 × 10 , 10 , 10−4, 10−5
5 × 10−2, 10−2, 5 × 10−3, 10−3, 10−4, 10−5, 10−6
BT Technology Journal • Vol 23 No 2 • April 2005
Web browsing
maximum 280 ms −2
−3
−3
10 , 7 × 10 , 10 , 10−4, 10−5 5 × 10−2, 10−2, 5 ×10−3, 10−3, 10−4, 10−5, 10−6
Background download of e-mails
n/a −3
−4
n/a −6
10 , 10 , 10
4 ×10−3, 10−5, 6 × 10−8
−3
10 , 10−4, 10−6 4 × 10−3, 10−5, 6 × 10−8
Delivering QoS in the next generation network — a standards perspective
them. Such scheduling is particularly important in a wireless access environment due to the constraints on bandwidth.
11.
QoS in hybrid NGN and 3G mobile networks
While both ITU-T and 3GPP have set out to define a set of network QoS classes capable of supporting a variety of conversational, interactive, streaming and background applications, they have arrived at different conclusions. This would not necessarily be a problem if the third generation mobile and NGN environments were isolated. But obviously mobile users on a 3G network will want to communicate with users on a fixed access NGN. Additionally, the drive towards fixedmobile convergence will make it increasingly difficult to say whether a particular service is fixed, mobile or a hybrid of the two. In this converged environment the question of how to ensure that the networks deliver a level of performance suitable for supporting the enduser applications needs to be addressed. Studies are under way to determine if the UMTS and Y.1541 QoS classes can somehow be merged or mapped. Upon inspection of the two sets of classes some similarities emerge:
•
Y.1541 Class 0 corresponds with the 3GPP conversational class in intent — both are intended to support real-time, interactive applications with stringent delay requirements and a limit on jitter,
•
Y.1541 Class 1 corresponds with the 3GPP streaming class in intent — both are intended to support real-time, interactive applications with less stringent, but still limited, delay requirements and a limit on jitter,
•
Y.1541 set of Classes 2-4 corresponds with the 3GPP interactive class (and its subclasses) in intent — both are intended to support a range of interactive data applications with varying sensitivities to delay (in the Y.1541 case the delay sensitivities are given as absolute objectives, whereas in 3GPP they are captured in a relative manner by the priorities assigned to them),
•
Y.1541 Class 5 corresponds with the 3GPP streaming class in intent — both being intended to support traditional Internet best-effort applications.
The parameters themselves can be related as follows:
•
3GPP’s transfer delay parameter is defined as a maximum and is equivalent to the sum of Y.1541’s delay and jitter parameters (IPTD and IPDV),
•
3GPP’s SDU error ratio parameter is defined in such a way as to make it equivalent to the sum of Y.1541’s loss and error (IPLR and IPER),
•
3GPP’s residual bit error ratio has no corresponding parameter in Y.1541 — all of Y.1541’s parameters are packet-based.
With the exception of delay for the conversational and streaming classes, the 3GPP classes do not have absolute limits placed on their parameters. For example, the SDU error ratio for the conversational class can lie in the range from 1 × 10−2 to 10−5. This range of values makes it difficult to predict what the end-to-end packet loss ratio would be in a 3G-to-NGN call by combining the 3GPP SDU and Y.1541 packet loss and error ratios. The biggest difference in the way that the two sets of classes describe network performance is in their approach to packet delay variation (or jitter). Y.1541 defines a limit on jitter through its IPDV parameter for Classes 0 and 1, whereas the equivalent 3GPP conversational and streaming classes include delay variation in the maximum transfer delay specified for those classes. This means that for a call from a 3G mobile network to an NGN using Y.1541 classes there will be no way of predicting the end-to-end packet jitter. This incompatibility between the two sets of classes has been identified by several key standards bodies as a major barrier to the provision of assured quality paths between 3G mobile networks and NGNs. The fact that both sets of classes are embedded in well-established standards adds to the difficulty of finding a solution. ITU-T, ETSI, 3GPP and T1A1 in the USA are cooperating in trying to provide a solution to this problem.
12.
IP transfer capabilities
In March 2002 ITU-T SG13 approved Recommendation Y.1221 ‘Traffic Control and Congestion Control in IP Based Networks’ [28], which gives a general description of traffic control and congestion control along with particular objectives and procedures. In the context of Y.1221, traffic control refers to network actions designed to meet the negotiated performance objectives in an IP-based network and to allow the avoidance of congested conditions, and congestion control refers to network actions designed to minimise the intensity, spread and duration of any congestion that occurs10. Such control procedures are required in 10 TCP/IP has mechanisms in the protocol which ensure fair bandwidth sharing between multiple TCP/IP streams, and efficient use of almost all the available bandwidth, even in the presence of demand far greater than network capacity. TCP/IP underlies most Internet applications. Explicit traffic and congestion controls are required to cope with high volumes of UDP/IP traffic and to enable the delivery of assured levels of QoS (in terms of delay, packet loss and throughput).
BT Technology Journal • Vol 23 No 2 • April 2005
57
Delivering QoS in the next generation network — a standards perspective
order to support services with QoS requirements, where the level of QoS is negotiated between a user and the provider.
•
— supports applications which do not have stringent loss or delay requirements,
Key to Y.1221 is the concept of the traffic contract for a given IP flow. The traffic contract at a particular interface is made up of:
•
the selected IP transfer capability (IPTC) — a set of network capabilities provided by IP-based networks to transfer IP packets,
•
the traffic descriptor — the set of traffic parameters that describes the traffic characteristics of an IP flow,
•
the selected Y.1541 QoS class.
Dedicated bandwidth (DBW) transfer capability — supports applications with stringent delay requirements, — intended to give guaranteed and timely delivery of IP packets along the end-to-end path,
•
— despite there being no QoS commitments, the expectation is that packets will be delivered provided that sufficient resources are available. A fourth IPTC was added in March 2004:
•
Delay-sensitive statistical transfer capability
— supports applications that requirements on delay variation,
have
In addition to the detailed description of the IPTCs, Y.1221 says a little on the functions which can be used for traffic control: network resource management,
Statistical bandwidth (SBW) transfer capability
•
admission control,
•
parameter control,
•
packet marking,
•
traffic shaping,
•
packet scheduling.
— intended to give guaranteed delivery of IP packets along the end-to-end path, — intended to be compatible with both the controlled-load network element service, and the services based on the DiffServ assured forwarding per-hop behaviour [18].
The 2002 issue of Y.1221 says nothing about methods and tools for IP traffic engineering. This is a subject for further study.
Mapping of Y.1541 QoS classes to Y.1221 IPTCs and DiffServ PHBs. Y.1541 QoS classes Class 0
Class 1
Class 2
Class 3
Class 4
Class 5
Y.1221 IPTCs
DBW
DSBW
BE
DiffServ PHBs
EF
AF
BE
BT Technology Journal • Vol 23 No 2 • April 2005
not
Appendix III of Y.1221, which was approved along with the additional IPTC, gives guidelines on the support of services using IP transfer capabilities in a DiffServ environment. The Appendix points out that there may be other means than DiffServ by which the transfer capabilities can be supported. Table 4 shows the most logical mapping of Y.1541 QoS classes to IPTCs and DiffServ per-hop behaviours (PHBs).
•
Table 4
do
(DSBW)
— compatible with both the controlled-load network element service, and the services based on the DiffServ assured forwarding per-hop behaviour.
— intended to be compatible with both the DiffServ guaranteed service, and the services based on the expedited forwarding per-hop behaviour [19].
— supports applications which do not have stringent delay requirements,
58
bandwidth
— intended to give guaranteed and timely delivery of IP packets along the end-to-end path,
The IPTCs are crucial in that they create the link between the end-to-end network performance objectives, as captured in the QoS class, and the mechanisms that can be employed in the network to meet these objectives, notably DiffServ. Three IPTCs were included in the approved version of Y.1221. Some of their key characteristics are summarised below.
•
Best-effort transfer capability
Delivering QoS in the next generation network — a standards perspective
13.
Conclusions — putting it all together
From the end-user application requirements given in G.1000 to the IP transfer capabilities described in Y.1221, there is a structured approach to ITU-T QoS and performance standards, which is facilitated by the framework and terminology described in G.1000. At the router and packet level, standards defined by the IETF are still relied on. These IETF standards give relative QoS mechanisms which can be used to meet the absolute QoS requirements given in the ITU-T (and 3GPP) standards, but the standards themselves are not sufficient to give any guarantees of QoS in an IP-based network such as an NGN or a 3G network. More work is required on aspects such as interworking between 3GPP and ITU-T QoS classes, and scalable mechanisms to ensure that the appropriate network resources are allocated for each flow that requires more than a best-effort service from the network. Work is currently ongoing in the ITU-T and ETSI to define a comprehensive network architecture for the support of assured QoS services [29]. In the meantime, a combination of MPLS, DiffServ and traffic engineering is likely to be used to try to provide stringent delay and loss applications with the degree of performance they require from the network.
References
12 Awduche D et al: ‘RSVP-TE: Extensions to RSVP for LSP Tunnels’, IETF RFC3209 (2001). 13 Berger L: ‘Generalized Multi-Protocol Label Switching (GMPLS) Signalling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions’, IETF RFC3473 (2003). 14 Berger L et al: ‘RSVP Refresh Overhead Reduction Extensions’, IETF RFC2961 (2001). 15 Blake S: ‘Some Issues and Applications of Packet Marking for Differentiated Services’, IETF Internet-Draft, draft-blake-diffservmarking-00.txt (December 1997). 16 Bohn R, Braun H, Claffy K and Wolff S: ‘Mitigating the coming Internet crunch: multiple service levels via Precedence’, UCSD/ NSF Technical Report (November 1993). 17 Willis P J: ‘Introduction to quality of service, BT Technol J, 23, No 2, pp 13—27 (April 2005). 18 Heinanen J et al: ‘Assured Forwarding PHB Group’, IETF RFC2597 (1999). 19 Davie B et al: ‘An Expedited Forwarding PHB’, IETF RFC3246 (2002). 20 Rosen E and Rekhter Y: ‘BGP/MPLS VPNs’, IETF RFC2547 (1999).
1 ITU-T: ‘Recommendation E.800: Terms and Definitions Related to Quality of Service and Network Performance Including Dependability’, (1994). 2 ITU-T: ‘Recommendation G.1000: Communications Quality of Service: A Framework and Definitions’, (2001). 3 ISO 8402: ‘Quality Management and Quality Assurance — Vocabulary’, (1994). 4 Blake S et al: ‘An Architecture for Differentiated Services’, IETF RFC2475 (1998). 5 Braden R et al: ‘Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification’, IETF RFC2205 (1997). 6 Braden R et al: ‘Integrated Services in the Internet Architecture: An Overview’, IETF RFC1633 (1994). 7 Rosen E et al: ‘Multiprotocol Label Switching Architecture’, IETF RFC3031 (2001). 8 ITU-T: ‘Recommendation Y.1541: Network Objectives for IP-based services’, (2002).
11 Mannie E: ‘Generalized Multi-Protocol Label Switching (GMPLS) Architecture’, IETF RFC3945 (2004).
21 ITU-T: ‘Recommendation G.1010: End-user Multimedia QoS Categories’, (2001). 22 ITU-T: ‘Recommendation Y.1540: Internet Protocol Data Communication Service — IP Packet Transfer and Availability Performance Parameters’, (2002). 23 Paxson V et al: ‘Framework for IP Performance Metrics’, IETF RFC2330 (1998). 24 ITU-T: ‘Recommendation M.2301: Performance Objectives and Procedures for Provisioning and Maintenance of IP-based Networks’, (2002). 25 ITU-T: ‘Recommendation I.356: B-ISDN ATM Layer Cell Transfer Performance’, (2000). 26 3GPP: ‘TS 23-107 Quality of Service (QoS) Concept and Architecture V5.10.0’, (September 2003).
Performance 27 3GPP: ‘TS 29-207 Policy Control Over the Go Interface V.5.5.1’, (October 2003).
9 Clark D, Shenker S and L Zhang: ‘Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms’, Proc SIGCOMM ’92, Baltimore, MD (August 1992).
28 ITU-T: ‘Recommendation Y.1221: Traffic Control and Congestion Control in IP Based Networks’, (2002).
10 Mankin A et al: ‘Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment’, IETF RFC2208 (1997).
29 Cuevas M: ‘Admission control and resource reservation for sessionbased applications in next generation networks’, BT Technol J, 23, No 2, pp 130—145 (April 2005).
BT Technology Journal • Vol 23 No 2 • April 2005
59
Delivering QoS in the next generation network — a standards perspective
Dave Mustill joined BT in 1987 after graduating from the University of York. After a year in performance engineering he moved into network standards, working in the ITU-T and ETSI on network architecture and performance. Over the last sixteen years, he has been involved in the development of standards on performance and QoS for PSTN, ISDN, B-ISDN and IP networks. He chairs the UK End-toEnd QoS Task Group which is charged with updating the UK’s national transmission plan to take account of the introduction of IP technology into the PSTN. He is currently a rapporteur in ITU-T SG12 and is chairman of the QoS Working Group of ETSI TISPAN — the ETSI body looking at standards for next generation networks.
60
BT Technology Journal • Vol 23 No 2 • April 2005
Peter Willis joined BT in 1988 after obtaining an MEng in Electronic Systems Engineering from the University of York. His early work in distributed computing included the development of an ISDN IP router and the design of BT’s first public Internet network, BTnet. He installed one of BTnet’s first two PoPs in August 1994. He moved on to become the network manager for BTnet from the BT Network Operations Centre. He oversaw a huge growth of the BTnet team and an explosion in the number of IP services and customers from 1994 to 1998. He returned to Adastral Park in 1998 and ensured the lessons learned from designing and operating IP networks since 1993 were applied to BT’s designs, new emerging protocols, and architectures. He now works for BT’s Group CTO leading the development and implementation of components of BT’s next generation network architecture.
