In this chapter, we will introduce the quality of service (QoS) topic as applicable to IP communication scenarios. QoS is a complex topic, and we will describe in this chapter just some basic ideas that allow the reader to understand the mechanisms and protocols that exist to provide quality of service.
We will start by looking at some of the available architectures at the IP transport level to provide QoS, such as integrated services and differentiated services. Then we will introduce the framework for policy control, which enables the introduction of more intelligence in the admission control decisions for QoS. Then we will see how these ideas are applied in a SIP-based communication scenario and what the necessary SIP extensions are in order to integrate the SIP/SDP session establishment process with the underlying IP transport-level processes for quality of service.
Many communication scenarios involve the exchange of real-time traffic such as voice or video. We saw in Chapter 10 that in real-time traffic scenarios, it is critical that packets arrive at the destination no later than a certain time after they were transmitted by the source. If they arrive later, playback cannot happen and they have to be discarded. If the amount of packets arriving late increases, the quality of service perceived by the end user suffers, and, eventually, the received media (speech, video) may become unintelligible.
In a congested IP network, routers cannot cope with incoming packets as they come, so the routers are forced to queue the packets. This causes packet delay to increase, which, in turn, may cause real-time traffic packets to be discarded at the receiver. If congestion is severe, then the queue length limits are reached, and routers start to lose packets. In any case, a network congestion situation causes the end users to perceive a degraded quality of service.
In an unloaded IP network, this effect is not produced because packets are forwarded as soon as they are received, and therefore queues do not develop. Hence, an approach to provide quality of service for real-time communications has traditionally been, and still is, to overdimension IP networks. Obviously, one may argue that this is not the most cost-effective solution.
Our experience with the Internet of the 21st century tells us that Internet backbones are reasonably well dimensioned so as not to cause a problem for, for instance, voice transmission. Millions of people today around the world make telephone calls over the Internet with reasonably good quality. However, the explosion of high-bandwidth multimedia services, such as video, might pose a challenge in the future.
Even if there seems to be extra bandwidth in Internet backbones, there is still a point in the network where bandwidth is still limited: the access. Although xDSL technology has helped to overcome this issue in recent years, the issue still remains for access networks that are inherently limited in bandwidth, such as wireless networks.
There are, and there will be, cases where overdimensioning the network is not an option, and therefore it is critical to implement some kind of mechanism that helps preserve a certain quality of service for particular traffic flows and/or for particular users. If we assume that resources are limited, and that there is no endless extra capacity in the networks, assuring quality of service necessarily implies some way of prioritizing some packets over others. This calls for a different model from the traditionally egalitarian best-effort Internet model.
In general terms, prioritization could be implemented for those types of traffic (such as the real-time traffic) that have very stringent quality of service requirements. In that way, a router might prioritize a packet belonging to a real-time flow (e.g., UDP packet carrying voice) over a packet belonging to non-real-time flow (e.g., TCP packet carrying email). Another key aspect to consider here is charging. A network provider might want to charge for the provision of quality of service.
Even if the techniques to offer quality of service and policy control in an Internet environment have been defined for a long time, their implementation is marginal, as of today, in the public network. However, the concepts of quality of service and policy control are again becoming hot topics with the advent of telecommunication standards such as those produced by 3GPP and ETSI TISPAN. These standards, conceived for telecom operators, define the use of a controlled SIP-based private infrastructure in order to offer multimedia services (the so-called IMS, which will be described in Chapter 24). These standards build on the traditional Internet ideas for quality of service, taking them a step beyond, and allowing telecom operators to offer quality of service to their subscribers while at the same time providing the tools to enable charging for the use of QoS. The fact that, in some cases—for example, in wireless networks—bandwidth is limited, calls for such QoS mechanisms. Moreover, having the control of the access network—and thus, the key to the provision of quality of service—is a tool in the telecom operators’ hands in order to compete with Internet multimedia service providers that cannot offer such a quality of service. All in all, it is therefore expected that the techniques for IP quality of service will gain relevance in the short term associated with the deployment of telecom operators’ controlled multimedia networks.
Having said this, we will review in this chapter some of the traditional ideas around QoS in IP networks. These ideas will form the foundation that will allow the interested reader to understand the evolved QoS architectures that are now being defined—and, in some cases, deployed—in the remit of controlled 3GPP and ETSI TISPAN multimedia networks.
The approaches to QoS in IP networks are independent of the application layer—they all occur at IP level. This is a key design principle of the Internet, and has the tremendous advantage of allowing the two domains, application layer and transport layer, to evolve separately. Nevertheless, there is a need, at some point, to integrate the SIP application layer with the media transport layer, as we will see during this chapter.
The first sections in the present chapter will deal with the application-independent Internet approaches for providing quality of service and policy control. The last sections in this chapter will cover how to integrate the SIP layer (i.e., the control plane) with the previous approaches in an IETF-like multimedia network. Chapter 24 will touch upon how these concepts are used, slightly changed, in the Next Generation Networks (NGN) controlled by telecom operators.
The IETF has developed extensions to the IP architecture and the best-effort service model in order to deliver quality of service. More specifically, two additional models have been defined:
Integrated services (intserv)
Differentiated services (diffserv)
The integrated services approach is based on having the IP routers give preferential treatment to some IP flows over others. An IP flow is defined as a distinguishable stream of related datagrams that result from a single user activity and require the same QoS [RFC 1633]. In practice, an IP flow is distinguished by the combination of protocol, source and destination IP address, and source and destination port.
In order to implement a preferential treatment for some flows, IP routers would need to incorporate a couple of new functions:
the classifier: That is, a component that inspects the incoming packet and marks it as entitled to receive a specific QoS treatment by the router. The classifier passes the packet to the scheduler.
the scheduler: This component looks at the mark set by the classifier, and manages the forwarding of the packets in the different queues. The scheduler might, for instance, based on the mark, decide that a packet pertaining to a particular flow is forwarded before another packet pertaining to a different flow, even if the latter packet arrived earlier to the queue than the former.
The integrated services approach defines two different services:
Both of them represent an enhanced quality of service as compared with the basic best-effort service provided by the Internet. The controlled load service provides users with a quality of service that closely resembles the QoS that they would receive from an unloaded network. Even if the network is congested with best-effort traffic, the controlled load service would give preference to packets subject to QoS, hence emulating the behavior of an unloaded network. The controlled load service does not offer a guarantee that the delay will be bounded for a particular flow; it just gives preferential treatment to some packets versus others.
The guaranteed service, on the other hand, provides a specific flow with the assurance of a bounded delay.
In order to implement integrated services, we need some additional pieces that we did not mention so far. First, clients need to have a mechanism to ask for resources to be reserved in routers so that they can assure a specific quality of service. Second, routers need to have the capability of accepting or rejecting new reservation requests based on their existing available resources. The first functionality is called resource reservation; the second is referred to as admission control.
Figure 21.1 represents the different functionalities in an IP router extended with intserv functionality.
Resource reservation may be implemented with Resource Reservation Protocol (RSVP), defined in [RFC 2205]. Clients can, via the RSVP protocol, signal the routers the identification of the flow (protocol, source and destination IP address, and source and destination UDP/TCP port) and the required quality of service for it. Routers check if they have available resources to honor the request. If they have, then the packet classifier and scheduler are configured accordingly so as to give a specific treatment to the packets in the flow as soon as they arrive.
RSVP reservations are unidirectional; in order to reserve resources in both directions, two reservation processes need to be performed.
The way RSVP works is quite simple. In order to reserve resources in one direction, a two-step process is followed. First the transmitter sends an RSVP PATH message that is destined to the receiver (i.e., destination IP address is the receiver’s address). As this message traverses the routers in the path to the recipient, it will store in each RSVP-enabled router the address of the previous RSVP router (conveyed in the RSVP PHOP parameter). When the PATH message reaches the receiver, the receiver will create an RESV message that is used to actually reserve the necessary resources in the routers. The RESV message will backward traverse all the routers previously traversed by the PATH message. Routing of the RESV message is performed in a hop-by-hop way using the state previously stored by the PATH message. In that way, it is assured that the resource reservation is done in the very routers that will handle the packets from transmitter to receiver, which will follow the same route taken by the PATH message.
This is shown in Figure 21.2.
The differentiated services approach is also based on giving preferential treatment to some packets over others in the routers. However, instead of treating different flows separately, the diffserv approach relies on border routers marking the incoming packets with a tag called DSCP (differentiated services code point). Then the internal routers in the network just need to look at the DSCP in the packet and, based on it, apply a specific per-hop behavior (PHB) that is configured in the router. In other words, diffserv is based on applying specific treatment to aggregations of packets, rather than to specific flows, as in integrated services. This fact allows differentiated services to scale much better than integrated services. Figure 21.3 shows the differentiated services approach.
Differentiated services are defined in [RFC 2474], [RFC 2475], [RFC 2597], and [RFC 3260].
The fact that the integrated services approach requires routers to classify different flows (and hence to look to several protocol fields in order to identify the flow) impacts its scalability. Thus, it is not considered a good approach for the core of the network, though it might be a good fit for the access network. For the core, the diffserv approach is a better choice. In this way, both mechanisms might prove to be complementary when offering end-to-end quality of service to end users. Moreover, RSVP might be used, not only to reserve resources in the access network, but also to signal to the edge router, between the access (intserv) and the core (diffserv) network, how to set the diffserv mark in packets pertaining to a particular flow. This approach is described in [RFC 2998]. Figure 21.4 shows a possible scenario.
Variants of this approach are proposed for the newest IP-based next generation networks (3GPP IMS, TISPAN NGN), where, instead of RSVP, typically other protocols are used to signal the QoS requirements (e.g., 3GPP Generic Tunneling Protocol, GTP).
We saw in the previous section that resource reservation requests need to undergo an admission control function. This function is typically implemented in the access network’s edge router. The admission control component takes the decision to accept or reject the resource reservation request based on two factors:
The requester’s resource reservation request.
The available capacity in the router.
Nevertheless, service providers might want to base the admission control decision also on other parameters, such as the requester’s identity, his or her user profile, time of day or week, and so forth. For instance, the service provider might want to grant access to quality of service only to those users who have paid an extra amount.
[RFC 2753] specifies a framework for policy-based control over admission control decisions. The framework defines two functional entities: the policy enforcement point (PEP) and the policy decision point (PDP). The architecture is shown in Figure 21.5.
The PEP is a component located in a network node (e.g., router) that receives the resource reservation request. If that request requires a policy decision, the PEP will then formulate a request for a policy decision and send it to the PDP. This request may contain information such as the description of the flow or the amount of requested bandwidth that was present in the original received request, plus additional information.
The PDP, when receiving the request, may look for additional info (e.g., might query a user profile database). Then the PDP makes a policy decision and communicates it back to the PEP.
The PEP receives the decision and enforces it—that is to say, accepts or rejects the original request. This is shown in Figure 21.6, where an incoming resource reservation request is rejected after a policy decision is made.
A possible option for the protocol between PEP and PDP is the Common Open Policy Service (COPS) protocol [RFC 2748] and [RFC 4261]. COPS employs a simple client/server model where the PEP sends requests, updates, and deletes to the PDP, and the PDP returns decisions back to the PEP. The COPS protocol uses TCP as a transport.
COPS was proposed for the communication between PEP and PDP in the first releases of 3GPP IMS. Since Release 7 (R7), it has been replaced by an application on top of the DIAMETER protocol. The DIAMETER base protocol is defined in [RFC 3588].
Let us imagine that John wants to set up a voice call using SIP, and that he wants to use resource reservation so as to assure a certain quality of service. The reservation of network resources requires knowing the IP address, port, and session parameters of the called party (so as to identify the flow in the RSVP request). This information is obtained as a result of the SDP negotiation, in the SDP answer. Therefore, John will send the initial INVITE carrying the SDP offer. The INVITE request will cause Alice’s UA to ring and respond with a 180 (Ringing) provisional response that includes the SDP answer. At this point, John starts the resource reservation process because he has all the session information to do that. Let us imagine that the resource reservation process fails because there is one router in the path that rejects the resource reservation request. The call would then be dropped, but Alice has already been alerted, therefore resulting in a negative end-user experience. This is shown in Figure 21.7.
In order to avoid this problem, we need to make sure that the user is alerted only after network resources have been successfully reserved. This implies that SIP session establishment and resource reservation need to be somehow coordinated. The preconditions framework is a SIP extension defined in [RFC 3312] (the main spec) and [RFC 4032] (an update to the previous one) that specifies the way to integrate resource management with SIP and solve these issues. We will describe the usage of the framework for integrating QoS resources; however, the framework is general enough so as to be used for other types of resource management.
[RFC 3312] introduces the concept of a precondition. A precondition is a set of constraints about the session that need to be fulfilled before the called user can be alerted. The set of constraints is included in the SDP offer. When the called user receives the SDP offer, it generates an answer, but does not alert the user or proceed with session establishment. The recipient waits for the precondition to be met—that is, it waits for the resources to be reserved. As soon as the precondition is met, alerting can occur, and the session establishment can be resumed.
Figure 21.8 shows how this would work for a call between John and Alice. John does not want Alice to be alerted until network resources are reserved in both directions in order to assure quality of service. So he sends an INVITE request indicating that preconditions are required. This is indicated by:
Including a SIP Require header field set to the option tag “precondition,” and
Including some additional attributes in the SDP offer (see next section).
When the INVITE reaches Alice’s UA, the UA knows that Alice should not be alerted. Alice’s UA agrees to reserve network resources. Alice will handle resource reservation in the direction Alice-to-John, but needs John to handle the John-to-Alice direction. Alice indicates this by sending back a 183 (Session Progress) response to John, asking him to start resource reservation and to confirm to her as soon as the John-to-Alice direction is ready for the session. Both John and Alice start resource reservation. Let us assume that Alice completes resource reservation in the Alice-to-John direction; she does not alert the user yet because network resources in both directions are needed. When John finishes reserving resources in the John-to-Alice direction, he sends an UPDATE request to Alice. She returns a 200 (OK) response for the UPDATE, indicating that all the preconditions for the session have been met. At this point in time, Alice starts alerting the user, and session establishment completes normally.
We will now look a bit more in detail at how the SDP exchange works and what are the needed SDP attributes to handle preconditions.
From a User Agent’s point of view, a precondition is characterized by the following parameters:
Type: [RFC 3312] considers only the type “qos” (for quality of service). In the future, new types may be defined.[1]
Strength: Indicates whether or not the called party can be alerted if the resources cannot be reserved.
Status-type: Indicates whether the resource reservation needs to be done end to end or segmented.
Direction: Indicates whether the resource reservation applies to one direction (send or receive) or to both.
An end-to-end precondition implies that resources are reserved all along the way between the two parties. A segmented precondition implies that end users need to reserve resources only in their corresponding access networks. From a User Agent’s perspective, a segmented precondition can be local (if it applies to his or her own access network) or remote (if it applies to a peer’s access network). Figures 21.9 and 21.10 illustrate the differences between end-to-end and segmented status-types.
The strength tag can have the following values:
The direction parameter can have the following values:
sendrecv: Applies to both directions.
send: Applies to the send direction (from the User Agent’s point of view).
recv: Applies to the receive direction (from the User Agent’s point of view).
none: Does not apply for any direction.
We have seen how a precondition is characterized; let us now see how this works.
When John, in our previous example, decides to call Alice using preconditions, he adds some additional media-level attributes to the SDP offer for each media type. One of those attributes is called the desired-status attribute (a = des). It represents the desired status for the required precondition. It might look like:
a=des:qos mandatory e2e sendrecv
What this means is that John requires a qos precondition, and that resource reservation must be done end to end and applied to both directions. In addition to the des attribute, John must also add another SDP attribute, the current-status attribute (a=curr). This attribute represents the actual status of the precondition—that is, the actual status of the resource reservation. Given that John cannot start resource reservation until he has received the SDP answer, the curr attribute will indicate that resources are not reserved in any direction. So the complete media-level content of SDP1 would be:
m=audio 20000 RTP/AVP 0a=curr:qos e2e nonea=des:qos mandatory e2e sendrecv
The curr and des attribute must be present in any SDP offer/answer exchange that requires preconditions. The User Agent that receives the SDP offer compares curr and des; if they match (except for the Strength indication, which is sent only from calling party to called party), it means that the precondition is met, and alerting can proceed.
When the INVITE reaches Alice, she will create and send the SDP answer embedded in a 183 response, and start reserving resources in her sending direction. As was stated in Chapter 15, given that the 183 response contains an SDP answer, it must be sent reliably (that is, it will need to be acknowledged by a PRACK request). The SDP answer reflects the fact that Alice agrees to reserve resources for this session before alerting. She copies the received des attribute into the SDP answer, and includes a curr attribute that represents her view on the status of the precondition. In addition to those, she adds a new SDP attribute called confirm-status (a=conf), which represents a threshold on the status of the precondition. By including it in the response, Alice is indicating that she wants to be notified by John when the precondition reaches such a threshold.
SDP2 would look like (only the media-level):
m=audio 40000 RTP/AVP 0a=curr:qos e2e nonea=des:qos mandatory e2e sendrecva=conf:qos e2e recv
When John receives this SDP, he will know that Alice agrees to reserve resources for this session (otherwise the SDP would have been rejected), so he initiates the resource reservation in his sending direction. The conf attribute in this SDP indicates to John that when he finishes reserving resources in his sending direction (which corresponds to Alice’s receiving direction, as indicated by the “recv” parameter), he needs to communicate that situation to Alice.
Let us imagine that Alice completes resource reservation in her sending direction. Then she will wait to receive the confirmation from John about the precondition status for his sending direction (which corresponds to Alice’s receiving direction).
When John completes resource reservation in his sending direction, he sends to Alice an UPDATE request that reflects the new status for the precondition. SDP3 would look like:
m=audio 20000 RTP/AVP 0a=curr:qos e2e senda=des:qos mandatory e2e sendrecv
We can see that now the current status indicates “send” direction, as opposed to “none,” as appeared in SDP1.
At this point, Alice’s UA knows that the precondition has been met, so she will include SDP4 in the body of the 200 (OK) response to the UPDATE, and ringing will start. SDP4 would look like:
m=audio 20000 RTP/AVP 0a=curr:qos e2e sendrecva=des:qos mandatory e2e sendrecv
As we have seen from the example, the SIP preconditions extension requires that two additional SIP extensions are supported by User Agents: the PRACK and UPDATE methods. Therefore, the INVITE requests that require preconditions must additionally include the 100rel tag in the Supported header field, and should include an Allow header field with the “UPDATE” tag.
In SIP communication scenarios, SDP is typically used to describe the desired session characteristics. SDP also allows a User Agent to indicate that QoS requirements must be met in order to successfully set up a session. However, we have seen that a different protocol, RSVP, is used to request the resources required to meet the end-to-end QoS of the media stream. Therefore, there is a need to assure that the resources requested through the resource reservation process match the resources that were requested and authorized as part of the SIP/SDP session establishment process. In other words, we need a mechanism to link the SIP and transport layer in order to assure that policies are correctly enforced. [RFC 3313] defines such a mechanism and will be described in the next subsection.
It is worth mentioning that this mechanism is again in contrast to general Internet principles, which completely separate data from applications. Thus, this solution is not applicable to the Internet at large, but does find a lot of applicability scenarios in networks under a single administrative domain. The SIP extension needed to implement these functions will then be defined as a private (P-) extension.
[RFC 3521] and [RFC 3313] define the reference architecture for applying SIP sessions setup with media and QoS authorization, which is depicted in Figure 21.11.
The elements in the architecture are:
The End Host: It is the user’s device. It comprises a SIP UA, a RSVP client, and a media tool.
The Edge Router: It is the router connecting the end host to the rest of the network. It includes the following three components:
The Policy Enforcement Point: that is the point where the policy decisions are enforced.
The RSVP Agent.
The data handler, which includes the packet classifier, packet scheduler and the admission control module.
The QoS-enabled SIP proxy: That is, a SIP proxy that has the capability to interact with a PDP for the purpose of retrieving the media authorization token, as we will see later on.
The Policy Decision Point: The point where the policy decisions are made.
Figure 21.12 depicts, at a high level, how the media authorization process works. During SIP session establishment, the QoS-enabled proxy will check if the user is authorized to receive QoS. If he or she is, the proxy will contact the PDP and obtain an authorization token. The authorization token is stored in the PDP together with the negotiated session description. The proxy includes the token in the response back to the UA. The token contains all the information needed for the end host to perform resource reservation. Therefore, the end host initiates the resource reservation, including the token in the RSVP message requesting QoS. When this message is received by the Edge Router, the PEP will forward the token, together with the requested bandwidth, to the PDP. The PDP will check if the corresponding requested bandwidth is within the limit of what was negotiated in the SDP exchange. The PDP uses the token as the key to find the stored negotiated SDP. If the check is passed, the PDP sends back a positive response to the PEP, which reserves the resources and forwards the RSVP message.
In order to carry the token in the SIP signaling, a new header is defined: P-Media-Authorization. This header includes a P-Media-Authorization-Token, which represents the token in a specific format.
In the RSVP signaling, the token is conveyed in an RSVP object called policy data—more specifically, in the Policy-Element field within that object, as defined in [RFC 2750], which is an extension to the base RSVP protocol defined in [RFC 2205].
We will now see an end-to-end example for a session setup with media/QoS authorization and resource reservation. The call flow is shown in Figure 21.13.
We will assume that:
John wants to set up a multimedia session with Alice.
Both John and Alice have contracted QoS with their service provider.
1.
John sends an INVITE to his QoS-enabled outbound proxy (proxy A). The INVITE request includes the SDP offer. The SDP offer contains the description of the media that John desires to use for this communication, and the bandwidth (“b” parameter) requested.
2.
When the outbound proxy receives the INVITE message from the UAC, the proxy authenticates the caller and verifies that the caller is authorized to obtain QoS.
3.
Proxy A forwards the INVITE.
4.
Alice’s inbound proxy (proxy B) receives the INVITE. It authenticates the originating proxy and authorizes the call.
5.
Proxy B sends a Policy-Setup message (AuthProfile) to PDP-B including the media description. PDP-B stores the authorized media description in its local store, and generates an authentication token that points to this description.
6.
PDP-B returns the authorization token to proxy B (AuthToken).
7.
Proxy B places the token in the INVITE message and forwards it to Alice’s UA.
8.
Alice’s UA sends a 183 response (including the SDP response) reliably.
9.
Proxy B forwards the response to proxy A.
10.
Proxy A sends a Policy-Setup message (AuthProfile) to PDP-A including the negotiated media description. PDP-A stores the authorized media description in its local store, and generates an authentication token that points to this description.
11.
PDP-A returns the authorization token to proxy A (AuthToken).
12–18.
Proxy A forwards the 183 response to John’s UA. Then a PRACK transaction takes place to confirm delivery of the 183 response.
19.
As soon as Alice has sent the 183 response (step 8), she can request QoS by sending a RSVP PATH message that includes the received token as a Policy Element.
20.
The Edge Router B, acting as PEP for UA-B, upon receipt of the RSVP PATH message, sends a COPS message (REQ) to PDP-B. PDP-B checks the authorization using the stored authorized media description that was linked to the authorization token it returned to proxy B.
21.
If the authorization is successful, PDP-B returns an “install” decision (DEC).
22.
Edge Router B checks the admissibility of the request, and, if admission succeeds, it forwards the RSVP PATH message toward John.
23–26.
As soon as John receives the 183 response (step 12), he can start requesting QoS by sending an RSVP PATH message. So, steps analogous to steps 20, 21, and 22 take place, but now on the originating side.
27.
As soon as John receives the RSVP PATH message (step 22), he sends a RSVP RESV message to reserve resources on the network.
28.
The Edge Router A, upon receipt of the RSVP RESV message, sends a COPS message (REQ) to PDP-A. PDP-A checks the authorization using the stored authorized media description that was linked to the authorization token it returned to proxy A.
29.
If the authorization is successful, PDP A returns an “install” decision (DEC).
30.
Edge Router A checks the admissibility of the request, and, if admission succeeds, it forwards the RSVP RESV message toward Alice.
31–34.
As soon as Alice receives the RSVP PATH message, she sends the RSVP RESV message to reserve resources on the network. So, steps analogous to steps 28, 29, and 30 take place, but now on the terminating side.
35–40.
As soon as John receives the RSVP RESV message, he sends an UPDATE to Alice to indicate that the preconditions are fulfilled. The UPDATE is acknowledged.
41.
As soon as the UPDATE is received, Alice’s UA starts ringing.
42.
Alice accepts the call, and the media is established.
This chapter introduced a lot of concepts. As a summary, for the process to apply QoS in SIP communications, readers should remember:
The User Agents (e.g., calling party and called party) ask for resources through SDP in SIP signaling.
SIP proxies in the control plane then permit the media plane to allocate these resources.
And then the clients must still request the routers in the media plane to actually allocate these resources.
The architectures around QoS are well known, though they have not yet been widely deployed. Broadband accesses and an Internet with increasing capacity have made these architectures not needed in many cases so far. However, with the advent of IP multimedia services for wireless, bandwidth-restricted accesses, these ideas recover importance, and we will see that they will play a crucial role in the IMS architecture for mobile operators (Chapter 24).
[1] The IETF draft [draft-ietf-mmusic-securityprecondition], which, at the time of writing, is under evaluation, introduces a new type of preconditions: the security preconditions of type “sec”.