Differentiated Services (diffserv) | QoS

The effort of the Differentiated Services (diffserv) working group (www.ietf.org/html.charters/diffserv-charter.html) is directed toward the development of the mechanisms that support aggregate QoS services. In other words, diffserv is concerned with ordering (and treating accordingly to this order) traffic aggregates. The packets that end up in a particular aggregate are classified according to a certain behavior rather than according to a particular service. With the intserv model, the admission control considers only the available capacity in order to grant or deny the resource reservation request. Yet, a new set of admission criteria (such as the identity of users, security-related information, time of day, and day of the week) are becoming increasingly important in influencing admission policy.

These criteria, once specified at the network endpoints, are mapped into differentiated services (DS) codepoints to be carried in the IP packets and thus recognized by the network elements. Informational RFC 2475 explains the relevant architecture model and sets the terminology. To this end, RFC 2475 classifies existing models of service differentiation into five categories: (1) relative priority marking (including IP version 4 precedence marking), (2) service marking, (3) label switching, (4) integrated services/RSVP, and (5) static per-hop classification. The diffserv architecture can be considered as a refinement of the relative priority marking in that it “more clearly . . . [specifies] the role and importance of boundary nodes and traffic conditioners.” As for the integrated services/RSVP model, which lacks state aggregation, the differentiated services mechanisms are expected to help by aggregating the RSVP state in the core of the network.

Among the key concepts of diffserv is that of per-hop behavior (PHB), defined as “a description of the externally observable forwarding behavior of a . . . node applied to a particular . . . behavior aggregate.” (A behavior aggregate is a set of packets, marked with the same codepoint, that are moving in the same direction over a given link.) A simple example of a PHB is specification of a guaranteed minimal allocation of bandwidth to a link for a period of time. RFC 2475 further notes that PHBs may be specified in terms of their resources (for example, buffer or bandwidth), priority relative to other PHBs, or relative observable traffic characteristics (for example, delay or loss). PHBs shaped by a common constraint so that they can be specified (and subsequently implemented) together, form a PHB group. PHB groups are essential differentiated services building blocks, and their concept is central to defining other elements of the diffserv architecture.

A differentiated services domain (DS domain) is defined as a contiguous set of nodes “that operate with a common service provisioning policy and set of PHB groups implemented on each node.” Nodes within a DS domain use the DS codepoint of an IP packet to select a relevant PHB and to deal with the packet accordingly. Typically, a DS domain encompasses one or more networks under the same administration (that is, an enterprise network or an ISP). As illustrated in Figure 1, a DS domain consists of DS boundary nodes (interconnecting the DS domain with the outside world, which, in turn, consists of other DS domains as well as non-DS-capable nodes) and DS interior nodes. As Figure 1 points out, a host “may [but does not have to] act as a DS boundary node for traffic from applications running on that host . . .” Contiguous DS domains form a DS region. Note, however, that the domains within any given region are not required to have a common set of PHB groups or identical codepoint-to-PHB mappings.

Figure 1: Classification of the DS domain nodes.

In order to support the services that span across the domains, the peering domains establish a service level agreement (SLA). The diffserv architecture defines an SLA in terms of the things it may provide, including:

§  Packet classification policy (that is, the criteria for selecting the subset of traffic that is to receive a differentiated service) and remarking rules.

§  Specification of traffic profiles and actions to traffic streams that fit (or don’t fit) these profiles. (A profile may, for example, assign to a particular codepoint the request to measure the traffic marked by it with a token bucket and provide the respective parameters.) Actually, the binary fit/don’t-fit scheme may be insufficient; according to diffserv architecture, “multiple levels of conformance with a profile may be defined and enforced.”

The ultimate product of the SLA is the traffic conditioning agreement (TCA). Here, the word conditioning means ensuring that the classified traffic complies with the profile; as the result of conditioning, certain packets may be dropped or delayed (delaying packets is one means of shaping the traffic). In addition, the packets’ codepoints can be changed in the process of conditioning. The act of measuring the arriving traffic against the profiled temporal properties is called metering. RFC 2475 defines a TCA as “an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain’s service provisioning policy.”

The traffic enters a DS domain through a DS boundary node, which, in this case, is called (in complete analogy with the PSTN terminology) a DS ingress node; the traffic leaves the domain through a DS boundary node called a DS egress node. Figure 2 illustrates the role of these nodes in traffic conditioning and their relation to TCAs. Here, the downstream traffic is leaving DS domain X through a DS egress node bound by the X-to-Y TCA. The egress node must therefore ensure that the traffic to DS domain Y corresponds to this agreement; if it finds the input traffic in violation of the TCA, it conditions it appropriately. The peering DS ingress node of domain Y is responsible for checking (again, by possibly conditioning it) by the same agreement. Typically, “the SLA between the domains should specify which domain has responsibility for mapping traffic streams to DS behavior aggregates and conditioning those aggregates in conformance with the appropriate TCA,” but the DS ingress node is ultimately responsible for enforcing the TCA within its domain. The functions of the DS egress node of DS domain X and the DS ingress node of DS domain Y are similar with respect to the Y-to-Z TCA, but note that the (only depicted) ingress node of DS domain Z is also connected to the non-DS-capable network. In this case, the ingress node is responsible for traffic conditioning in accordance with the local policy (of the DS domain Z).

Figure 2: Traffic conditioning at the edges of DS domains.

Figure 3 depicts the elements of the diffserv architecture relevant to the packet classification and traffic conditioning process. The first functional element of the architecture is the packet classifier, whose role is to sort the incoming packets based on some packet-related criteria. RFC 2475 defines two types of classifiers. The behavior aggregate (BA) classifiers look only at the DS codepoint; the multifield (MF) classifiers consider other packet header fields as well as additional information (for example, incoming interface). The packet classifier passes selected packets to the marker (which sets the DS field of each packet to a particular codepoint and adds it to a particular behavior aggregate) as well as to the meter (which measures the temporal properties of the traffic according to a particular profile and triggers specific actions for the in- and out-of-profile packets in the rest of the conditioning elements). Finally, the traffic streams end up in the shaper/dropper, whose role is to delay the traffic when it is necessary to bring it in compliance with a traffic profile. The delayed traffic is held in a buffer; when the buffer is full, certain packets (including those already in the buffer) may be dropped.

Figure 3: Packet classifiers and traffic conditioners.

Source: RFC 2475.

RFC 2475 also addresses a number of important topics (like security and tunneling considerations and PHB specification and guidelines) that are essential for complete understanding of the scope of differentiated services. The present diffserv standards-track documents have been published in RFC 2597 and RFC 2598.

RFC 2474 defines the DS field of the IP header for IP version 4 (IPv4)—where it replaces (or rather reinterprets) the type of service (TOS) octet—and version 6 (IPv6)—where it reinterprets the class of service (CoS) octet. Six bits (bits 0 through 5) of the field contain the DS codepoint; the last two bits are reserved. The document also addresses the existing (“historical”) codepoint definitions and the resulting issue of backward compatibility. To ensure the backward compatibility, a set of codepoints (called the class selector codepoints) that meet minimum requirements of compatibility with the deployed forwarding treatments is reserved. The document also makes recommendations regarding PHB standardization guidelines and assignment of codepoints.

The last two RFCs, respectively, define the assured forwarding (AF) PHB group and the expedited forwarding (EF) PHB:

1.  RFC 2597 defines the AF PHB group. The group contains four general-use AF classes; within each class there are three levels of drop precedence. Packets belonging to a specific AF class are forwarded independently from packets of any other class. The standard deals with short-term congestion by prescribing packet queuing. The long-term congestion is dealt with by dropping packets with higher drop precedence. RFC 2597 recommends specific codepoints for the 12 class–drop precedence pairs.

2.  RFC 2598 defines the EF PHB as the mechanism for building low-loss, low-latency, and low-jitter end-to-end services through a DS domain. (Note that these qualities are especially important for real-time voice-over-IP delivery.) EF PHB is defined as “a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate’s packets from any diffserv node must equal or exceed a configurable rate.” In order to eliminate (or reduce to a small size) the queues the aggregate has to go through, RFC 2598 postulates that the DS nodes that support the PHB must be configured (by network administrators), “so that the aggregate has a well-defined minimum departure rate.” Furthermore, the aggregate is to be conditioned, “so that its arrival rate at any node is always less than that node’s configured minimum departure rate.” Conversely, to protect non-EF traffic, RFC 2598 postulates that the maximum EF rate and, when appropriate, burst size must also be settable by network administrators. The document recommends a specific codepoint for the EF PHB and provides example mechanisms for implementing the EF PHB. It also reports (in its appendix) on an implementation of the Virtual Leased Line (VLL) Service.

Integrated Services | Quality of Service (QoS)

QoS is the subject of ongoing active research and more or less active standardization.

ITU-T has done much work in relation to B-ISDN, in which it effectively relied on the output of the ATM Forum. To this end, ITU-T Recommendations I.356 and I.610, respectively, specify performance measurement methods and QoS objectives for end-to-end connections and define operations and management tools to monitor the QoS parameters. In addition, the B-ISDN signaling specifies mechanisms for negotiating traffic parameters and QoS performance objectives.

Because of its connection-oriented, virtual-circuit approach to packet networking, it is more or less straightforward to deal with the QoS in the PSTN: The characteristics of the virtual circuit are what need to be negotiated among the participants of a session (and between each participant and the network). Given the inherently connectionless and stateless nature of the IP networks, guaranteeing end-to-end QoS is a much more complex matter. Consequently, standardization of relevant protocols is more complex, too. Virtually all QoS work that is related to routing (or, more precisely, forwarding) is performed in the IETF, and so, we concentrate on the IETF developments (some of which are explicitly addressed by the documents issued by other standards bodies).

TheretHERE are two basic approaches to IP QoS:

1.  Guaranteeing certain QoS on a per-flow basis.

2.  Guaranteeing QoS on a per-packet basis (as designated by the packet’s class of service).

The former approach is taken by the Integrated Services (intserv) and Resource Reservation Setup Protocol (rsvp) working groups, the latter by the Differentiated Services working group. In addition, the Multiprotocol Label Switching (mpls) working group is dealing with what effectively amounts to establishing virtual circuits for IP traffic, which makes it particularly suitable to interworking with the PSTN B-ISDN networks (such as ATM and Frame Relay networks). In the rest of this section, we address the respective standardization developments in that order.

Integrated Services (intserv)

The IETF Integrated Services (intserv) working group (www.ietf.org/html.charters/intserv-charter.html ) has been chartered with the development of an abstract packet-forwarding model. The applications of the model to particular Layer 2 protocols (such as ATM) have been, and continue to be, developed in the Integrated Services over Specific Link Layers (issll) working group (www.ietf.org/html.charters/issll-charter.html), which has produced ATM-related RFCs and works on the following link layer protocols: PPP, IEEE 802.2 LAN, and ISO High-Level Data Link Control (HDLC).

The earlier informational RFC 1633 specified the reference model for the network elements, which sets basic functions and terminology (see Figure 1). In this model, an arriving packet passes the:

§  Classifier. Maps the packet into a specific class (the class of the packet determines its treatment).

§  Packet scheduler. Manages the forwarding of different packet streams using a set of queues and possibly other mechanisms, like timers.

§  Output (first-in, first-out) queue.

Figure 1: Implementation reference model for routers.

Source: RFC 1633.

In the upper part of the figure, the routing agent supports a specific routing protocol and maintains the routing database. The reservation setup agent supports a specific resource reservation protocol; after approval by admission control, the traffic control database (which is shared with the classifier and packet scheduler) is modified to reflect the desired QoS. The management agent can modify this database, too, on behalf of the network management requests, in order to arrange controlled link sharing and to set admission control policies.

Following the template defined in informational RFC 2216, two types of services—the controlled-load service and guaranteed service—and their respective network element behavior types are defined in RFC 2211 and RFC 2212, respectively, as follows:

Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.

Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queuing delays.

To the application processes subscribing to the controlled-load service, the network appears to be unloaded. In other words, the packet loss, if any, will approximate that typical to the transmission medium. As for the delay, it is supposed to be nearly constant, dependent again on the transmission medium delay and the processing time delay in devices along the path. The application process specifies the controlled-load service by providing the Token Bucket Specification (Tspec, defined in RFC 2215). The application process specifies the guaranteed-load service by the same token bucket specification (Tspec) as well as the Reservation Specification (Rspec). Rspec is a pair of numbers that, respectively, specify the data rate (ranging from 1 to 40 TB/s) and the slack term (ranging from 0 to 2³² - 1 ms). The slack term is used by any network element to reduce its reservation level (the updated slack term is then passed to the next network element in the chain). RFC 2211 and 2212, respectively, specify the actions of network elements for each of the two types of services.

One resource reservation protocol has been developed, in close cooperation with the intserv working group, by the Resource Reservation Protocol (rsvp) working group (www.ietf.org/html.charters/rsvp-charter.html) in the transport area of the IETF. The protocol is also called RSVP, and is published in RFC 2205.

RSVP is used by the application process at the receiving end of flows (that is, streams of data with the same QoS requirements, which are defined by the destination address related to a particular session) as well as by the network elements along the path among the hosts whose processes are involved in the session. (The protocol has been specifically designed for and used by the multicast sessions, which explains its major features—especially the reservation mechanism described in the following text.) Although choice of a transport layer is not essential to key function of the protocol, the transport layer ports specifically considered in the document are those of UDP and TCP.

The reservations are requested for simplex flows. That means that the protocol treats the receiver and sender as two independent entities (in a manner similar to the single-endedness principle of the IN). Only the receiver makes reservations. If there are two application processes talking to each other, two different and independent reservations will be made: one by the receiver in one process, and one by the receiver in the other.

Figure 2 demonstrates the place of RSVP in the integrated services architecture—in particular, to the interface between a host and a router. The host model is equivalent to that of the router, which underlines the principle that the QoS is defined at the edges by hosts with routers carrying out the requests. The data path (that is, the interface between the packet scheduler of the sender and classifier of the receiver) is clearly separated from that between the two RSVP processes, which explains why the “implementation of RSVP will typically execute in the background, not in the data forwarding path.” (For this reason, following telephony terminology, the Internet community often refers to RSVP messages as the out-of-band signaling, although the difference between in-band and out-of-band is much more subtle here than in the case of the PSTN.) We should clarify, however, that RSVP is not an admission-control or packet-scheduled application, and its role is to reserve rather than provide the resources.

Figure 2: RSVP in hosts and routers.

Source: RFC 2205.

An RSVP reservation request uses a flow descriptor, which consists of flowspec (which may, in turn, include the service class, Tspec, and Rspec) and filterspec. The flowspec describes the QoS and is used by the packet scheduler; the filterspec defines the set of packets (that is, the flow) for the given QoS and is used by the packet classifier. Two-reservation options with respect to the treatment of different senders in the same session are supported: (1) establishing a distinct reservation for each sender and (2) making a single reservation shared among all senders. Other two-reservation options with respect to the selection of senders and, thus, the existence and number of filter specs provide (1) the explicit list of senders (with one filter spec for each sender) and (2) the so-called wildcard that explicitly selects all senders (and so eliminates the need for the filterspec).

Following is a description of how RSVP works. The sender transmits the Path message specifying the QoS request. As this message traverses network elements, it is stored in the path state in each of them. The receiver sends back along the same path Resv messages specifying the QoS for the reservation requests. The messages affect a soft (i.e., temporary) state: As the Path messages are periodically retransmitted, so the Resv messages are repeated to maintain this soft state for the duration of the session. These two messages are defined as fundamental by the RSVP standard (RFC 2205), which was designed to identify (via Path messages) all endpoints of a multicast flow. (The Resv messages from separate receivers can be combined into a single request at those points in the network where a flow’s paths merge.) With these two messages, RSVP not only uses existing routing protocols to determine the path of the flow between source(s) and destination(s), but it also reacts to changes in the network topology. Retransmission of Path/Resv over a new path can be used to change a path of a reserved flow, while the absence of retransmissions can be detected by the routers so as to deallocate the QoS resources associated with a delinquent path.

Session Initiation Protocol and Session Description Protocol

The two standard protocols that govern session control are the Session Initiation Protocol (SIP) and Session Description Protocol (SDP). These standards were originally intended for loosely controlled multimedia conferencing over the Internet; however, they have developed into a functional alternative to the H.323 suite. In particular, the combination of SIP and SDP is functionally equivalent to that of H.225.0 and H.245.

SIP (see RFC 2543) was initially standardized by the Multiparty Multimedia Session Control (mmusic) (see www.ietf.org/html.charters/mmusic-charter.html ) working group in the IETF Transport area. As the work had grown, a specialized SIP working group was created (see www.ietf.org/html.charters/sip-charter.html ).

SIP was designed to create and tear down multimedia sessions. In its syntax, SIP is similar to the Hypertext Transfer Protocol (HTTP)—defined in RFC 2616—and it reuses many HTTP header fields (such as authentication). Like HTTP, SIP is ASCII text encoded. Unlike HTTP, however, SIP was developed with the intention of addressing human users, for which reason the uniform resource identifier (URI) defined by SIP looks more like an e-mail address than the address of a World Wide Web page. For example, sip:hui-lan.lu@bell-labs.com is a SIP URI. For the purposes of integrating the PSTN and the Internet, it is important to note that SIP message headers can also carry other URIs (such as telephone URLs, defined by the IETF).

SIP is a client-server protocol: A client generates a request, to which a server sends one or more responses. A (potential) session participant can both generate and receive requests, which suggests that the end systems should have both the client and server capabilities. SIP also supports transaction capabilities. The RFC 2543 definition of a transaction is:

A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final . . . response sent from the server to the client.

Transactions are assigned the command sequence (CSeq) numbers. The SIP nomenclature (similar to that of SNMP and HTTP) alludes to the object-oriented model by defining the following methods that are carried in SIP requests (one method per request):

§  INVITE. Conveys the information about the call to invited participants. It is issued in order to set up a call, and once the call is set up, it can be issued by any party to the call in order to change the call parameters or to add another party.

§  BYE. Terminates a connection.

§  OPTIONS. Solicits information about a user’s capabilities.

§  CANCEL. Terminates the search for the user.

§  REGISTER. Makes the user’s location known to a SIP server.

§  ACK. Invokes the reliable message exchange for invitations. (Note that SIP has its own mechanism for invitation exchange; thus, it can run on top of an unreliable transport layer protocol such as UDP.)

The invitation to a session is accompanied by the Session Description Protocol (SDP) defined in RFC 2327, also developed by the mmusic working group (WG). SDP provides the description format (not the protocol) of the multicast and unicast addresses, the number and types (that is, audio, video, data, control) of streams involved, the codecs involved (that is, the payload types to be carried by the transport protocol), the transport protocol itself (for example, RTP or H.320), the UDP port, the list of starting and stopping times of the session, encryption keys, and so on. Keep in mind that SDP is only one possible payload of SIP; SIP can also carry all Multipurpose Mail Extensions (MIME) types, for example.

In the following section, we discuss location of clients and servers. In a perfectly valid degenerated case, both a client and server can be located in the same host. The opposite extremity, which is strategic to network-wide applications of SIP, is when several SIP servers located in different hosts act as proxies. In this case, server A, after having received a request from a client, may consult a local directory (by using LDAP, for example), only to find out that there is another SIP server, server B, which is better suited to respond to the request. Server A forwards the request to server B, which, from now on, will route its responses through server A.

The proxies can form a routing chain of any length. Figure 1 demonstrates such a chain. You have probably noticed a striking similarity between this figure and Figure 1. This similarity is actually profound, and it has been among the major factors that have influenced the pint working group to adopt SIP as the foundation of the PINT Protocol. SIP also offers a natural solution to the problem of gateway discovery, which is being worked on in the IP Telephony (iptel) working group (www.ietf.org/html.charters/iptel-charter.html).

Figure 1: SIP routing.

The use and applications of SIP are growing. The present specification of SIP, however, as far as size is concerned, is about one-tenth of that of the H.323 suite. In some cases (for example, session control), the protocols seem to be working to solve the same problem; other aspects (for example, definition of network functional elements and their respective roles) are different. For a good comparison of H.323 and SIP, please see “A Comparison of SIP and H.323 for Internet Telephony” (Schulzrinne and Rosenberg, 1998).